On Nov 15, 10:57 am, Christian Boos <[EMAIL PROTECTED]> wrote:
> Alec Thomas wrote:
> > On 11/14/07, Christian Boos <[EMAIL PROTECTED]> wrote:
> >> 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 contend that option 2 is almost worse than option 1 in that
> > respect: it forces plugin authors to add even more legacy permissions,
> > whereas option 1 does not. It's also possible that option 1 would be
> > 100% forward compatible.
>
> > Still, either would work. Anybody else got some thoughts
>
> -- Christian
I've just implemented attachment support for my FullBlog plugin, and
chatted with Alec on IRC as a precursor to this RFC. My experience is
basically:
1) Adore the flexibility of using a permission policy to implement the
support for attachment permissions. For instance I actually have 2
modify permissions in my blog plugin (BLOG_MODIFY_OWN,
BLOG_MODIFY_ALL) where the lower level permission would only allow you
to add and delete attachments if it is your own blog posts - not on
blog posts where you aren't author. Mapping to legacy permissions -
implicitly or explicitly - would be step in the wrong direction. And
certainly having them re-appear in trac-admin or web admin when they
have been gone for years does not feel right.
2) My main qualm about the permission policy was of course having to
add it to trac.ini when it really just extends the a built-in module.
For this I see two alternatives:
a) Make security policies default enabled, but if it isn't specified
in the permission_policy list it will just be checked at random/load
order after the explicityly declared policies. The order can be
resolved by primarily using the trac.ini list, then default trac
policies (if not in specified list), and lastly unspecified policies.
To disable a policy one uses the [components] section like for any
other plugin - it seems to me uncessary to enable the policy both in
components and include it in permission_policies.
b) Make an attachment extension point for the attachment permission
policy that queries the implementor for a resource (attachment) realm
what permission to ask for in each circumstance - forwarding the basic
action (ATTACHMENT_VIEW etc.), username and the parent resource. In my
case above I can then return .._OWN or .._ALL depending on what
resource it is. Then only default policies are in use - with some
help.
:::simon
http://www.coderesort.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
