bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: First installation... my humble review
Date Wed, 13 Nov 2013 20:08:36 GMT
On Wed, Nov 13, 2013 at 3:44 AM, Olivier Mauras <olivier@mauras.ch> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message