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

[Ralf Lang]

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"?

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)?

I'd vote for both on 1) but I am uncertain on 2).

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537