Users App (UXPROD-784)

[UXPROD-242] Ability to Protect Fields from Being Overwritten by User Import Created: 21/Feb/18  Updated: 20/Jun/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Users App

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Amelia Sutton
Resolution: Unresolved Votes: 1
Labels: Folijet-UI-candiate, round_iv, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File patron-loader-freeze.png    
Issue links:
Defines
is defined by UIU-531 Flag an entire user record as a poten... In Progress
is defined by UIU-530 Ability to override a field via Folio... Draft
is defined by UIU-532 Set an expiration date for how long f... Draft
is defined by UIU-533 Allow user to add a reason why the fi... Draft
is defined by UIU-534 Need to track the fields that are pro... Draft
is defined by UIU-535 Store/Make the list of exceptions acc... Draft
is defined by UIU-536 Need to a way for the list of overrid... Draft
Relates
relates to MODINVSTOR-119 generic way to mark records "protected" Open
relates to UXPROD-2873 Mod-user-import stabilization Open
relates to UXPROD-2731 Improvements to User loader - additio... Open
relates to UXPROD-2734 Bulk APIs for Users module Open
relates to UXPROD-2732 Improvements to User loader - protect... Closed
relates to UXPROD-2320 Improvements to User loader - source ... Draft
Epic Link: Users App
Analysis Estimate: Medium < 5 days
Analysis Estimator: Khalilah Gambrell
Front End Estimate: XL < 15 days
Front End Estimator: Zak Burke
Back End Estimate: Large < 10 days
Back End Estimator: Kurt Nordstrom
Estimation Notes and Assumptions: This estimation is largely dependent on the scope of the changes we make to the backend. I think a "Large" size is fitting if the change is primarily an additional field made to the required data stores to hold the change schema.

Alternately, if we want a more comprehensive solution akin to mod-notes wherein we implement an actual module to track change permissions to schema, I think an XL designation would be more fitting.
Development Team: Prokopovych
Kiwi Planning Points (DO NOT CHANGE): 21
PO Rank: 54
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R3
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R1
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R4
Rank: Leipzig (Full TBD): R1
Rank: Mainz (Full TBD): R2
Rank: MO State (MVP June 2020): R1
Rank: St. Michael's College (Sum 2021): R2
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

Support ability for staff to block a field(s) on a user record or the entire user record from being overwritten by a user import/data feed. This feature will support a library's need to temporarily prevent a user import/data feed or Folio logic from updating a field(s) on a user record.

As a system administrator, I want to be able to designate what happens when a record is in the FOLIO database but does not come in the feed, depending what kind of feed it is.
If the record in FOLIO was created via feed, the absence of the patron in a new feed should cause the record to be inactivated
But, if a record in FOLIO was created by migration or in FOLIO itself, the feed will have no effect on it.



 Comments   
Comment by Kurt Nordstrom [ 25/May/18 ]

If we make certain that all records in question have the standard metadata field (which includes creation and modification dates), would this be enough to determine which should and should not be overwritten?

Comment by Cate Boerema (Inactive) [ 28/Sep/18 ]

Just a note from a Slack convo today with Theodor Tolstoy (One-Group.se), Lisa Sjögren and Siska from Chalmers about this feature: We will most likely write our own functionality for user import, and that will surely contain some functionality in that area. So I do not see a pressing need for that

Theodor Tolstoy (One-Group.se), should we change the Chalmers rank on this from go-live? Or do you want to leave it as go-live until you have implemented your own user import functionality?

Comment by Anya [ 29/Mar/19 ]

Comment from March Meeting : Can wait while EBSCO does loading; will need once we're on our own/ connect to BANNER / Workday / Colleague

Comment by Erin Nettifee [ 10/Jul/19 ]

There are a number of use cases for this, two coming to mind:

  • A patron's underlying university data is wrong and being corrected; we want their library access to continue while the correction is being done;
  • Someone temporarily needs to have group membership or privileges escalated; for example, a student who is normally not entitled to delivery, but has an injury that means they can't walk to a location and need delivery as an accommodation.

We would also want this to be at the field level - for example, freezing someone's expiration date or group, but not their name or contact information. I recognize that may be hard to have v1, though.

This would need to be temporary - e.g., an expiration date on this should be required - because you don't want an account to be frozen forever (risking access being extended beyond when it should have been expired.)

I think there are actually two features here - one for blocking update via a bulk load process, and one for blocking update via the GUI. For the GUI, I imagine a solution like Teams could be possible for a full-record lock. Once Users has a new PO, I would advocate for the PO splitting this up, since institutions may prioritize one higher than the other for go-live.

Comment by Erin Nettifee [ 05/Aug/19 ]

Additional use case that came up in RA discussion - deceased patrons. A lot of this depends on local practice and the variation of high-touch services being asked for, especially in the case of a faculty member passing away.

If there is no larger workflow being designed, libraries may choose to use workarounds to address local needs (like changing an email address on a record, so that an overdue notice is not inadvertently mailed.) Freezing the record will be important to make sure that a central HR field does not interrupt these changes.

Comment by Cate Boerema (Inactive) [ 19/Sep/19 ]

Hi patty.wanninger, Erin Nettifee et al. Today in the RA SIG meeting, we discussed how at least a couple institutions (Duke and Chicago) really need some way to flag an entire record as "do not update". The super thin thread proposed is actually quite thin thread. The idea is that there is some flag on the user record that can be manually set that says "don't overwrite" (or something along those lines) and then the user import feed would be able to look at that flag and skip updates of records that have it. I think we should create a separate feature for this like "Flag for Protecting User Record from Being Overwritten by User Import". At minimum, this feature would entail adding a simple flag to the user record. I am not yet clear on what additional changes would need to be added to mod-user-import. Does the logic for preventing records from being overwritten need to be added to that module or can that be handled outside of FOLIO in institutions' scripts.

patty.wanninger can you please create a UXPROD feature for this and drive the requirements discussions? If it's really about just a single field on the User record, I am hoping we can slip it in for mvp.

Comment by Erin Nettifee [ 20/Sep/19 ]

Hi Cate Boerema. Yep, this is actually almost exactly what we discussed at the UM SIG on Wednesday, and Patty and I took a task to work on a thin-thread feature and user stories.

patty.wanninger - let me know when you want to get that scheduled. Not sure what your travel is looking like right now.

Andrea Loigman - just an FYI.

Comment by Hkaplanian [ 24/Sep/19 ]

Someone should check and see if the current user import command line tool has the ability to protect particular fields from being overwritten. I have a very hazy memory of seeing that ability at least partially demonstrated several years ago. It could be imagination, but I think that ability is there.

Comment by Erin Nettifee [ 24/Sep/19 ]

There is an ability to update only info that's in the import - so if an address isn't in the import file, but in the FOLIO record, you could tell the import not to overwrite the FOLIO record. However, that doesn't get at the use case here, since you need to flag the record in the GUI so that the import then knows not to touch it for that particular record - not necessarily for all records.

Comment by Erin Nettifee [ 30/Jan/20 ]

This is an example of how this feature looks in an Aleph implementation (at Duke) - these controls are on the individual user record. You check the appropriate box and save to protect that part of the record; to unprotect, uncheck the box and save.

Comment by patty.wanninger [ 23/Oct/20 ]

This is the original feature - will close UXPROD-2732 Closed

Comment by Karen Newbery [ 26/Oct/20 ]

Patty, Duke is going to leave the ranking as is at R1. Erin has covered our reasons well in previous comments.

Comment by Ann-Marie Breaux (Inactive) [ 19/Nov/21 ]

Hi patty.wanninger All the stories in this Feature are still draft, and there's no mockups. Once the stories are moved to Open and mockups added, Folijet can take another look at it.

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