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