[commits] [Wiki] changed: HordeGroupAPI

[Ben Klang]

bklang  Mon, 24 Jan 2011 20:39:05 -0500

Modified page: http://wiki.horde.org/HordeGroupAPI
New Revision:  1.8
Change log:  Flatten Groups?

@@ -14,8 +14,30 @@

  For Horde4, we will move away from the object-oriented method of  
managing groups in favor of a Horde_Groups class which will act as a  
group manager.  This should alleviate some of the confusion between  
the different drivers, and eliminate some of the OO overhead.

  Also for Horde4, the way we handle saving groups to the backend will  
change.  Instead of keeping track of the changes and committing them  
to storage when updateGroup() is called, all changes should be stored  
on the fly.  There is a bit of a performance hit for this, but it  
simplifies the API, and group modifications are rare enough and  
deliberate enough that this should not be an issue.
+
+++ Open Questions
+
++++ Flatten Group Structure?
+
+Today the Group subsystem allows for nested groups like this:
+
+
+  !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.

  ----

  ++ Standards