Extension Point : ILegacyAttachmentPolicyDelegate
The ILegacyAttachmentPolicyDelegate implementations define how to check for
ATTACHMENT_* permissions for different realms.
The TracPermissions system defines coarse permissions to control which users have access to which modules. TracFineGrainedPermissions introduced more fine grained control over permissions for individual resources. The IPermissionPolicy interface is used to implement this new system, re-implement the legacy behavior and allow plugins to extend the permission policies.
Attachment permissions are not really separate permissions and can not e.g. be specified in the Admin interface.
IPermissionPolicy implementation) handles the legacy attachment permissions
ATTACHMENT_DELETE. For the ticket, wiki and milestone realms, it maps them directly to
MILESTONE_* permissions on the parent resource. Attachments are child resources, and this delegates attachment permissions to their parent resources'. (E.g., if a user has the permission to modify a page, that user can also attach a file; permission to delete a page also gives permission to delete an attachment, etc.)
Plugins that implement other resource realms and also support attachments can implement the
ILegacyAttachmentPolicyDelegate interface. This allows extending
LegacyAttachmentPolicy with similar mappings.
ILegacyAttachmentPolicyDelegate implementations are only used if the
LegacyAttachmentPolicy is listed in the permission_policies configured in trac.ini.
These policies are called for user actions on a attachments. They can explicitly allow or deny these action, or abstain to defer the check to the next policy in the chain. For attachments to realms other than ticket, wiki or milestone, the
LegacyAttachmentPolicy will defer to
A minimal ILegacyAttachmentPolicyDelegate in isolation is not very useful (but possible) and usually accompanied by implementations of other interfaces that request and require these permissions. Hence the following example is best understood in context of the ComponentModuleExamples.
In Trac components have no attachments. One could extend the ComponentModuleExamples to implement support for such attachments. The following example maps attachment permissions to component and ticket admin permissions:
from trac.core import Component, implements from trac.attachment import ILegacyAttachmentPolicyDelegate class ComponentModule(Component): implements(ILegacyAttachmentPolicyDelegate) def check_attachment_permission(self, action, username, resource, perm): if resource.parent.realm == 'component': if action == 'ATTACHMENT_VIEW': return 'COMPONENT_VIEW' in perm(resource.parent) elif action in ('ATTACHMENT_CREATE','ATTACHMENT_DELETE'): return 'TICKET_ADMIN' in perm(resource.parent)
|Plugin||maps attachment permissions to||for attachments to resources of realm||Notes|
|AtomPub Plugin|| || |
|Bitten|| || |
|th:ExoWebCodeReviewPlugin|| || |
|th:FullBlogPlugin|| || ||Performs some additional logic.|
|MailArchiveExtPlugin|| || |
|TracTalkPlugin|| || |
|trac-testmanagement-plugin|| || |
|th:ExtendedVersionPlugin|| || |
|th:DiscussionPlugin|| || |
Additional Information and References
- API Reference
- See IPermissionPolicy
- Initial development: mailing list archive
- Related tickets:
- This interface is sometimes referred to as
- Why Legacy?
- The idea was that this mechanism would no longer be necessary once it becomes easier to setup fine-grained permissions in the default permission store.