Dieter Maurer wrote:
How do you explain that Zope 2.8.x does *NOT* use
a simple "restrictedTraverse"
(in "Products.ZCatalog.CatalogBrains.AbstractCatalogBrain.getObject")
but instead an "unrestrictedTraverse" to the parent followed
by a "restrictedTraverse" for the last step?

Using a "simple restrictedTraverse" is wrong!

No, it's a different and valid approach...

And this is wrong -- but you apparently did not got this
from the discussion...

And that is what I am sad about (as I wrote)..., I'm guessing YOU didn't get what I wrote below about alternative security policies ;-)

The ZCatalog behaviour was fixed again in a late 2.7 release.
The long discussion was about this fix...

You are apparently proud to go back again...

I don't catch any exceptions, and yes, I'm happy that it is the right decision...

This does not justify the attribute "sane" (rather "insane") ;-)

I'm not forcing you to install it...

Imagine documents that can have attachments. Attachments have a single-state workflow which has them always accessible with their access being controlled by the workflow state of their containing document.

Sounds good, yes?

No: a single state workflow should not control permissions
(but allow them to be controlled by the environment).

Now THAT is a good point...

That's one reason why the "restrictedTraverse" implementation
was replaced by the more complex "unrestrictedTraverse-to-parent then
restricted-to-final-object" one.

...and still would have resoluted in a None being returned in this case!

Hopefully, you see the effect of the "simple restrictedTraverse"
and why the new implementation is better...

No, I see why Zope's security policy should have some different options...

...which I see you conveniently snipped off the end of the email.

Oh well, it seems legitimate differences of opinion aren't acceptable to you, which is a shame ;-)


Simplistix - Content Management, Zope & Python Consulting
Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to