[UXPROD-2320] Improvements to User loader - source of feed Created: 12/Mar/20 Updated: 20/Jun/23 |
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | TBD |
| Reporter: | patty.wanninger | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | migration-load, round_iv, usermanagement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||
| Development Team: | None | ||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R5 | ||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R5 | ||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R4 | ||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||||||||||||||
| Rank: Warner (MVP Jul 2020): | R5 | ||||||||||||||||||||||||||||||||
| Description |
|
The mod-user-loader needs to be improved. As a system administrator, I want to be able to distinguish the source of the feed. I need to do different things if the feed is legacy data, from an institution's system, or other source. Would like to be able to store the source of the feed. Currently source of bulk load gets concatenated with ext system ID. This ticket is now a split - see related features in the links below and please rank. |
| Comments |
| Comment by patty.wanninger [ 13/Mar/20 ] |
|
Ian Walls Please comment @Cate this is a draft of a feature from the User Management SIG's point of view. It is still missing the pieces from the sys ops point of view. |
| Comment by Ian Walls [ 23/Mar/20 ] |
|
Perhaps, like with Instances, Users could be given a "source" field that indicates the source of truth for this record ("FOLIO", campus system, legacy ILS, etc.) To manage field overwrites/protections, what about implementing the PATCH verb for users? Any supplied fields would be overwritten, any absent would be left alone. Pre-filter the record fields supplied to only send what needs updating. Perhaps having a post-filter, set on the FOLIO side, would be a good error-catch, in case fields were mistakenly supplied that shouldn't be overwritten. Using UUID versions 3 or 5 on creation of the user record would allow programmatic translation from the ID in the source of truth to the FOLIO UUID. I'm having a hard time seeing a built-in FOLIO tool that does this job sufficiently for all libraries... it seems like locally created scripts, with the appropriate connection to the source of truth, and the necessary logic for the institution, would better meet the varied needs of each implementor. |
| Comment by Julian Ladisch [ 23/Mar/20 ] |
|
This feature combines five issues. Should implementers use the highest rank of the five issues? |
| Comment by Kelly Drake [ 23/Mar/20 ] |
|
I'm going to agree with what Ian Walls said, especially at this point in FOLIO's development. |
| Comment by patty.wanninger [ 23/Mar/20 ] |
|
Julian Ladisch Yes, I believe so. If any part of this ticket is ranked high for Stage II implementers, we can further prioritize the features upon disucssion. |
| Comment by Cate Boerema (Inactive) [ 08/Jun/20 ] |
Ian Walls I am not sure if it supports PATCH, but it was my understanding that User loader already worked this way (e.g. when loader is silent on a field, the field is left alone). Is that not the case? That said, even if we have or developed this ability, I'm not sure it would address the data protection need. Here's a scenario:
How would the user loader know to be silent/not supply data for this field/user combination going forward? Finally, we already have a UXPROD for protecting fields from override by the user loader:
In fact, to Julian Ladisch's point, there are several features here which should probably get different priorities. I would suggest breaking this down into separate features. |