Skip to end of banner
Go to start of banner

2022-04-20 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 3 Current »

Date

Attendees

Agenda

  • Patty will discuss UXPROD-3644 - Make the preferred contact field in Users conditional on method of contact.
  • SIP-2 PIN field - Related to UXPROD-1811 (Implement patron PIN as a separate authentication field)  and MODUSERS-254 (Implement backend-only field to store patron PIN).

Discussion items

TimeItemWhoNotes
35 min.Implement patron PINBjorn

See UXPROD-1811MODUSERS-254SIP2-89 and Additional PIN field for users/patrons

Currently the PIN is stored in the User password field, which causes problems, and is poor from a security standpoint. This work (almost all back-end) is a requirement for a number of features. SIP2 implementation would need to be enhanced to take advantage of this, also Edge-patron enhancements would be needed. Bjorn clarified that the PIN would be used for self-check-out purposes, not for log-in. To set or re-set their PIN, patrons would login to their account. Bjorn said they would not need an email reset button. The ticket is for storage and verification of the PIN, how institutions choose to implement would be up to them. 

Patty is concerned libraries will want a front-end component to work with this. It was decided to bring the question to the RA SIG as to whether we need a front-end component created concurrently. Patty will check with Jana regarding a time to discuss that in the RA SIG. Ian will start work on this, and see how difficult it is. Given needed work on SIP2, and Edge-patron, this won't be ready for Morning Glory. Institutions also need time to prepare for changes to SIP2.

20 min.UXPROD-3644Patty

Having the email by a required field in the UI is problematic for some libraries, as not all their patrons have email. Putting in a fake email creates problems, as the email bounces, making the hosting provider unhappy. It was decided that the 'conditional requirement' approach was not warranted, as FOLIO only is able to automatically send emails. It would be nice, especially give German legal requirements, for FOLIO to have an alternate way of doing automatic notices.  It was decided to contact Julie B. (PO for notices), to ask about having email notification alternatives (such as texting or snail mail).

Patty will write a ticket to have the two currently required (in the UI only) Contact Information fields -- Email and Preferred contact – be no longer required.

Action items

  •  
  • No labels