[dev] [cvs] commit: framework/Group/Group ldap.php

[Ben Klang]

On Nov 24, 2006, at 3:27 PM, Ben Chavet wrote:

> That's exactly the problem, then.  Apps shouldn't be  manipulating   
> nested
> groups in a driver-specific manner.  They should be using getparent 
> () or
> getchildren() (or whatever the equivalent is, I don't have the code  
> in front
> of me) API calls, and the backend driver should handle the parent/ 
> child
> relationships.
>
While getParent() and getChild() certainly have their use, I don't  
think that they are sufficient to fully support a nested groups  
implementation.  I believe there must be an unambiguous way to  
address a group without knowing the backend-specific group ID.


>
> The group API should be completely backend-independent.  In other  
> words, a
> group has a unique ID, a name, a list of members, and optionally a  
> parent
> and/or children groups.  The unique ID should always be used when
> referencing the group, and the API calls should be used to handle
> parent/child relationships.
>
I'm completely in agreement on group APIs being backend-independent,  
but I don't think that having a notation (colons or otherwise) to  
represent fully qualified groups makes an API backend dependent.  In  
other words, the colon separation notation for a group may have first  
been used by DataTree, but I think it should still be valid for LDAP  
(and in some cases, applications are using that notation already).   
When I was reading the applications dealing with groups, I generally  
saw the app ask the group driver for the Group ID by name, then would  
do all group manipulations based on that ID.  This level of  
abstraction is a very good thing in my opinion.


> The longname vs. shortname is a side effect of
> the datatree backend, and we should shy away from distinguishing  
> the two.
>
>
I never saw it as a side effect, but as a handy way of working with  
groups.  There are places in the UI where you might wish to use the  
short group name, and others where the long group name is preferred.   
Making the applications (potentially) aware of group relationships  
is, I think, a good thing.


> We should also move away from using getGroupId(name) because of the
> ambiguity potential.
>

I disagree here.  Why would we not want to use getGroupId(name)?   
Personally I'd rather see all group storage done by name, even in  
prefs, permissions, etc storage.  By storing (and referencing) groups  
by name, the ID becomes internal to the Groups driver and migrating  
from (example) DataTree to (example) LDAP does not mean going through  
all the share, application, wiki page, ticket queues, etc permissions  
updating DataTree group IDs (which are integers) to LDAP group IDs  
(which are strings/DNs).


>
> Oddly enough, I changed this back because LDAP groups were broken  
> for me
> when setting up a fresh LDAP-based test environment, and this is  
> what it
> took to make it work :)
>
I'm surprised as well :)
We should compare notes on how our LDAP environments are set up and  
see if there is some common ground here.  I originally committed  
these patches because nested groups were non-functional for me.  If  
they broke something for you, I'd like to better understand what was  
broken.

-- 
Ben Klang
Alkaloid Networks
ben at alkaloid.net
404.475.4850
http://projects.alkaloid.net