Skip to end of banner
Go to start of banner

2017-11-09 Resource Access Meeting Notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Date

Attendees

Goals

  • Continue discussion of issues of joint interest to the UM and RA SIGs

Discussion items

TimeItemWhoNotes
5 minHousekeeping
  • Note-taker: David Bottorff
  • Report out from 1st Calendar internationalization meeting
 55 min UM/RA cross-interests

See: UM and RA SIG Joint Discussion Topic Backlog

  • Password functionality
  • Expiration dates for patron contacts
  • User fields for fulfillment options

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