[Zope3-checkins] SVN: Zope3/trunk/src/zope/app/dublincore/timeannotators.py Unwrap DCadapter in time annotators.

[Garrett Smith]

Gary Poster wrote:
> Zope3/trunk/src/zope/app/dublincore/timeannotators.py Unwrap DCadapter
> in time annotators.
> 
> 
> 
> On Feb 27, 2005, at 1:58 PM, Garrett Smith wrote:
> 
>> Gary Poster wrote:
>>> Zope3/trunk/src/zope/app/dublincore/timeannotators.py Unwrap
>>> DCadapter in time annotators. 
>>> 
>>> 
>>> 
>>> On Feb 25, 2005, at 7:10 PM, Albertas Agejevas wrote:
>>>> 
>>>> ...Imagine a forum where anonymous
>>>> users post comments.  Your suggestions imply that either DC write
>>>> access will be public, or modification times will not be updated.
>>>> This is bogus. 
>>>> 
>>>> A more plausible model would be if the event subscribers could be
>>>> declared as "trusted" if they do system-level things, like updating
>>>> the DC metadata or indexes.
>>> 
>>> Albertas, your use case sounds reasonable.  On one hand, I think it
>>> makes sense for a default Zope 3 app to *not* allow DC annotations
>>> if you do not have write privileges to an object (for instance, if
>>> you don't have have write access to an object it would seem
>>> surprising that you could be last modifier to me, as an
>>> out-of-the-box behavior); but on the other, it also might make
>>> sense for an app with your use case to allow DC annotations.
>> 
>> I see Albertas's point here. I think most people would want
>> create/modified to always work, regardless of how they have their
>> permissions set up.
> 
> Maybe so.  I don't feel strongly about it.
> 
>> This is also a function of event handlers *always* being called.
>> Events are a nice way to add functionality, but once they're
>> subscribed, they can be hard to work around.
> 
> Oh, yeah, good point. :-/
> 
> Isn't there some magic that if you subscribe None then that clears
> subscription for the exact combination of interfaces?...something like
> that?  Something even more surgical would be better for this sort of
> case.  But that might be workable.
> 
>>> Would making an override zcml registration of the DC annotation
>>> subscriber in your package's zcml make sense for your app/package? 
>>> It could make the DC subscriber a trusted subscriber
>>> ("trusted='yes'"), which does precisely what you want AFAICT.  For
>>> the precise use case you mentioned, you might even be able to
>>> register the trusted DC subscriber only for the content types for
>>> which it makes sense (the forum, I guess).
>> 
>> I think implementing trusted event handlers is the way to go. Given
>> they're adapters, it should be a matter of hooking up 'trusted' via
>> the meta configure. 
>> 
>> It's certainly an inconsistency that normal adapters can be trusted,
>> but event handlers can't.
> 
> Maybe I'm missing a subtlety (handler vs. factory, maybe?) but this is
> already available on the HEAD, if I understand you.
> 
> http://127.0.0.1:8080/++apidoc++/ZCML/
> http_co__sl__sl_namespaces.zope.org_sl_zope/subscriber/index.html
> 
> (or see zope.app.component.metadirectives.ISubscriberDirective)
> 
> I think I've used these (trusted subscribers)...

Heavens to Murgatroid! You're right!

So, 'subscriber' does indeed allow one to setup a trusted event handler,
which gets unproxied objects. I wasn't able to protect access to the
handler with a permission -- there appear to be some bugs:

- When specifying a permission, the directive wants a 'provides' else it
fails inelegantly. I would imagine the fix is to use 'Interface' with
InterfaceChecker whenever provides is None.

- When specifying a permission, one can't use multiple fors, else the
directive complains about having too many facrtories. The permission
related code appends a 'proxify' factory, so this might be a bogus
error.

In any event, the short term workaround for Albertas would appear to be
to mark the DC time handlers as trusted (with a XXX :) When the
subscriber directive is cleaned up to work better with permissions, we
should protect the DC time handlers, probably zope.ManageContent.

Are we close?

 -- Garrett