On Wed, Nov 13, 2013 at 3:44 AM, Olivier Mauras <[email protected]> wrote:
> On 2013-11-12 21:41, Olemis Lang wrote:
>
>> Unless I missed something or a regression has been introduced in /trunk
>> that's exactly the case . This is enforced by the multi-product
>> permission
>> policy [1]_
>>
>> I join you a screenshot that shows that it's not.
>
hmmm ... I did not received the screenshot .
> And to my understanding it is because of not returning the handler if "not
> req.perm.has_permission('TRAC_ADMIN')" in the product admin.
> By removing this check product panel admin becomes available to the owner
> _without_ giving access to other admin panels. At least that's what my
> tests are showing :)
If you please could write a test case for this and show that it fails,
that'd be nice to follow from there .
> Nevertheless there's a difference between Trac and product admin role .
>> The
>> former are site admins , i.e. they have access to the file system , sudo
>> etc ... whereas the later only manage product resources e.g. tickets ,
>> wiki
>> , ... If you could list all the instances we fail at doing so we'll be
>> looking forward to improve them asap
>>
>> I see the repositories as a product ressource
>
I do not (generally speaking ;) , indeed the same repository may be shared
and connected to multiple products , which is the case for e.g. library
code . For instance , Bloodhound mirror is available in
blood-hound.netenvironment and it actually does not belong in any
product , but should be
linked to all products because, in the end, all packages developed in there
depend upon BH core .
> they can ...
>>
>> Not really they can only link to a globally available repository...
> which beats the product isolation.
yes and no ... depends on your viewpoint and use cases. If you mean that
there's room for enhancements , yes , definitely ; but repositories
... but yes , there is a reason and it's due to the Trac vs product admin
> roles mentioned above . Trac repository connectors operate on repos cloned
> in the local file systems (or equivalent ;) therefore adding a new one
> happens outside the web site boundaries is more like a task of site admins
>
> I don't think this matters much. Even if the product owner doesn't have
> access to filesystem this shouldn't prevent him to enter a path given to
> him by the "bloodhound server admin"
>
I do think this matters . I'm not very fond of publishing server paths (...
neither do the admins in my team ;). By establishing a convention (e.g.
/opt/vcs/<vcs_type>/<repos_name> where vcs_type = hg | svn | git ... ). The
product admin wouldn't even need to worry about server-side filesystem
paths ; they'll only need to know the vcs type and repos name . That's just
an example ...
In any case the current implementation still implies that only TRAC_ADMIN
users may create new repositories, and always outside web UI . IMO it would
be nice to integrate those operations too in forthcoming releases for an
enhanced user experience . Nonetheless in order to do so new (or enhanced)
entry points will be needed .
--
Regards,
Olemis - @olemislc
