Colllection (ATTopic) searches by portal type incorrectly

[sirgarr]

Steps to reproduce:

• On a fresh Plone 3.0.4 site, add a Collection with one criterion: retrieve items with type Page.
• The default "Welcome to Plone" page does not appear in the Collection.
• However, if I go to "Document (Page)" portal_types in change the title from Page to Document, then reindex the welcome page, it does appear in the Collection.

I think that:

• The Collection is storing the portal_type id, "Document," in its criterion
• The Collection searches for catalog brains with Type equal to "Document" instead of portal_type equal to "Document."
• Because the catalog brains have Type equal to "Page" and portal_type equal to "Document," no results are returned.

[daftdog]

I can confirm that bug, got the same problem with some of my custom content types.

[naro]

hm, right, portal type criteria should search on portal_type, not on Type index, because Type is equal to title of the type and can be easily changed in ZMI.

[daftdog]

Hmm any clue how to fix this? I couldn't find any hints on where to start from in the code of the criterion...

[stainsby]

Replying to daftdog:

Hmm any clue how to fix this? I couldn't find any hints on where to start from in the code of the criterion...

Here is a quick and dirty workaround: In <instance>/Products/ATContentTypes/criteria/portaltype.py, change the line:

result.append((self.Field(), self.Value()))

to:

result.append(('portal_type', self.Value()))

Its serious bugs like this creeping into features that should be rock-solid stable that has forced me to consider moving to alternative frameworks (db4o, Wicket, etc. are looking promising). How did Plone 3.0.4 get released with this obvious error in it!?

I suggest that this this a blocker for Plone 3.0.5 as it will break many sites that use collections. I'll leave it to a Plone guru to make that decision though.

[optilude]

See also #7498

[sirgarr]

This patch should work while not re-introducing #6981. Sorry I don't have the proper hardware right now so I can't run all the tests. I also haven't created a new test.

In existing sites which already have an "item type" criterion set to a type with portal_type != Type, collections need to be manually updated unless somebody writes a migration script.

[sirgarr]

Also -- this patch is slightly messy because it relies on knowledge of the internal code for a type information's Title method, in order to look up a string version of the Title rather than a translatable Message version. (The latter would be automatically translated in TALES.)

It might make sense to add a parameter to the Title method to allow retrieving the Title in string format, not Message format. This would eliminate the need to know the internal implementation of the Title method.

[sirgarr]

Replying to sirgarr:

look up a string version of the Title

Actually there is an easy way to do precisely that -- I've updated the patch accordingly.

[sirgarr]

Fixed in http://dev.plone.org/collective/changeset/56105/ATContentTypes/branches/1.2:

Modify "Item Type" criterion to store the untranslated Type instead of portal_type, but to show the translated Type to the user. Fixes #7467 (with a browser test to verify it) without breaking #6981 again - however, the browser test for #6981 is disabled because the test browser does not translate the tests.

Any idea how to get the test browser to translate text in order to write a browser for #6981?

[sirgarr]

A few more changes to make tests work correctly and more robustly:

http://dev.plone.org/collective/changeset?new=ATContentTypes%2Fbranches%2F1.2%4056106&old=ATContentTypes%2Fbranches%2F1.2%4054788

Also, these changes still need to be forward-ported to trunk.

[sirgarr]

Additional changes to 1.2 and trunk

The fix is now forward-ported to trunk. The test for the translation issue #6981 is still disabled.

[limi]

This fix was included in ATContentTypes 1.2.4.