It could raise Unauthorized because the current user is not allowed to access the returned object, which is the case if there are security restrictions lower in the object tree. Which is something you don't seem to grok.
So why not just catch Unauthorized rather than masking all errors that happen, ever? ;-)
That condition has been accepted for far too long and, reading the rest of the thread here, seems to be a bug in this case.
Then what was this all about: """ >>2. If I understand correctly, it's trying to traverse to the >> newly-created DiscussionItem which though it's indexed, will not be >> available but two lines after the top-level call, on createReply, >> line 313. >> >>I assume there's a reason for the object to be indexed before being >>stored, so I won't try to guess what the correct fix is. > > > I'm not sure there's a good reason. This code looks quite dumb to me. It > should do a _setObject and _getOb and do the rest of the edit, > addCreator, etc. """
Furthermore, rather than effectively re-implementing getObject in CMF code, why didn't we just catch the exceptions that are now being raised?
Because we want to get to that object and reindex it.
Huh? You've changed it to return None when it can't get the object, how does that let you get to the object and re-index it.
Anyone mind if I revert this checking?
Yes, me. Stop threatening to revert checkins, Chris.
I'm not threatening anything, I'm asking, and the wording was bad here. I meant to revert the current "fix" and replace it with something like:
try: object=brain.getObject() except Unauthorized: logger.error('Could not get to %s to do X to it',brain.getPath())
What's wrong with the above?
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests