On 4. Apr, 2013, at 2:01, Olemis Lang wrote: > On 4/3/13, Matevž Bradač <[email protected]> wrote: >> On 3. Apr, 2013, at 17:39, Olemis Lang wrote: >>> On 4/3/13, Matevž Bradač <[email protected]> wrote: >>>> On 3. Apr, 2013, at 8:49, Olemis Lang wrote: >>>>> On 4/2/13, Matevž Bradač <[email protected]> wrote: > [...] >>>>> Is there anything else to do about this ? >>>> >>>> It seems so - when creating a new product, the product is created but >>>> cannot >>>> be viewed due to PRODUCT_VIEW permissions missing. >>> >>> You mean product owner can not access product resources ? If that's >>> the case this is an issue (test case coming soon ;) . If this is about >>> any other user , then there are two options : >> >> Yes, that was the issue - the product was created by admin in this >> case, and after creation the "PRODUCT_VIEW privileges are required >> to perform this operation." error occurs. >> > > This should be fixed (for TRAC_ADMIN users) after applying the > patch(es) mentioned in comment:15:ticket:438 ..
Thanks for the patches, PRODUCT_XXX issue is now fixed. =) I reran the tests and committed both t438_r1463560_product_perm_tracadmin_all.diff and t438_r1463560_newproduct_perm.diff in r1464333. > . > > [...] >>>> Note that this only >>>> happens >>>> with newly created products, the default one (@) works as it is. There >>>> are >>>> no >>>> PRODUCT_XXX permissions in the permission table for either of them(which >>>> should >>>> be okay). I haven't found the root cause yet, still checking the code. >>>> >>> >>> I'll write some test cases . Let's see where do we get from there >>> ;) >> >> OK, great =) >> > > see comment:16:ticket:438 > >>> >>>> On another note, a product need not have an owner (and IIRC that's the >>>> default >>>> behaviour), how should the permission policy behave in that case? >>>> >>> >>> Just like any other permissions policy . If you'd own I'm sure you'd >>> agree with me that it'd be quite annoying if suddenly you delete your >>> own permissions by mistake (or not) and can not access product URLs >>> afterwards . That special case in code is aimed at >> >> Sounds fine to me. I just wanted to emphasize that by default the owner >> is empty. In that sense the "product owner cannot access the product" is >> not the primary issue, but rather that nobody can access it (not even >> admin). >> > > If product owner is not set by default then TRAC_ADMIN users will have > to setup permissions for everybody else . > > Notice: based on my previous professional experience that will lead to > some trouble between development and devops (departments ?) because > either the later will be forced to assume this responsibility which is > easily delegated to e.g. project team leaders or the former will end > up having more access than tolerated in some (many) enterprise > deployments. > > IOW , this is the equivalent to : > > - All users contacting (Bitbucket | Github | ...) employees for > support so that repository creator (i.e. owner) will be > granted with permissions to manage his/her own repository. > > ... etc, etc ... I don't think it's a good idea to set empty owner by > default . If not specified explicitly it should default to > req.authname ... or maybe something else ... > > Of course , permissions setup for new products may be customized by > implementing resource listeners . Therefore the architecture will not > constrain users willing to do smething else . I completely agree here. I found it strange that in the default "add product" form (/main/products?action=new), the owner field is not even present. So I think your suggestion of using the req.authname as the owner sounds good. In the admin add product (/main/admin/ticket/products) the owner field is present however, which supports your suggestion even more. For this form I'd say that at least a warning should be issued if no owner is specified, and perhaps the owner should be set to req.authname here as well. > >>> >>> Not to have a product owner sounds a bit bizarre to me now. I'd >>> suggest to require owner field in new product form , as that very same >>> user will be responsible for managing product perms et al. at the >>> beginning . Otherwise , if empty , (global) TRAC_ADMIN intervention >>> will always be required . We might support both use cases by providing >>> a bool option e.g. `require_product_owner` in `[multiproduct]` section >>> ? >> >> Well it all boils down to what a product owner should really represent. >> Is this a product admin that can create milestones/versions etc. or >> something else? Is the owner constrained to users with PRODUCT_ADMIN >> rights or can it be any user? Etc etc. >> > > The logic is all the way round . Product owner will always be a > product admin , but the opposite will not be true . Product owner may > be transfered to any other imaginable user and auto-magically (s)he > will receive PRODUCT_ADMIN super-powers in product scope , regardless > of whatever rules are stored in permissions store or decisions > enforced by enabled perm policy components . > > Along the way we'll realize that product owner will be able to perform > actions not alloed for product admins e.g. transfer product ownership > to other user . Ok, this also makes sense to me. > > Also recall that there's no such thing like permission schemes for new > products . That's a TODO (see #495) . > ;) > Then there's also #408. =) > -- > Regards, > > Olemis. Thanks. -- matevz
