Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olemis@gmail.com designates
 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Date: Tue, 22 Jan 2013 00:01:45 -0500
Message-ID: 
 <CAGMZAuPPhjfGx4QgKz_-5udbGncr4PSp-n=xXYO7N0cMkko4jw@mail.gmail.com>
Subject: [BEP-0003] [RFC] Permissions in product scope
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev <bloodhound-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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
     (PRODUCT_ADMIN)
  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.
WIKI_MODIFY,
     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 ...) ,
      o.O

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 .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: