[dev] Permissions - possible changes

[Jason M. Felice]

Quoting Chuck Hagenbuch <chuck at horde.org>:

> As we move towards Horde 3.0, I'd like to make sure that the 
> permissions system
> is robust and flexible enough to support us both now and going forward. There
> are two potential modifications which may or may not be good ideas that I'm
> looking for feedback on.
>
> 1. Add more permissions levels.
>
> Right now we have PERMS_SHOW, PERMS_READ, PERMS_EDIT, and PERMS_DELETE. Some
> other permissions systems have more levels, and we could potentially follow
> that - PERMS_ADD comes to mind. Other possibilities would be PERMS_ADMIN,
> PERMS_COMMENT, PERMS_MODERATE, etc.
>
> Do we need more levels? I'm not sure we do. Could some of them be 
> useful? Sure -
> I'm just not sure it's worth it. I'm interested in what the whole development
> community thinks, though.
>

In our other framework, we originally had four (select, insert, update, 
delete).
   We needed more fine-grained permissions (for particular actions like 'import
Excel spreadsheet', for example) on some screens.  At first, we kludged
separate objects for those permissions, but we eventually extended the system
to allow arbitrary permissions for any object and the object interprets them
however it sees fit.

The permissions models _are_ different.  In the our old framework, permissions
are attached to classes (which are actually PHP classes), in Horde the
heirarchy is arbitrary.

In a nut shell, I think the ideal solution is to have basically those 
four, and
the system handles those, but additional ones can be specified by particular
objects.  Things come up like "what if we don't want to give this user access
to the "Mutilate" button?"


>
> 2. Make permissions levels additive.
>
> Right now, PERMS_DELETE does not imply any other permissions - it 
> just lets you
> delete things. This is very flexible, but I'm not sure it's useful in 
> practice.
> It also means that we have an additive bitmask which is, again, flexible, but
> more complicated than a simple level of access.
>
> We could change to having each level of permissions imply all the 
> others - i.e.,
> you have *either* SHOW, READ, EDIT, or DELETE. For one thing, this would
> greatly simplify the permissions editing screens.
>
> This would actually remove an amount of flexibility, in exchange for 
> simplicity
> and making it more intutive for users (I'm not sure that it's obvious 
> now that
> you need to make sure to give someone all 4 levels of access to your shared
> calendar, for instance, or SHOW, READ, *and* EDIT to let them add events,
> etc..).
>
> Thoughts?

I prefer the flexibility, and this is from experience.  On the other 
hand, I may
not be the typcial user.  Do we have any idea what the typical user might
expect?

--
  Jason M. Felice
  Cronosys, LLC <http://www.cronosys.com>
  216-221-4600 x302