Users App
(UXPROD-784)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. |
| 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:
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
|
| 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. |