incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [BEP-0003] [RFC] Permissions in product scope
Date Wed, 23 Jan 2013 00:19:07 GMT
On 1/22/13, Andrej Golcov <> wrote:
> Let's take a use case.


> Do we want to allow a ProductAdmin to change workflow for the product
> and do we want to use existing plugins for this purposes?

Definitely yes .

> If the answer is yes, let's assume, that we decided to use
> TracWorkflowAdminPlugin [1] for this purpose.
> If we look in TracWorkflowAdminPlugin code [2] we can see:
> ...
> class TracWorkflowAdminModule(Component):
>     implements(IAdminPanelProvider, ITemplateProvider,
>                IEnvironmentSetupParticipant)
> ...
>     # IAdminPanelProvider methods
>     def get_admin_panels(self, req):
>         if 'TRAC_ADMIN' in req.perm:
>             yield ('ticket', dgettext("messages", ("Ticket System")),
>                    'workflowadmin', _("Workflow Admin"))
> ...

This example illustrates a good part of the underlying complexity involved ...

> As far as I understand the code,  (TRAC_ADMIN' in req.perm) should be
> True if we want the plugin working.

Yes .

> So far, we discussed two possibilities how to solve the problem:
>  - ProductAdmin has TRAC_ADMIN permission for product environment

... which implies actually render the admin panels (e.g. workflow
admin) to product admins . The main issue is that Trac , and plugins
do not differentiate sensitive from cosmetic admin tasks .

>  - ProductAdmin has PRODUC_ADMIN permission but in some circumstances
> ('TRAC_ADMIN' in req.perm) still returns True.

... and in general , it will be hard to delimit the thin line between
«those circumstances» to decide between allow vs deny .

> For sure, there is possibility that I'm missing some important things.

There is a third option inspired on previous comments by Joe

 - Product admin has PRODUCT_ADMIN power-user permission
   acting as a catch-all permission enclosing all others except
   direct checks for TRAC_ADMIN . The later will always fail in product scope.
   Hence product admins may not access product /admin URL space.
   Admin tasks in product scope will be performed via separate
   (yet similar) admin panels requiring only barely minimal
   permissions .

@joe : correct me if I misunderstood something

I'm sympathetic to this approach , as it effectively *should* match my
current expectations for a candidate architectural design .
Nevertheless it is a fact that it requires a lot of extra effort ,
even if most of current admin panels may be reused with minor
modifications . Indeed after all this there are still some open
questions :

  1. Shall we have a parallel architecture built form scratch
      for product admin ?
  2. Shall we leverage current admin architecture by putting
      product admin in context instead ?
  3. Shall we have no product admin section at all thereby
      encouraging add-hoc navigation ?

IMO (3) is way behind from a UX perspective , but in part that's the
navigation experience offered nowadays to users without TRAC_ADMIN
permission but having e.g. MILESTONE_ADMIN . There will be no
«evident» admin section (i.e. neither Admin main nav item nor the
structured and focused navigation seen in admin panels) , but in other
pages (e.g. milestones, roadmap, etc ...) there will be links to pages
for CRUD operations .

OTOH (2) will be entangled between the roots and leaves of the current
admin architecture and beforehand it seems to me that we'd end up
fighting plugin upgrades to support .

At present I'd advocate for a combination of (1) and (3) i.e. a
parallel solution to contribute nav items to a sort of product admin
area (not as structured as traditional /admin section) reusing
existing and new web panels accessible outside /admin area .

That will also allow us to keep the solution orthogonal to plugins
admin code , and follow a DIY approach every time we might require
such Apache™ Bloodhound specific upgrades in a timely manner , maybe
without the express participation of plugin authors . This does not
mean that we'd raise barriers for the participation of hacks authors ,
by default . All the opposite . If plugin authors do it , well , much
better . The fact is that both sides might have a different vision of
the situation , different priorities and development velocity .

btw , these are «thoughts in progress» ... ;)



Blog ES:
Blog EN:

Featured article:

View raw message