Inventory app Version history
- Khalilah Gambrell
- Christine Schultz-Richert
- Ryan Taylor
Feature | |
Release | Sunflower |
Document status | draft |
- 1 Overview
- 1.1 Action items
- 1.2 In scope
- 1.3 Out of scope
- 1.4 Team Responsibilities
- 1.5 Tech design
- 2 Requirements overview
- 3 Questions
Overview
Action items
Document business expectations? Where do we differ from Acquisitions? Some examples:
ECS handling - change ownership
Setting record for deletion
Default display (sort, number to display, how to go through more history) - endless scroll? More?
Document some user workflows (i.e. Single record overlay)
Work with Kimie to revise UX ( )
Remove “sort by”
Remove examples where the app is identified as the trigger for the change
When the record is created (look at Orders app)
ECS event of “Shared”
Write user stories
In scope
Log that contains
User who made the change
Date time of change
Change made
Feature toggle
Applied to both FOLIO and MARC source instances
Configuration of number of cards to show (default 15)
Out of scope
Ability to rollback to and/or view previous versions
Ability to sort
Including the app that triggered the change
Exporting version history
Highlighting the fields changed
Team Responsibilities
Category | Folijet | Spitfire | Notes |
Version history UI |
|
|
|
Domain events & rest endpoints |
|
|
|
Change log feature toggle |
|
| Whichever team has capacity after UI |
Display configuration |
|
| Need story; Whichever team has capacity after UI |
Tech design
Requirements overview
Requirement | Notes | Folijet | Spitfire | |
|---|---|---|---|---|
| 1 | Feature toggle so that libraries can set whether the feature is enabled (applies to both FOLIO and MARC source records) |
|
| |
| 2 | Add icon to open change log |
| https://folio-org.atlassian.net/browse/UIIN-3170 |
|
| 3 | After clicking change log icon, suppress accordions/tags/actions menu |
| UIIN-3176: Instance: Suppress accordions/tags/action menu when clicking Change log iconOpen |
|
| 4 | Include version history on:
|
| https://folio-org.atlassian.net/browse/UIIN-3173 | https://folio-org.atlassian.net/browse/UIQM-674 https://folio-org.atlassian.net/browse/UIQM-673
|
| 5 | Display the date and time of the change in local timezone |
|
|
|
| 6 | Display the source of the change (user vs system) |
|
|
|
| 7 | Identify as a “Change”, and indicate whether the field was:
|
|
|
|
| 8 | Indicate the field changed on Instances detail view for both FOLIO and MARC source records. Note: for MARC source records, the field changed should reflect the Instance field changed (see other requirement for Source view) |
|
|
|
| 9 | In Source view for MARC source records, identify the specific MARC fields (not to the point of indicators or subfields) changed |
|
|
|
| 10 | If a MARC field is changed that does NOT map to a FOLIO instance, do not include the change in the Instance detail view log |
|
|
|
| 11 | 15 cards on version history to show as default Estimate:
Only include 15 cards in the log at a time in the instance history view |
| https://folio-org.atlassian.net/browse/UIIN-3179 |
|
| 12 | Present a toast message that loading additional changes may take time |
|
|
|
| 13 | When records are promoted to shared:
| Tech design considerations:
|
|
|
Questions
Question | Answer | Refinement Notes | Answer Date | Status | |
|---|---|---|---|---|---|
| 1 | In the mockups, the user name is hyperlinked - does this just go to the user record? | Yes |
| Dec 20, 2024 | complete |
| 2 | Do we indicate when one record is updated from changes made to another record (such as updating the call number on a holdings record which then updates the effective call number on the item record)? | If there is a field that is autogenerated/updated, needs to be reflected in item version history
Likely need to exclude from the version history (CSR needs to come up with the list of fields to exclude) |
| Jan 16, 2025 | complete |
| 3 | Do we include a change of “Shared” for ECS? | Yes. Need to determine LOE for indicating that the record was Shared as opposed to just Created (CSR to determine what will replace “Original version” when shared and create backend story) @Christine Schultz-Richert - to determine UI wording We do not need to retain the local version history when shared. |
|
| analysis |
| 4 | Do we include a change of “Derived” and “Duplicate”? | Yes No, not for this phase. Just indicating that the new record was created is in scope. |
*could be similar to effort of “via” line that we omitted | Jan 14, 2025 | complete |
| 5 | Do we include a change if
| Yes
|
|
| analysis |
| 6 | ECS change ownership | When holdings are moved to another instance, that holdings record is deleted and a new one is created on the instance. Therefore, the holdings would just be deleted, we wouldn’t need to capture that change anywhere. The new holdings record would just have a history of being created. We don’t need to retain the history of the deleted holdings |
| Jan 16, 2025 | complete |
| 7 | Is keeping one year of history sufficient? Potentially need some sort of workflow where a user can make a call to some sort of archive to get more history? | Existing story for configuring retention period |
|
| complete |
| 8 | Do we need to track when fields are reordered in quickMARC? | Yes - indicate field and an action of “Moved”? - Ping acq about what they’re doing if:
Do not include as a change | @Kateryna Senchenko check to see if these changes would be captured anyway |
| Analysis |
| 9 | Confirm whether there will be changes logged when records are linked together? (might show with parent/child?) | For parent/child changes, we need to show high level that a new child or parent relationship was added, edited, or removed | @Pavlo Smahin needs to review how the relationships are stored |
| analysis |
| 10 | Confirm whether the linking of authorities to bibs be reflected in change log | When a MARC bib field is linked to a MARC authority heading, indicate that the field was changed in the bib version history | @Kateryna Senchenko to confirm that this will be captured as an update in quickMARC
|
| analysis |
| 11 | Do we need to implement this issue (https://folio-org.atlassian.net/browse/MODINVSTOR-1220 ) as a part of UXPROD-4125 or UXPROD-4126? |
|
| Jan 14, 2025 | complete |
| 12 | What is the impact of implementing these issues https://folio-org.atlassian.net/browse/MODINVSTOR-1207 and https://folio-org.atlassian.net/browse/MODINVSTOR-1268 after UXPROD-4125 or UXPROD-4126? |
| Not related | Jan 14, 2025 | complete |
| 13 | Requirement for showing only 15 cards at one time (need UI requirements)
|
|
| Jan 14, 2025 | complete |
| 14 | How do we show change history when the repeatable fields are changed in Instance? | We do not need to add a separate line for each contributor(s) that was changed. If more than one contributor has been added/edited/removed, just have one line of “Contributors” with the change type. We don’t have to capture the inner fields that have changed, just the higher level field. |
| Jan 14, 2025 | complete |
| 15 | How do we show change history when the multiple fields are changed in quickMARC? | For repeatable fields, include a card for each separate field (ex: multiple 600s would have a separate card for each 600) |
| Jan 16, 2025 | complete |
| 16 | Will we add the highlighted fields on the record in the future? | Yes - @Christine Schultz-Richert to talk to Kimie |
| analysis | |
| 17 | Will we add the rollback capability in the future? | Yes |
| Jan 14, 2025 | complete |
| 18 | Do we include bound-with changes? | No | Jan 16, 2025 | complete | |
| 19 | What do we do with records that are already in the system? |
|
|
| analysis |
| 20 | Holdings & item deletion - where do we log? | We don’t have to display in the UI version history. But we need a way for an institution to make a call that will return records that were deleted via an API | @Khalilah Gambrell - to create a spike for team to investigate the LOE for exposing deleted holdings/items so that institutions can make a call via API to retrieve | Jan 16, 2025 | complete |
| 21 | Do/where we display deletions for instances and authorities? | No, we do not need to display deletions for instances or authorities |
| Jan 16, 2025 | complete |
| 22 | For which records do we retain the audit history when deleted? | Question: Instances - @Ryan Taylor - in the scenario where the Instance record is set for deletion, are we saying that the history is removed too? Or should we retain the history? Answer:@Christine Schultz-Richert -- Version history should be retained when an Instance has been set for deletion. Since “hard deletes” are not supported in UI for Instances today. Users will still have the ability to change an Instance back to active (or “un-delete”). As such, we should retain Instance Version History even after its been set for deletion. |
|
| analysis |
| 23 | Do we retain history for authority records that are in the archive? | Remove history when authority record is deleted from the UI/data import action |
| Jan 16, 2025 | complete |