[Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

[Florent Guillaume]

Chris Withers  <chris at simplistix.co.uk> wrote:
> Tres Seaver wrote:
> 
> > Chris, you need to get off this hobby horse.  Florent's fix was correct
> > for the *new* model which has 'getObject' raising (a model you profess
> > to *like*).
> 
> Why not by catching the expected errors? Do you like bare try: 
> except:'s? (since that's effectively what this is!)

<Sigh> Please read and understand the code more carefully.

There is no expected error. reindexObjectSecurity (which I introduced
more than 2 years ago because CMF was buggy without it) needs access to
all subobjects to reindex them. To do that it has to:

1. use an unrestricted searchResults, which was introduced with the name
   unrestrictedSearchResults 8 months ago in the types tool, and used in
   reindexObjectSecurity 3 weeks ago,

2. use an unrestricted equivalent of getObject. Before, getObject
   returned the object without security checks. Now, it does security
   checks. So we can't use it. And there's no unrestrictedGetObject.

That's why we have to do the equivalent using unrestrictedTraverse and
brain.getPath()

The None issue is a red herring, it's just that we *don't* want to fail
even if there are broken indexes. No we don't. We're reindexing what we
can find in the catalog. We don't want an exception.

> > Bugs in the catalog itself, in BTrees, in the CMF, or in third-party
> > software can leave cruft in the catalog:  robust code *has* to deal with
> > that problem.
> 
> ...by sweeping it under the carpet? Come on! I for one want to know if 
> there's cruft in my catalog so I can fix it.

I don't want the users to find that out when they change the local roles
somewhere. If you want to audit your catalog, just write a recursive
method that checks the objects. Don't do it on the fly and have it fail
on your users when ignoring broken object would have no actual impact on
the functionality of the code.

> Now, this particular case seems to back up my point even more. It looks 
> like the actual problem here is crufty code in 
> Products.CMFDefault.DiscussionItem which has been happilly masked up 
> until now.

This is unrelated. Don't mix theses issues, I fixed a real bug that may
or may not have been visible because of DiscussionItem.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com