Alec Thomas wrote:
> ...
> 2. Add an interface that allows plugins to declare which permissions are
> valid for attachments in their realm. The LegacyPermissionPolicy
> could then do the job of remapping permissions.
>
I'm fine with this. Ideally, the fine-grained permissions should be
simpler to add, like by having the authz_policy be active by default and
have an admin panel for it. But in the meantime, I think that plugins
that want to save their users the pain to configure the fine grained
permissions just for enabling attachments, they could plug into the
legacy permission policy, which should itself have an extension point.
class ILegacyAttachmentPermissionProvider(interface):
def map_attachment_permissions():
"""Return a dictionary which maps the 'ATTACHMENT_CREATE',
'ATTACHMENT_MODIFY' and 'ATTACHMENT_DELETE' keys
to existing permissions"""
Example implementation for the ticket module:
def map_attachment_permissions(self):
return {
'ATTACHMENT_CREATE': 'TICKET_APPEND',
'ATTACHMENT_VIEW': 'TICKET_VIEW',
'ATTACHMENT_DELETE': 'TICKET_ADMIN',
}
> If anybody can think of a better way of solving this, it would be great
> to hear about it.
>
Well, in the future I'd like to gradually get away from permissions that
encapsulate the realm name into the action name itself, as this is
becoming redundant now that we can check the permission on the realm. So
that's why I don't like so much the proposed solution 1. Solution 2 is
OK as it goes with "legacy" in its name ;-)
-- Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
