Alec Thomas wrote:
...
because the attachment module and its parent are co-reliant.
To make this work we'll need to have "sub-realms" for each realm that
supports attachments.
eg.
wiki
wiki//attachment
ticket//attachment
(or whatever syntax is decided on for separating contexts/realms)
That way a user can individually grant attachment permissions on
different parent objects. Actually, thinking about it, this will
alleviate the need for an ATTACH permission altogether, as "CREATE" in
the wiki:attachment security realm would provide this permission.
Using the 'VIEW', 'CREATE' and 'DELETE' permission actions for the
attachment itself works quite well, given that a context for an
attachment is always parented in another context (of a wiki page, a
ticket, ...).
I wanted to be sure that the approach we were taking in that branch
could be extended to attachments, and this seems indeed to be the case.
It's also quite trivial to add security policies for things that are not
really Trac resources, as it's easy to create contexts for anything (see
e.g.[4599]).
So I think the original goals of the PermissionPolicy plan can be
fulfilled, except for the minimal impact on the API part ;) The current
API looks quite fine to me, and behaves quite well: for example, when
some attachments are protected, they can't be seen in the timeline, same
for private tickets (not showing up in searches, shown as missing when
written as TracLinks), etc.
Finally, the permission cache has been set back to the level of the
request, where it belongs (see r4601).
I think it's a good time to get some more feedback on the branch.
-- 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
-~----------~----~----~----~------~----~------~--~---
