Ticket #8161 (closed Bug: wontfix)

Opened 8 years ago

Last modified 5 years ago

portal_types meta_type != obj.meta_type

Reported by: frisi Owned by: frisi
Priority: major Milestone: 3.3.5
Component: Archetypes Version:
Keywords: CMF portalfactory Cc: jphoude, frisi


If you defined the meta_type of your content type in profiles/default/types/My_Type.xml like that::

<object name="My Type">
  <property name="content_meta_type">My Type</property>

objects of your type will have 'MyType' as meta_type::

  >>> _ = folder.invokeFactory('My Type', 'mytype')
  >>> folder.mytype.meta_type

This breaks sorting since Products.Archetypes.OrderedBaseFolder.moveObjectsByDelta only takes CMF-Types into account by comparing meta_types.

Since these differ for meta types containing spaces you'll experience very strange behaviour when reordering items in a folder containing some objects of type 'My Type'.

Change History

comment:1 Changed 8 years ago by frisi

either portal_types should not allow type definitions with a space, or the meta_type of objects should contain the spaces too.

comment:2 Changed 8 years ago by optilude

You're my hero, frisi - I've been banging my head against this one a few times!

I think we need to fix moveObjectsByDelta so that it normalises before comparing, or that it compares on portal_type, not meta_type. I'm actually surprised that meta types lose the space, but this probably pretty deep in Zope.


comment:3 Changed 8 years ago by jphoude

  • Cc jphoude added

comment:4 Changed 8 years ago by nouri

  • Owner changed from nouri to frisi

Frisi, do you have any idea where we're losing the space? Also, what does the class definition of My Type look like?

I don't like the idea of normalizing in OrderedBaseFolder. Seems like the wrong level to fix this.

comment:5 Changed 8 years ago by optilude

  • Status changed from new to closed
  • Resolution set to invalid

I'm not sure this is actually a bug in Archetypes/Plone/CMF. It may just be a common programming error.

In OrderedBaseFolder (and PloneFolder), we have;

    def getCMFObjectsSubsetIds(self, objs):
        """Get the ids of only cmf objects (used for moveObjectsByDelta)
        ttool = getToolByName(self, 'portal_types')
        cmf_meta_types = [ti.Metatype() for ti in ttool.listTypeInfo()]
        return [obj['id'] for obj in objs if obj['meta_type'] in cmf_meta_types ]

Note that objmeta_type? will not have a space in it. As far as I can tell, the meta type on an actual object is always normalised to not have a space.

Now, ti.Metatype() is a value set in the installation profile and held as a property on the FTI in portal_types. If you have a space here, it's arguably a bug in the content type's setup code.

If you have a profile like this, it works:

<?xml version="1.0"?>
<object name="My Type"
   meta_type="Factory-based Type Information with dynamic views"
   i18n:domain="rug.contenttypes" xmlns:i18n="http://xml.zope.org/namespaces/i18n">
  <property name="title" i18n:translate="">My Type</property>
  <property name="description"
    i18n:translate="">Definition of the My Type content type</property>
  <property name="content_meta_type">MyType</property>
  <property name="content_icon">document_icon.gif</property>
  <property name="product">rug.contenttypes</property>
  <property name="factory">addMyType<property>
  <property name="immediate_view">atct_edit</property>
  <property name="global_allow">False</property>
  <property name="filter_content_types">False</property>
  <property name="allow_discussion">False</property>
  <property name="default_view">view</property>
  <property name="view_methods">
    <element value="view" />
  <alias from="(Default)" to="(dynamic view)" />
  <alias from="edit" to="atct_edit" />
  <alias from="sharing" to="@@sharing" />
  <alias from="view" to="(selected layout)" />
  <action title="View" action_id="view" category="object" condition_expr=""
    url_expr="string:${object_url}/" visible="True">
    <permission value="View" />
  <action title="Edit" action_id="edit" category="object" condition_expr=""
    url_expr="string:${object_url}/edit" visible="True">
    <permission value="Modify portal content" />

Note how the name of the portal type object (on the outermost object tag) has a space, but the content_meta_type property doesnt.

comment:6 Changed 7 years ago by petschki

  • Status changed from closed to reopened
  • Resolution invalid deleted

Maybe there should be a fix for this, because many people obviously create products with spaces in meta_type (see collective.portletpage for example which cannot be sortet because of this "bug").

comment:7 Changed 7 years ago by frisi

  • Status changed from reopened to closed
  • Resolution set to wontfix

sorry for the late reply nouri, didn't get email notifications (https://dev.plone.org/plone.org/ticket/1385) i'm okay with optilude to see meta_types containing spaces as programming errors. as petschki reportet this requires to fix several add-ons (eg coll.portletpage), too.

before using zopeskel i never (dared to) put any spaces in meta_type declaration, but zopeskel even suggest to do that:

$ paster addcontent contenttype
Enter contenttype_name (Content type name ) ['Example Type']: My Type

since a lot of people do use zopeskel (maybe the authors of coll.portletpage too ;-) we should fix the root of most evil there.

i checked the issue tracker there and found an issue with a cross reference to this report already:  http://plone.org/products/zopeskel/issues/22

comment:8 Changed 5 years ago by keul

  • Cc frisi added

Sorry for commenting a closed bug, but seems that no-one fixed this issue in portletpage itself.

I had a similar experience in another project, and also an update step seems needed to fix obj.meta_type for all existings object.

Today ZopeSkel is ok, but still no one can sort the portletpages.

comment:9 Changed 5 years ago by frisi

hi lucca

reading through this thread i can see that we agreed on not changing the behavior here, although there are some products around that do have spaces in their meta_type.

portletpage apparently is one of those and should be fixed. please contact the author (optilude ;-) if he can do the fix or at least give you some tipp how to fix it (esp. the upgrade stop for migrating existing content).

i can understand that we could also think about fixing this in Plone, CMF, Zope? (wherever necessary). if you think this should be the way to go, it's probably the best to file a new ticket that refers to this one for starting this discussion.

Note: See TracTickets for help on using tickets.