[dev] Horde_Group Refactoring for Horde4

[Chuck Hagenbuch]

Quoting Ben Klang <ben at alkaloid.net>:

> Hello all,
>
> In IRC recently a few of the developers have been discussing the  
> refactoring of the Horde_Group library for Horde4.  There is already  
> a wiki page in progress (http://wiki.horde.org/HordeGroupAPI) to  
> that effect.  One item discussed is the complexity from having the  
> ability to nest groups.  This enables a structure like
>
> ParentA
>   -> Child1
>   -> Child2
> ParentB
>   -> Child3
>   -> Child4
>
> This structure can be seen in Horde's administration screens.
>
> However what is not clear is how those groups relate.  This brings  
> up difficult-to-answer questions like:
> * Is a member of the group Child1 automatically a member of ParentA?
> * If permissions are granted to ParentA, do they automatically apply  
> to Child1 and Child2?
>
> If you answer "yes" to both questions above then an Administrator  
> does not have a convenient way to view all of the group memberships  
> or security settings in effect for a given user.  It also  
> complicates things like sending notification messages to a group  
> (like in the ticketing system or the wiki) because there is no  
> immediate way to view all of the users in the group.  The more  
> recursion we allow, the more abstract this becomes and the harder to  
> manage.
>
> Certainly these issues can be addressed, but my question is: do we  
> really need this complexity?  Horde apps do not make use of this  
> feature today in any meaningful way.  My vote would be to eliminate  
> the complexity (both in code and UI) and provide a simpler, flat  
> group model.

I would vote to make groups flat, but if possible, to allow groups to  
be members of other groups. Not children in a tree, but flat members.  
That way questions are always based on whether or not the group being  
originally checked contains the user, or a group that contains the user.

-chuck