Streamlined patron load/registration functionality and updating of records
Add functionality to reduce the amount of information a patron has to enter upon registration if the institution already has that info via some other authentication system or other service/database while still getting it into the patron record. Also update patron records if the data in the primary source changes.
Heather Black commented
Related to authentication -- adding a way to address the following issues with stub accounts created in the current registration process would be helpful.
1) Currently, when using remote auth or ldap, if a new user authenticates through the remote auth system a stub account is created with just a username in the record. This idea seems like it would fix that but I wanted to make sure it's out there. It might be helpful to add a clean up functionality for these records if a customer not be able to use this new data load functionality.
2) Add in flexibility to be able to pre-populate but also allow new users to update/add information on registration. This is particularly important for libraries that use pick-up locations. New users will need to be able to select a pick up location and likely this data would not be in a patron record load from the registrar. And, as above, if a user does not complete this process, enable some way to flag such records so that they don't go into the ether without an NVTGC designation.
Beth Arellano commented
Which authentication systems is the update planned to support?