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

* Your Email Address
* Spam protection	Enter the letters below: . ..__ ._.. ..__. \| \|[ __ \| \| \|\| \| \|/\\|[_./_\|_\|/\\|\|__\
Comment	> 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.
Attachment
Watch this ticket

Saved Queries