...
- call re International Calendar re QUILTO, basing on google calendar in a general sort of way, useful conversation, Deb, Cheryl, Ushi, Mark Keeper, Andrea Loigman, will meet again when QUITO has something for us to look at
- RA/UM cross-interest discussion today
- password mockup (Kimie)
- send reset password email - sends email and popup includes link and copy link function to send if user is not receiving emails from FOLIO
- example email, 24 hours to reset
- how will this work for SSO environment? would it be okay to disable/suppress all of this?
- needs to work for all users, including patrons, in case someone builds a patron facing app
- table the issue of what password would give access to in terms of outside users vs staff
- another option: forgot password link at sign in screen, enter email, username, or phone number, which sends you your email
- choose password should require double entry of password?
- should password eventually support 2FA and ultimately biometric? Does the IDM security ultimately need to be pulled out as a separate app that can be updated, etc.?
- Duke requires staff reset passwords every 3 months.Patron who is logged in can change password separate from forgot password workflow? Do we need also password expiration or mass reset?
- security issues surrounding this? should password/security be stripped out?
- Is this a problem or more complicated because we're trying to be all things to all users, staff and patrons?
- permission for password reset and contact info edits by user level, people might need to view but not edit
- right now you can either view it all, edit it all, or not see it at all
- maybe just make passwords completely separate from other user information screen
- useful to know the source of the contact info table this for another discussion, separate issue
- do we ever need to let the user update their own information? the one exception would be things like pickup location, etc.
- we do need SSO and password management, but need for test accounts for vendors, etc.
- at the moment SSO implementation adds a link to sign on with SSO
- login screen that offers SSO or username and password for those who are not SSO
- examples:
- From Karen Newbery https://gitlab.oit.duke.edu/users/sign_in
- Andrea Loigman https://library.duke.edu/librarycatalog/login/?next=/librarycatalog/request/008020077&aeon_holdings=none
- Chris Manly https://cornell.account.box.com/login
- Chris Manly https://confluence.cornell.edu/login.action
- examples:
- is the need for separate password management alongside SSO a v1 issue?
- sometimes dummy accounts are created as operators to allow for workflows that our systems don't support, there are always going to be likely need for workarounds
- some of what Chicago can do is due to a flexible campus infrastructure
- request fulfillment option in user record - delivery and pickup options
- an exception mechanism from within the feed for individual users for override rather than locking fields in FOLIO itself table this for future discussion
- We will need another joint discussion in the near future, Andrea and Chris will determine a time