Hi, as I spotted in previous email some design flaws (in my opinion) in Authentication. >> It gets >> > worse if you consider changes such as adding or modifying an >> > authentication module, for which the default configuration changes are >> > almost invariably associated with code changes. > Same for authentication. I consider this as a design flaw. > We should split authentication and identification. > And manage identification in a modular way... So that administrators > would just have to edit configuration files in order to make correct > mappings, and not dive into the code, change and commit (if they know > git enough...) >
I would like to gather some use cases of what hardcoded customization people had to implement in Auth_with_ldap in order to make them run. We have some... Most of which consist in date calculation for users, and hash values mappings for categories or other data or encoding. We also implemented search against multiple branches... (patch to be sent soon (still need some sanitizing) ). But I would be quite interested in more use cases. So that we could have a kind of test cases to implement in order to generalize the thing at its best. -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
