bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject [BEP-0003] [RFC] Permissions in product scope
Date Tue, 22 Jan 2013 05:01:45 GMT
Hi everybody

I've been thinking about how to deal with permissions in product
context . AFAICS almost
everything should work in a similar way with product environments .
For instance,
the same (store | policy | ...) components should serve to similar
purposes in product
scope. Given that product envs will have their own settings , and their own set
of enabled components , it seems to me that we should keep the same flexibility
under the new circumstances .

The only major difference I see is related to TRAC_ADMIN permission.
In global env
this represent super-user role. There are no restrictions . When
trying to translate
that inside products this is what I think so far :

  1. IMO we should include a new role (permission) , namely product admins
  2. There is a difference between site admins (i.e. TRAC_ADMIN ) and
     product admins . The former are responsible for server resources,
stability ,
     security ... and similar critical tasks . OTOH only a subset of
admin tasks
     may be delegated to product admins , and strictly in product scope.
     To make myself clear , TRAC_ADMIN(s) may install new plugins and configure
     DB connection whereas product admins may not , but they may configure
     a lot of settings (... not all ... e.g. DB connection is one such setting )
     to customize components behavior .
  3. We should come up with some mechanism to effectively delimit both scopes.
  4. Product owner will always be PRODUCT_ADMIN.
  5. Other users may be granted with PRODUCT_ADMIN permission explicitly.
  6. Product admins will be granted with all other permissions (e.g.
     TICKET_ADMIN, ...) in product scope. TRAC_ADMIN(s) super user rights will
     still be effective inside and beyond product boundaries .
  7. At present components check for TRAC_ADMIN permission explicitly .
     Some checks might be true for product admins but others do not.
  8. ... which leads to the question ... should we have a single admin area
     for both TRAC_ADMIN and PRODUCT_ADMIN with actions filtered considering
     permissions ?
  9. Otherwise , should we offer two separate admin sections
     for each role (... and somehow deal with duplicated behavior ...) ?
  10. Considering (2) it seems to me that product admins should not be aware
      of server-side paths ...
  11. ... and thereby IMO for product admins path options should be either
      hidden or replaced with other controls (I'm thinking of something like
      trachacks:IniAdminPlugin) .
  12. ... but product admins should have the freedom of managing repositories,
      maybe create new ones (e.g. empty repos , forks , patch queues ...) ,

I wanted to gather some opinions before modifying BEP 3 and actually
write some code
about it . I'm focused on the requirements , not the actual solution .

PS: There might be much more to consider , feel free to add more items
to the list and/or fork the discussion to a separate thread for more
focused insights on a particular subject .



Blog ES:
Blog EN:

Featured article:

View raw message