Jim Fulton wrote:
I already raised the question what the precedence should be if the <class...-and-<adapter...-pattern is used within the registration of trusted adapters.
OK, I'll anser that. If a permission is used in an adapter directive, it takes precedence over declarations made in a class directive.
(In the future, I'd like to change the way security declarations work so that, perhaps, they are set on a name-by-name basis. So then, declarations for names in other interfaces wouldb't be lost when making a declaration for an adapter to a particular interface.)
Excuse me wasting your time, I was wrong.
I think the current proposal is:
1. provide an explicit locate attribute. This should be steaightforard.
2. if a non-public permission was specified, then behave as if a locate attribute was used. This seems straightforward too.
Yes, I'm still aware of that proposal. It's implemented now. So, after all I would be ready now to check in :)
I don't see what the problem is.
After your adjustment I think it's only a 'little' problem if the <class... -<adapter..-pattern is used: If no permission is defined within the adapter directive it's possible that somebody defines a permission within the class directive that would require a locatable adapter. In those cases people have to be aware to use the locate attribute explicitly:
<adapter factory=".wikipage.WikiPageHierarchyAdapter" provides=".interfaces.IWikiPageHierarchy" for=".interfaces.IWikiPage" trusted="true" locate="true" />
<class class=".wikipage.WikiPageHierarchyAdapter"> <require permission="zwiki.ViewWikiPage" attributes="parents path findChildren" /> <require permission="zwiki.ReparentWikiPage" attributes="reparent" set_attributes="parents" /> </class>
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com