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 ...
[...]
>>> 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 .
>>
>> 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 .
Also recall that there's no such thing like permission schemes for new
products . That's a TODO (see #495) .
;)
--
Regards,
Olemis.
