Hi. Kevin (cc'd, along with the person whom I believe filed the original bug) asked me to look at collector issue 438. Here are a few thoughts and observations.

- canWrite and canAccess are simply friendly ways of interacting with the security policy: they defer all of their actual calculation to the security policy. Therefore, if they complain, that means your security policy is complaining.

- By default, the form machinery pays attention to the security policy, even if they are within a trusted adapter, when determining if it is ok to set a value. This is generally what you want. In this case, for instance, it appears to be alerting the developer of a misconfigured (or misunderstood) partial adapter configuration.

- To that point, the error, ForbiddenAttribute, indicates that the security machinery doesn't know anything about the 'title' attribute on the object that the form machinery is attempting to modify--that is, it knows of *no security declarations* pertinent to the object for 'title'. Obviously, from the zcml in the collector issue, the developer believes that the security declarations have been made. They haven't, at least for what matters here.

My first guess, then, is that the factory generated by annotatableadapter.partialAnnotatableAdapterFactory is not the class that is instantiated. I don't know that code: maybe I'm wrong. But, generally, the missing link that needs to be filled is getting the security settings on the object generated by the partialAnnotatbleAdapterFactory. The zcml is trying to do that, I see, but it's not working.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to