Horde_Group has been completely rewritten since.

After discussion among the core developers, we will modify the 
behavior of the LDAP driver to match that of the DataTree driver, 
fixing nested groups for LDAP.  For Horde 4 we will modify the API so 
there is no problem with group names containing a colon.

Please any suggestions what to do with ldap groups for future? I saw 
that ldap groups driver was able to show nested groups. But later, it 
was changed again to not support it. Today, if we want to use ldap 
groups, we have to use one context for all groups. Nested groups do 
not works.



We made small patch which only ignore dn of the group, so we see all 
ldap groups from entire ldap tree as flat structure if specified by 
config parameter. But it would be much more better if ldap driver uses 
nested groups. Any suggestions ?



I think that ldap driver need to return ous as groups to have full 
nested group functionality.

Looks great, good work!



Committed, thanks!

Ok I have now audited every function and compared the output to 
outputs from the datatree driver.  I'm happy to say that this patch 
brings the LDAP group driver *much* closer to behaving exactly like 
the DataTree driver, especially when it comes to nested groups.



Full list of changes:

* All error messages were modified to include the LDAP error message

* The PHPDOC for the newGroup() method was updated for correctness

* newGroup() now attempts to see if it has been passed a nested group 
for creation.  This is used in Thor and possibly other places.  At 
this point it doesn't try to build out the whole structure above the 
requested group, but it wasn't clear to me if this is desireable.  If 
all the parent groups exist then the group will be created, otherwise 
LDAP will spit a PEAR::Error back.

* Methods which relied on LDAP searches to determine Group Name or ID 
were dangerously imprecise.  If two groups had the same name then 
there was no guarnatee the correct name or ID would be returned.  I 
modified the methods to ensure that the correct name or ID is always 
returned.

* A FIXME warning has been added to the top of renameGroup.  I haven't 
exhaustively tested this method yet and I'm fairly sure it still needs 
to be modified.  The problem stems from the fact that (to my 
knowledge) LDAP objects can't be renamed across branches.  Worse, if 
the object has children they will need to be manually handled.  The 
cleanest way to do this is a copy/detel rather than a rename, but this 
will require some careful design.

* The exists() method has been modified to use an LDAP compare rather 
than a search.  This should dramatically speed up exists() operations.

* The return value of getGroupShortName, getGroupShortName and 
getGroupParents have been modified to behave *exactly* like the 
DataTree version.  Previously they did not behave the same and it 
caused problems in some applications.  Most of the problems were not 
visible with single-level groups.

* Input error checking was added to getGroupParentList()

* A small typo/bug introduced with the members-as-DNs patch has been 
corrected.



I have now exhaustively tested this with applications and took pains 
to evaluate the DataTree outputs relative to the LDAP outputs.  I 
can't proclaim it perfect but I'm very confident it is dramatically 
improved.

As I continued to use the modified driver with nested groups more 
functions appeared that needed modification.  So much for a simple 
change.  I'm going to refactor the code a bit so there is no 
duplication and audit every function carefully to make sure nested 
groups are fully supported.  The patch attached does work, it's just 
incomplete.

Found a couple more methods that needed modifications.  Attached is an 
updated (cumulative) patch.  Hopefully this should be all required 
modifications.

Nested group support is mostly working except that getGroupId() 
doesn't know how to handle colon-delimited group names.  This patch 
adds that support so that users can be verified as members of LDAP 
sub-groups.