Custom Fields
(UXPROD-396)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||
| 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: Right now, there are four identifiers that can be used when checking out an item to a patron:
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
Out of scope
Use case(s) 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 Duke will do the development on this feature, and Erin Nettifee will act as the feature's product owner. Questions
|
| 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. |