LDAPLoginAdapter 1.2, a user folder replacement that authenticates against an LDAP server, has been released. You can view some of the documentation and download the software at http://www.dataflake.org/software/ldaploginadapter. A Tracker at that same address allows you to easily file bug reports or feature requests for this product. Improvements and bugfixes since release 1.2beta1 (the last time a news release was posted) include: LDAPLoginAdapter 1.2 Bugs fixed: * Added a missing comma in __ac_permissions__ that broke changing roles via the "Security" tab on the LDAPLoginAdapter... * Completely revamped the exception handling in authenticate so that there will always be a (hopefully) helpful output in the log * authenticate had an exeption handler that would try and use a variable left uninitialized when the exception was thrown. LDAPLoginAdapter 1.2beta3 Bugs fixed: * The methods that manipulate the publicly available user object attributes now make sure to flush the cache of user objects and force all of them to be recreated, thereby making the changes "grab" immediately and not just whenever the user object expires all by itself and gets recreated. LDAPLoginAdapter 1.2beta2 Features Added: * A new management tab called "LDAP Schema" allows the manager to enter or delete attributes that describe the LDAP schema used for the LDAP user records. This completely replaces the misleading "Allowable User Attributes" found on the Advanced tab which had been abused to find out more about the LDAP schema in use. All select lists that list LDAP attributes are now driven by the attributes that are shown on the LDAP Schema tab. Features deprecated: * The "Special Users" and "Special User Roles" feature has been deprecated. I considered it a kludge in cases where you cannot set your LDAP schema correctly. With the advent of the LDAPUserManager product it has become trivially easy to add users and groups. This is the much preferred way of conferring roles to users. Bugs fixed: * Mishandled the loop to delete the public attribute mappings in manage_deletePublicUserAttrs which caused index errors * Default handling of method calls through the web or from python was inconsistent in regards to what to return and what to expect. All method signatures that might expect REQUEST now set it to a default value of None and in the method body test to see if it is None. This improves the use of methods from python where no REQUEST is guaranteed. * Change capitalization of manage_AddPublicUserAttrs to bring it in line with the normally used capitalization scheme * Renamed "Contents" tab to "Custom Forms" to clear up the meaning of this tab