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'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.

Right, that was pretty much what I was thinking.

> 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 ;-)

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.

The major advantage of option 1, I think, is that it makes it explicit
for users which permissions are used for attachments:
WIKI_ATTACHMENT_VIEW, BLOG_ATTACHMENT_DELETE, etc.

This is good from a user perspective, and would also allow us to easily
migrate permissions to whatever new permission model we use in the next
version. That is, we could potentially auto-populate the new permission
store with those from the permissions table.

Still, either would work. Anybody else got some thoughts?

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to