On Wed, Nov 13, 2013 at 3:44 AM, Olivier Mauras 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// 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