Page Comparison

...

Notes

• 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
• 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