bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Bloodhound installation issue(s)?
Date Tue, 17 Sep 2013 18:23:03 GMT
On 9/17/13, Jared Duncan <j@jdunk.com> wrote:
>>
>> Also is there somewhere that clearly explains the n:m relationship
>> between
>> bloodhound installations, environments, products, wikis, and
>> repositories?
>>  e.g. "per bloodhound installation, there can be many environments, each
>> environment can have many products, only one wiki per environment, shared
>> by all products," etc,
>>
>
> Let me add "users"

global

> and "permissions"

per-product ... except TRAC-ADMIN , which is a special case since it
is reserved for environment-level power users all over :

  - TRAC_ADMIN will only be asserted considering rules in global scope
  - ... and all other instances of TRAC_ADMIN in any product scope
    will be ignored ...
  - also PRODUCT_ADMIN in product context is reserved for power users
    for resources delimited within the boundaries of target product.

> It appears the
> scope of users/permissions is "site/project/environment-wide",

no

> i.e. if Joe
> has "ticket_admin" permission, he does so for all products under the
> project/environment/site.

at least not by design ... if that happens , it's a bug . he fact fact
is that authenticated users are granted with a set of permissions
(including TICKET_ADMIN ;) immediately after it's created .

> But if there is another product which needs to
> *not* be accessible to Joe, this product would need to be set up under a
> different environment/site.

no , you have two levels of security to enter product context .
Firstly PRODUCT_VIEW , secondly specific permissions TICKET_* , WIKI_*
, ...

> If Joe needed read-only access, a 2nd "joe"
> user could be added to the 2nd environment/site, and this
> separate-user-same-person joe could then be granted read-only privileges
> for all products under that environment/site.

you should just use product admin <prefix> permission
(add|remove|list) ... soon you'll notice that permissions are
independent .

> Does that sound about right?
>

afaict , I'd never design (use) a multi-product system as complex as
such approach you describe . Bloodhound MP architecture is aimed at
encouraging sharing (when appropriate) and isolation (again when
appropriate ;)

-- 
Regards,

Olemis - @olemislc

Mime
View raw message