[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:
Defines
is defined by MODUSERS-223 Improve log fields with additional in... Open
Relates
relates to UXPROD-2731 Improvements to User loader - additio... Open
relates to RMB-553 Add postSync to PgUtil Closed
relates to UXPROD-2732 Improvements to User loader - protect... Closed
relates to UXPROD-242 Ability to Protect Fields from Being ... Draft
relates to UXPROD-2734 Bulk APIs for Users module Open
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 ]

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.

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:

  • Normally only faculty have the option for request delivery so the user loader always sets Request preference to Hold shelf only for all patron groups except faculty
  • A graduate student gets special permission from the library to get delivery requests so staff go into FOLIO and manually check Request preference > Delivery

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: UXPROD-242 Draft It should be removed from this feature writeup, patty.wanninger.

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.

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