...

...

Michel Pelletier wrote and fixing the "can't index attributes acquired from higher than the enclosing folder" from ZopeFindAndApply. I've not been bitten by this one, so I'm not sure I understand.

Ok. I have a bunch of folders with help files in them - something like featureA/help/helpfolder1/fileA featureA/help/helpfolder2/fileB1 featureA/help/helpfolder2/helpfolder2a/fileB2 featureA/help/helpfolder3/fileC featureA/help/helpfolder4/fileD featureB/help/helpfolder5/fileE featureB/help/helpfolder6/fileF featureB/help/helpfolder7/fileG (only with many more helpfolders and files) and I want to full text index them, and also index them by a bunch of attributes. One of these attributes is 'featureName', which is a property of the featureFolder (eg featureA). The current code breaks the acquisition at the enclosing folder, so that it can see whether the folder has an objectItems() method. It then looks up objects in this no-acquisition folder, and indexes them. This means that when indexing, you can't index on an attribute from higher up the acquisition chain that the enclosing folder object. For my application (which is in production use[*1], btw - and has been getting all sorts of nice feedback) I could either: fix this or make sure to copy the 'featureName' attribute to all folderish objects created inside a featureFolder (and to their children, &c.) This would bite in a major major way - if I changed a featureName, I'd have to change it in all subfolders.

When indexing with find, you want objects to try and acquire attributes and index the value of that acquried attribute if it can do so?

Sure - if you're asking for an attribute that can be acquired.

Hmm.. I think context could come up and bite us here, The request to index the object may have a different acquistion context then the request that runs the query, thus 'find' may index values for objects that other people may not be able to see in their context, or even have permission to see.

That could be a documentation issue - "make sure to run the findandapply in a context that is appropriate". I still think that's better than the current behaviour, where you can index acquired attributes, but only if they're acquired from the immediate aq_parent.

By not acquiring, you limit the functionality, but avoid having to run catalog queries through the security machinery; god help us all if that ever happens. Maybe that doesn't make sense, what do you think? Can you reproduce a security violation with your patch?

Nope. Not in my application. In _theory_ I can see that you could have a security problem if you weren't aware that the indexing occurs in the context running the findandapply request - but then, it does already (see above). Heck, you could even make it a toggle option in the page 'index acquired objects'. The other (currently unreleased) use for this is in my workflow code. I have something like (but not really) an SQL method with a direct traversal class, which then gets called with dtml methods acquired from the parent - so wffolder/meth1 wffolder/meth2 wffolder/meth3 wffolder/sqlInstanceLookup and I need to be able to catalog wffolder/sqlInstanceLookup/0001/meth1 wffolder/sqlInstanceLookup/0001/meth2 wffolder/sqlInstanceLookup/0001/meth3 wffolder/sqlInstanceLookup/0001/meth4 Without the ability to index acquired attributes, this becomes hellishly difficult. Anthony [*1] go to www.ekit.com, sign up for an account (about 3 clicks) then click on 'help'. The tree on the left is populated from ZCatalog searches, which amongst other thing only show help for the stuff your account is able to do, the search box is a textindex of the files (which, again, only searches the help for stuff your account can do), and the lookup of a help document (like, when you click on a help link) will hit the ZCatalog to look up the file's path. The help files themselves are maintained by a non-techie in dreamweaver, and uploaded into zope. ZCatalogs rock :)