Page Comparison

External System ID unique?

Does the External System ID have to be unique?  The JIRA ticket is marked as a bug, although we never addressed this question in our spec.  Most institutions use SSO to enforce uniqueness of user IDs, but SSO options like Shibboleth can pass several unique ID fields to the user records.  Folio admins would choose which one to use for authentication through configuration settings. 

The External System ID is where some libraries would like to keep things like Apple ID or Google ID. 

Checkout can use the External System ID to identify/authenticate users, but Requests require a barcode.  That's annoying.

mod-user-import enforces uniqueness in External System ID when loading users, so those who don't use mod-user-import are the ones who could inadvertantly introduce non-unique values in the External System ID.  This is uncomfortable.

Some libraries would have to refactor their code if we required that the External System ID be unique.

Decision:  Require uniqueness for External System ID. 

The Leipzig team could work on this (as Björn suggested)

The JIRA tickets are unclear as to whether user deletion should check for Status - specifically, whether the status is required to be inactive.  We have agreed that this question is out of scope for our original JIRA tickets.

Deletion per UI does not check the Status. Up to now batch deletion is not possible.

Decision: Don't make the developers do status checks.  Make a new user story for that.

As of this meeting, the JIRA ticket had yet to be written.

There were two proposals for dealing with a Preferred First Name at checkout. 

1. If there is a Preferred First Name present in the record, it should replace First Name when patron information displays in checkout or elsewhere.  If Preferred First Name is not present, use First Name.
2. Display Preferred First Name with First name, with a visual cue such as quotation marks or square brackets to show counter staff which name should be used.

There were strong feelings for #2, where people wanted to be able to view a patron's full, legal name.  The disadvantages: (a) there is a lot of room for human error, causing a counter attendant to use the wrong name; (b) using the wrong name, after a patron has gone to the trouble of establishing a Preferred First Name, can cause confusion (if an Asian patron has both an Asian and a Western name) or annoyance (if a patron insists on using their middle name rather than their given name) or hurt (if a transgender person has not yet changed their legal name).

Decision:  We voted to go with option 1, because of the possibility of causing hurt if counter staff used the wrong name in error.  It is necessary, however, for a counter attendant to be able to click on a user name and see the full user record (including the full user name).