[Tickets #4135] Nested groups don't fully work in LDAP driver

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=4135
-----------------------------------------------------------------------
 Ticket             | 4135
 Updated By         | Ben Klang <ben at alkaloid.net>
 Summary            | Nested groups don't fully work in LDAP driver
 Queue              | Horde Framework Packages
 Version            | HEAD
-State              | Stalled
+State              | Assigned
 Priority           | 2. Medium
 Type               | Bug
 Owners             | Ben Chavet
+New Attachment     | group-ldap-nested-groups-fix.patch
-----------------------------------------------------------------------


Ben Klang <ben at alkaloid.net> (2006-07-09 21:28) wrote:

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.