[dev] Horde 3's 'admin' roles in application context (observed in sesha)

[Michael J Rubinsky]

Quoting Ralf Lang <lang at b1-systems.de>:

> I just browsed around the sesha code and noticed that H3's Horde_Auth had the
> capability to promote a user into "admin" role for the current context based
> on a perm. Admin stuff seems to have moved out of Horde_Auth into Horde_Core
> (class Horde_Registry).
>
> In Horde 4 I did "Finer grained Admin privileges through permission api"
> ( http://bugs.horde.org/ticket/9350 ) and it got accepted.  
> Originally this was
> a patch targeted at H3 but I think it never went in there for good reasons.
>
> For Sesha in Horde 4 consistency with the same logic would mean to turn all
> Horde_Auth::isAdmin(sesha:admin) calls to registry->isAdmin() || $perms-
>> hasPermission(sesha:administration, ... ) or drop the isAdmin thing
> altogether.
> I am not certain what would be consistent with existing apps.
>
> In Kronolith, global admins or isAdmins seam to have much expanded  
> access (but
> not completely - they don't see calendars without show privileges).
>
> However, admins (and only admins) have access to a resource's events.
>
> System shares can also only be edited by isAdmins.
>
> In wicked H4 otoh each item can be edited either by perm or by  
> isAdmin(). This
> is consistent with H3 where it used Horde_Auth::isAdmin() but never used the
> permission argument to that method.
>
> 1) Should sesha use permissions or isAdmin or both for "admin role"?

I would say both. IMO $registry->isAdmin() should always infer  
$perms->hasAppPermission(...). This way we can say  
$registry->isAdmin() can do anything, but  
$perms->hasAppPermission(...) can only do the specific things that we  
allow.

> 2) Should an app-specific admin permission or a (system share/resource)
> specific admin permission be added to apps which use (system shares/kronolith
> resources)?

For kronolith, at least, my opinion would be to have two specific  
perms. A resource perm and system calendar perm. This allows different  
people to be allowed to manage resources without them having  
permission to change events on system owned shares. These are likely  
to be different people in most (larger) organizations.

For other apps, I would say in general that if an app requires some  
sort of "admin" role, it should be separate from the  
$conf['auth']['administrators'] admins. This provides the most  
flexibility in delegating certain tasks to users without giving them  
admin access to the whole install.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org