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

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> 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.

Agreed.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/