---------------------
- Spell out how to safely upgrade in README.txt by using the
emergency user to delete/recreate the instances.
- Made the getAttributesOfAllObjects method more resilient by
always providing a key per queried attribute in the resultset
(http://www.dataflake.org/tracker/issue_00456 by Pierre-Julien
Grizel)
- Applied a similar fix to getUserIds and getUserIdsAndNames that
was applied for Tracker issue 441 to make sure empty resultsets
don't lead to catastrophic failures
(http://www.dataflake.org/tracker/issue_00446 by Pierre-Julien
Grizel)
- An earlier special-casing applied by Chris McDonough to
correctly handle AD objectGUID values has been applied in a
second place, in the findUser method (patch by Mark Hammond).
- Deleting a user record would be short-circuited if the user
record itself was not in the DIT anymore, e.g. because someone
manipulated the DIT without the user folder knowing about it.
This prevented cleanups for group memberships to be performed.
(http://www.dataflake.org/tracker/issue_00439 by Hans-Juergen
Sell)
- The getUserNames function did not react correctly in the face of
an empty resultset from getAttributesOfAllObjects and would
prevent admins from using the ZMI local role management view.
getUserNames now also raises a OverflowError if no results have
been returned in order to show a simple text input widget on the
local role management view instead of the multiple choice select
box. (http://www.dataflake.org/tracker/issue_00442 by Andrew
Veitch and http://www.dataflake.org/tracker/issue_00441 by
Hans-Juergen Sell)
- Added the new logging machinery to the LDAPDelegate class which
improves lower-level LDAP problem discovery.
- Moved away from the current way of logging to a purely zLOG-based
mechanism. This will make sure that all logging for Zope is in
one and the same place and that more information can be passed
along to the logging mechanism, such as tracebacks.
(http://www.dataflake.org/tracker/issue_00438 by Mark Hammond)
- Refactored the code that has python-ldap dependencies so that
only the LDAPDelegate instance now holds all the cards. This
enables plugging in different delegate implementations because
subclassing LDAPDelegate and overriding implementation details
has become easier.
(http://www.dataflake.org/tracker/issue_00438 by Mark Hammond)
- Added a registry for delegate implementations so that other
delegate classes can register themselves with this registry and
become available to the LDAPUserFolder during instantiation.