On Tue, Sep 29, 2009 at 01:39:28PM +0200, Christian Boos wrote: > > Felix Schwarz wrote: > > Am 28.09.2009 10:56, schrieb Christian Boos: > >> > >> Felix Schwarz wrote: > >>> Hi, > >>> > >>> after playing around with IPermissionPolicy for some time I suspect > >>> that some use case are not really handled well by the current API and > >>> I would like to resolve that for 0.12 :-) > >>> > >>> 1. For every policy check I have to load the db object again even if > >>> the caller has a db object already. Can we make it > >>> resource_or_dbobject? > >> > >> Hm no, that will break the existing API. > > > > That's why I proposed it for 0.12 :-) > > Even there, we prefer to change the API in a backward compatible way, > unless there's really no way to do it differently. > > As for the req proposal, I'd rather not do it this way, as the Request > is tied to the web layer which shouldn't play a role here. In 0.11, I > tried to "unbind" most of the API from the Request, in order to make it > possible to reuse Trac components outside of the web application context > (trac-admin, other scripts). We're certainly not there yet but it's not > a reason for allowing it to make a come back through the window ;-) The > thread local approach gives nearly the same "locality" to the cache, we > already do it for a number of other caches and I think this should > become the preferred way.
+1 on keeping req out of as much as possible. As a plugin developer, I have had to fake a request in various contexts where, strictly speaking, I shouldn't have needed to. On the other hand, be familiar with much of the Trac code, I realize that this makes things challenging, so props to cboos for pursuing this route. Jeff > >>> 2. Say I want to create a policy that prevents users to file tickets > >>> with a specific milestone (this needs triage). How to do that in a > >>> permission policy? > >> > >> I don't think a permission policy is adequate here, at least not in the > >> current model where we don't check permissions on the milestone when > >> creating a ticket. So maybe the ticket validation approach would be more > >> adequate here (see ITicketManipulator). > > > > The problem with ITicketManipulator is that it could be hard to hide > > the options for which the user does not have sufficient permissions > > already in the edit form... > > I see. That sounds like #8653. See also > http://trac.edgewall.org/wiki/TracDev/Proposals/EvenFinerGrainedPermissions > (the part about extending the target). > > -- 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 -~----------~----~----~----~------~----~------~--~---
