bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Mauras <oliv...@mauras.ch>
Subject Re: First installation... my humble review
Date Thu, 07 Nov 2013 16:40:47 GMT
 

On 2013-11-07 17:39, Joachim Dreimann wrote: 

> On 6 November 2013
18:15, Gary Martin <gary.martin@wandisco.com> wrote:
> 
>> Hi Olivier,
Thanks for bringing all that up! On 06/11/13 15:06, Olivier Mauras
wrote: 
>> 
>>> Hello, I met Gary Martin this morning on #trac and
discussing quickly about the look & feel of Bloodhound i ended up
installing it on a test server. Here's a compilation of the points that
i find "lacking": 1/ Blocking points for a production adoption - indeed
that's only my opinion * Product owner should automatically have admin
rights to this product. I plan on using Bloodhound in a multi product /
multi users setup. I can't imagine it working without delegating the
product admin rights to their owners
>> I am pretty happy with named
owners of products, or more generally resources, being given rights
associated with admin of the resource. It might be useful if the
permissions admin settings for a product reflected that in some sense.

>> 
>>> * Products should be able to have their own source repo If
rights are delegated, I don't see any valid reason for owners to not be
able to add their own repos
>> I think that there may be some good
use-cases for this, particularly when combined with the rights to access
the product's admin pages. For instance it could be that a repository
for a product should never even be known about in another product. The
current solution forcing repository definitions globally and allowing
local links means that the admin pages would have to be restricted to
those that are effectively allowed access to all. It could instead be
delegated. In the end, there is still the current requirement that
repositories have to be on disk and a trac-admin command has to be run
by someone with appropriate access to the server but that doesn't fully
justify the restrictions.
> 
> Tabs should remember the place you were
last within the tab context, so
> that you don't lose context every time
to switch tabs. Currently tabs
> always return you back to the landing
page for that tab, which is a poor
> experience in my opinion.
> 
>
Thanks for your feedback!
> 
> Joe
> 
>>> * Not knowing where you are
This is indeed linked to the previous point, wiki and source pages don't
show the product in breadcrumb
>> I would definitely argue for extending
the breadcrumb to go across all pages for this purpose. 
>> 
>>> 3/ Eye
candy * Source browser CSS may not be the easiest to read All lines to
the same color make it difficult to catch things Age color highlight is
too light and/or too close in colors * There's place on the mainnav tabs
As there's place available and that one can enable timeline and roadmap
from base.ini why not add them to mainnav() to not have then in "More"
tab?
>> The timeline has the virtue that it crosses all aspects of the
system. There is probably a case for having a link, particularly if
there are pages that do not have activity areas.

Please find attached
two patches.
First one grants product owner admin rights to his
products, and change the repository management part to the one used by
global one. This makes the product owner to create/delete/alias
repositories. 
For the moment it's global, it would require some changes
at DB level to make the repositories isolated per product. I think a new
table - "product_repositories" - with a new "DbRepositoryProvider" class
would be the less intrusive...

The second small patch modifies the
theme to get "Source" tab to point to product/<id>/browser instead of
getting the wiki.
This indeed gives a "No node /" error as i haven't yet
found my way in the code that would point the product browser to the
repository.

Sorry for the nasty two patches, i worked on installed app
instead of the code... This is all based on the latest stable
0.7.0.

Hope this will help.

Olivier 
 
Mime
View raw message