Ticket #7467 (closed Bug: fixed)

Opened 6 years ago

Last modified 5 years ago

Colllection (ATTopic) searches by portal type incorrectly

Reported by: sirgarr Owned by: alecm
Priority: blocker Milestone: 3.0.5
Component: General Version:
Keywords: Cc:

Description

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.

Attachments

collections-by-Type.diff Download (1.2 KB) - added by sirgarr 6 years ago.

Change History

comment:1 Changed 6 years ago by daftdog

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

comment:2 follow-up: ↓ 3 Changed 6 years ago by 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.

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 6 years ago by 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...

comment:4 in reply to: ↑ 3 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by sparcd

  • Priority changed from major to blocker

comment:6 Changed 6 years ago by wichert

  • Owner changed from somebody to alecm
  • Component changed from Unknown to Content Types

comment:7 Changed 6 years ago by optilude

See also #7498

comment:8 Changed 6 years ago by 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.

comment:9 follow-up: ↓ 10 Changed 6 years ago by 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.

Changed 6 years ago by sirgarr

comment:10 in reply to: ↑ 9 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by 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?

comment:12 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by limi

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

This fix was included in ATContentTypes 1.2.4.

comment:15 Changed 5 years ago by hannosch

  • Component changed from Content Types to Infrastructure

comment:16 Changed 22 months ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.