Custom Fields (UXPROD-396)

[UXPROD-2936] Check-Out App: Allow Custom Fields as Patron Identifiers for Check-Out Created: 03/Mar/21  Updated: 14/Feb/22  Resolved: 27/May/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R2 2021
Parent: Custom Fields

Type: New Feature Priority: TBD
Reporter: Erin Nettifee Assignee: Erin Nettifee
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UICIRC-559 Tests are flaky on Jenkins Closed
is defined by MODCONF-77 Update Mod-Configuration Entry to Sto... Closed
is defined by UICHKOUT-697 Check-Out: Update UI to be able to us... Closed
is defined by UICIRC-549 Settings: Update Circulation --> Othe... Closed
Relates
relates to UXPROD-2062 Anonymized loans: retain patron custo... Open
relates to UXPROD-2148 Users App: Support multiple External ... Analysis Complete
relates to MODUSERS-247 Add unique constraint for user extern... Closed
Epic Link: Custom Fields
Development Team: Other dev
PO Rank: 0
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: FLO (MVP Sum 2020): R4
Rank: U of AL (MVP Oct 2020): R4

 Description   

Please note that Duke has developed this feature and it is in place on Snapshot, and will be part of Juniper.

Current situation or problem:
Libraries want the ability to include additional identifiers on the user record to facilitate user transactions, including check-out.

Right now, there are four identifiers that can be used when checking out an item to a patron:

  • barcode
  • username
  • external system ID
  • folio record number

Some libraries have additional identifiers that they'd like to also work in the checkout app, such as identifiers for mobile devices.

This feature proposes development to FOLIO to allow libraries to store additional identifiers in custom fields, and for the Checkout app to be able to look up patrons by those additional identifier fields, in order to allow a checkout transaction to occur.

In scope

  • Settings modifications to allow libraries to opt into using custom fields for checkout;
  • Modifying the "Scan Patron" user interface on the left hand side to query those custom fields, in addition to the standard identifiers, to retrieve a patron record for checkout.

Out of scope

  • Modifications to update User Search to search for custom IDs - either through the user search modal, or through the Users app directly.
  • Modifications to support self-check systems being able to use additional identifiers with protocols such as NCIP or SIP2. If these are eventually desired, changes will need to be made to
  • Integrations to support the use of external ID readers with the FOLIO browser UI.

Use case(s)
A large academic institution offers three types of ID cards for its affiliates - a physical card, a mobile card supported through a smartwatch, and/or a mobile card supported on a smartphone. The library configures the main user profile to load the patron's physical card number into the main barcode field on the user schema, and then adds a custom field for a smartwatch ID, and a custom field for a mobile phone ID, and pushes those numbers into those fields.

Once the record is loaded, the patron can come up to a service desk to check out a book. The staff member puts the cursor into the Scan Patron box, and the patron taps their smart device on an ID reader. The ID reader outputs the patron's smart device ID into the Scan Patron box and hits enter; the patron's record is retrieved, and the checkout workflow can proceed.

Proposed solution/stories

Links to additional info
This feature is an outgrowth of discussion around implementation of UXPROD-2148 Analysis Complete - adding additional external IDs to the user schema. This is not necessarily intended to replace that feature, as various adopters can continue to see the need for it eventually, but have not prioritized it for urgent development. Implementing this will allow Duke to meet go-live requirements for supporting implementation of FOLIO in Summer 2022.

Duke will do the development on this feature, and Erin Nettifee will act as the feature's product owner.

Questions

  • Are there any security concerns with storing identifier data in custom fields? (Question raised by User Management SIG)
  • These custom fields will not be on the loan record, though this does need to be considered with https://folio-org.atlassian.net/browse/UXPROD-2062 when that is implemented.


 Comments   
Comment by md331 (Inactive) [ 03/Mar/21 ]

Note that one of the issues with continuing to use the current implementation of Custom Fields is an increased level of tech debt. As I mention here Custom Fields is implemented in a way that hardcodes a dependency on a particular implementation of the users interface rather than the users interface itself. This is contrary to the whole thesis behind Folio, where modules can be swapped out for different implementations. Requiring a specific implementation of the users interface specifically is risky given the desire of some institutions to not duplicate their user data across multiple databases.

Comment by Holly Mistlebauer [ 09/Mar/21 ]

Erin Nettifee:  This feature should be discussed with the RA SIG.   Dev should pass info to the  Prokopovych (Core Functional) team so that the team is aware of what is going on. 

Comment by md331 (Inactive) [ 16/Mar/21 ]

On the March 11 #stripes-arch call, we decided that we can't just leave the existing Custom Fields implementation as-is. To kickstart things, I wrote a new hook that decouples the backend and frontend. As of this moment, the PR is in Draft status to allow for comments and feedback while the first use of the hook - this feature - is being developed.

Comment by Brooks Travis [ 04/Apr/21 ]

md331 Are there any concerns over the inability enforce uniqueness on custom field values at the moment (I know that we already have externalSystemId as a field for lookup and it's not currently enforcing uniqueness, but it really should be…)? I'm not sure I've ever tried looking up a user by externalSystemId when they're not unique. I assume the solution in that case would be to just not use externalSystemId as a lookup point, same for any particular custom field.

Comment by md331 (Inactive) [ 05/Apr/21 ]

I'm not really concerned about it Brooks Travis. Like you say, there's a decent amount of footguns in the system already and I've gotta believe that people will intuitively understand the uniqueness requirements of this one.

Comment by md331 (Inactive) [ 05/Apr/21 ]

I think it'd be interesting to see if the folks developing mod-custom-fields took a peek and checked out what it would take to be able to mark a custom field as unique and enforce it. My first guess at downside would be performance. But to be frank, I don't really see anyone ranking that feature high enough for it to get tasked! 

Comment by Erin Nettifee [ 28/Apr/21 ]

This feature is in place on Snapshot (it did not make Iris, which is fine,) but it's a little tricky to test it because performance issues would really only emerge with large numbers of records to search, and Snapshot just doesn't have that many user records to speak of.

Mark helped me with a strategy to test the query on Duke's test environment, which has more than 70,000 records. The search query ends up looking something like this:

https://duke-test-okapi.folio.indexdata.com/users?query=(barcode=="FOO" OR externalSystemId=="FOO" OR customFields.mobileID=="FOO" OR customFields.mobileID2=="FOO")

It ends up resulting in a search that's about a half-second slower. Adding in the username to this (which Duke would want to do) - resulting in 5 fields - makes it maybe about 3/4 of a second slower.

This testing also confirms what we have been saying that libraries who do not turn on the custom fields query should see no performance issues, as expected.

Comment by Brooks Travis [ 30/Apr/21 ]

md331 Erin Nettifee Could performance impacts be remediated if a custom index was added for the mobileID custom field by your hosting/sysops team? I know that this has be useful in the past in other areas where a common query did not have an index specified in the code.

Comment by md331 (Inactive) [ 30/Apr/21 ]

Interesting, I didn't know you could do that! Definitely something to keep in mind. Thanks for the tip!

Comment by Khalilah Gambrell [ 27/May/21 ]

Hey Erin Nettifee and md331, I noticed all the stories are complete. What do you need to deploy these stories and have them included in Juniper release?

Comment by Erin Nettifee [ 27/May/21 ]

I'll go ahead and mark this as done to reflect the fact that it has been completed and tested and should be included in Juniper release planning (e.g., included in the ui-checkout release for Juniper.)

The open question is whether we need to put this into Bugfest testing, Khalilah Gambrell.

Comment by md331 (Inactive) [ 27/May/21 ]

Yeah I don't really know anything about Jira statuses or Bugfest and whatnot, but the work has been merged in ui-checkout and ui-circulation, so it'll be a part of whatever release is cut for Juniper.

Generated at Fri Feb 09 00:28:03 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.