Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAKoya90kZMSkPQJ+zH3TV92UV=cntsX=mXyeJ3uYO8fVmKHQyA@mail.gmail.com>
References: 
 <CAGMZAuPPhjfGx4QgKz_-5udbGncr4PSp-n=xXYO7N0cMkko4jw@mail.gmail.com>
	<CAHM0gngAMBS8DGYfTc4q5R3rv6A8x6GS1mHLHNEoU3KVQ2davA@mail.gmail.com>
	<CAKoya90kZMSkPQJ+zH3TV92UV=cntsX=mXyeJ3uYO8fVmKHQyA@mail.gmail.com>
Date: Tue, 22 Jan 2013 15:57:23 +0100
Message-ID: 
 <CAJSKAsiUYgpL=EaQuuLnZ5k+EkX-QWv85uc163FGmnzZmpVFcg@mail.gmail.com>
Subject: Re: [BEP-0003] [RFC] Permissions in product scope
From: =?UTF-8?Q?Peter_Ko=C5=BEelj?= <peter@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d044630069a6c7d04d3e1cb08

--f46d044630069a6c7d04d3e1cb08
Content-Type: text/plain; charset=ISO-8859-1

I agree with Joe here but we still need to find a technical solution to
make it all work here.
I must say I do not completely understand the diference between what Andrej
and Olemis are suggesting in one key point:

We do need to say that every product administrators also has a role of
TRAC_ADMIN in his product scope (to make the admin page and plugins
working). So Andrej suggest that we do that unconditionally and Olemis
suggest that we do that conditionally.

Question for Andrej: How do we prevent product administrators from changing
system level settings?
Question for Olemis: How do we do that conditional TRAC_ADMIN role thingy
to prevent changing product administrators from changing system level
settings?

I imagine that the hard part is the same in both proposals and that the
differences are only a small implementation detail.

The real question for me is: while all this seems useful, is it important
enough to complicate things at this point in time?
Do not get me wrong, I do think it should be solved sooner than later, but
it should not block us form rolling out a multiproducts without it.

Peter


On 22 January 2013 14:43, Joachim Dreimann <joachim.dreimann@wandisco.com>wrote:

> I'm a bit concerned about the complexity of some of those suggestions. I
> think they should be:
>
> 1. Product owner(s) === PRODUCT_ADMIN;
> 2. Administration area is the same for all admin levels, just filtered by
> permissions.
> 3. Product owners have control over the product, not the environment (as
> Olemis suggested).
>
> I believe it should be our goal to take more of the functionality of the
> 'admin' screens (especially the Ticket System section) and display them in
> the regular UI itself.
>
> That sums it up for me.
>
> - Joe
>
>
> On 22 January 2013 13:15, Andrej Golcov <andrej@digiverse.si> wrote:
>
> > > 7. At present components check for TRAC_ADMIN permission explicitly .
> > > Some checks might be true for product admins but others do not.
> > How does Trac should know when it is the case? That can be quite
> > complex and and potentially brings inconsistent behavior.
> >
> > I have in mind a little different solution that also has some
> > drawbacks but provides consistent behavior:
> >  - Site Admin has TRAC_ADMIN permission for parent environment.
> >  - Product Admin has  TRAC_ADMIN permission for specific product
> > environment.
> >  - Check TRAC_ADMIN permission in product environment should return
> > True for Site Admin. IOW, Site admin is also admin for all products.
> >  - Site Admin UI has it's own url and is executed in parent
> > environment e.g. http://bla/main/admin - The functionality of the UI
> > can be quite different from Product Admin UI, e.g. User management
> > must be part of this UI.
> >  - Product Admin UI has it's own url and is executed in product
> > environment  e.g. http://bla/main/productX/admin - Product admin can
> > assign product specific permissions to user but cannot CRUD users,
> > change system specific settings.
> >  - Product environment should protect from changing of system settings
> > and multi-product instances such as Users. For example, Product Admin
> > (with TRAC_ADMIN permission on specific product) cannot change DB
> > connection string. That can be tricky :) I don't yet feel myself
> > confident enough to say how this can be implemented. May be kind of
> > black list of system settings?
> > Comment, please.
> >
> > Regards, Andrej
> >
>
>
>
> --
> Joe Dreimann
> UX Designer | WANdisco <http://www.wandisco.com/>
> *
> *
> *Transform your software development department. Register for a free SVN
> HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
>

--f46d044630069a6c7d04d3e1cb08--