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: > [...] >>>> There are also a couple of regressions wrt. the multiproduct branch, >>>> those >>>> should probably >>>> be fixed first (e.g. PRODUCT_XXX permissions not set/copied when creating >>>> a >>>> new product). >>>> >>> >>> The permissions policy developed in #438 will grant product owner with >>> PRODUCT_ADMIN permission even if not assigned explicitly . Maybe there >>> is a good reason to add that permission in product perms store too , >>> but not strictly necessary . >>> >>> 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. > > 1. Let product owner change it by hand since (s)he might want > only a few users to interact with that product. > 2. configure product to be visible by anyone immediately > after creation ... and if so permissions needed to be added > on product resource change (create) . > >> 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 =) > >> 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). > > 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. > > -- > Regards, > > Olemis. Thanks, -- matevz
