Hi,
Thanks to Christian's work, we're getting closer and closer to a
releasable 0.11. One thing I think we need to fix before that release
though, is the attachment system.
This mail is basically a solicitation for ideas on how to improve the
attachment module permission handling.
Here's the current state:
- The attachment module no longer has a hard coded list of permissions
for each 'attachment point' (eg. WIKI_VIEW, TICKET_VIEW, etc.). This
is a good thing.
- The attachment module uses ATTACHMENT_* permissions internally. This
theoretically allows the module to be reused by external plugins.
- LegacyAttachmenyPolicy maps ATTACHMENT_* permissions for wiki,
ticket and milestone attachments to their 0.10 equivalents.
(see BACKGROUND below for why this
This is functional for Trac internally, but makes it tedious for authors
of plugins wishing to use the attachment module. They have to implement
their own IPermissionPolicy and the end user has to ensure that the
policy is inserted correctly into [trac] permission_policies. This is
tedious and error prone.
Proposals:
There are a couple of alternatives I can think of, but I'm not sure
they're that great:
1. Auto-generate "default" permissions for all realms that are valid
attachment points. Add an interface for declaring realms that accept
attachments, and generate <REALM>_ATTACHMENT_{VIEW,DELETE,MODIFY}
permissions for each. In conjunction with LegacyAttachmentPolicy,
this allows 0.10-style attachment permissions to keep working, while
adding more explicit attachment permissions for administrators, and
allowing arbitrary plugins to utilise the attachment permissions.
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.
If anybody can think of a better way of solving this, it would be great
to hear about it.
Alec
BACKGROUND:
Because we have to support the <= 0.10 "legacy" permissions for wiki and
tickets cboos introduced a policy that internally maps the new
permissions to the old ones. eg. A check for ATTACHMENT_VIEW on an
attachment on a wiki page is mapped to WIKI_VIEW, and so on.
If an installation is completely relying on a policy plugin like
AuthzPolicy, only the ATTACHMENT_* permission need be used and it all
works nicely. One simply uses the full "path" to the attachment in
conjunction with the ATTACHMENT_* permissions to apply permissions. eg.
[wiki/WikiStart:attachment/image.jpg]
* = ATTACHMENT_VIEW
--
Evolution: Taking care of those too stupid to take care of themselves.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
