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'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. >
Explicit but perhaps not that practical. Remember we're talking about the default permission policy, where permissions have to be granted explicitly and that means more work using either trac-admin or the current permission panel, the latest being not that user friendly for adding permissions (*). With option 1. you'd assign the permissions for the new realm (e.g BLOG_VIEW) and have that reused automatically for attachments, without having the need to add another explicit BLOG_ATTACHMENT_VIEW permission. That means /less/ work in the common case for the plugin users, for a bit more work for the plugin writer. And if the user wants more control, he can always do it with the ATTACHMENT_VIEW permissions using the authzpolicy. > 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. > I see. But for approach 2. we have the same base information, only less "rough-grained" control possibilities (i.e. you couldn't allow BLOG_VIEW and deny viewing the BLOG attachments like with 1). It would be possible to create the initial set of attachment permissions as well. (*) I'm not exactly against solution 1. The only big reservation I had was that I was thinking about that drop-down list in the permission admin panel, and seeing that list grow longer and longer... I think it's quite tedious right now to add permissions. OTOH, it's pretty easy to remove a bunch of them, so I'm thinking about this little enhancement: what about an "all permissions" entry that would add all the available permissions at once? Then it will be possible, in a second step, to conveniently select the permissions that should be removed. > Still, either would work. Anybody else got some thoughts -- 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 -~----------~----~----~----~------~----~------~--~---
