Version history requirements - Inventory & MARC authority
Feature | |
Release | Sunflower |
Document status | draft |
Overview
In scope
Log that contains
User who made the change
Date time of change
Change made
Applied to both FOLIO and MARC source instances
Feature toggle
Configuration of number of cards to show
Configuration of retention period
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
Team Responsibilities
Category | Folijet | Spitfire | Jira |
Version history UI |
|
|
|
Domain events & rest endpoints |
|
|
|
Change log feature toggle |
|
| |
Retention period configuration |
|
| |
Display configuration |
|
| https://folio-org.atlassian.net/browse/UIIN-3213
|
Tech design
https://folio-org.atlassian.net/wiki/spaces/DD/pages/332955650
Requirements
Configuration requirements
Requirement | Notes | Jira | Status | |
|---|---|---|---|---|
| 1 | Feature toggle so that libraries can set whether the feature is enabled (applies to both FOLIO and MARC source records) | Should apply to all record types (in Inventory & MARC authority)
ECS:
Note: “Local” refers to local instance, holdings, and item records | complete | |
| 2 | 25 10 cards on version history to show as default
| Managed at the tenant level - In Sunflower, central tenant setting will control the cards per page for all shared records. Member tenant setting will control the cards per page for only records that are local to that tenant. | https://folio-org.atlassian.net/browse/UIIN-3213 https://folio-org.atlassian.net/browse/UIMARCAUTH-444 https://folio-org.atlassian.net/browse/MODAUD-222
| complete |
| 3 | Allow for configuration of retention period Default to all |
| complete |
Version history pane requirements
Requirement | Notes | Folijet | Spitfire | Status | |
|---|---|---|---|---|---|
| 1 | Add icon to open change log |
| https://folio-org.atlassian.net/browse/UIIN-3170 |
| complete |
| 2 | After clicking change log icon, suppress accordions/tags/actions menu |
| https://folio-org.atlassian.net/browse/UIIN-3176 |
| complete |
| 3 | 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
| complete |
| 4 | Display the date and time of the change in local timezone |
|
|
| complete |
| 5 | Display the user source of the change.
|
|
|
| complete |
| 6 | When record is first created, only included a record-level change of created. Do not include field-level changes on the card. |
|
|
| complete |
| 7 | Identify as a “Change”, and indicate whether the field was:
|
|
|
| complete |
| 8 | Identify as a “Change” when holdings/item records are moved When holdings are moved, show change on holdings record of:
When item records are moved, show change on item record of:
|
|
|
| complete |
| 9 | 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) | Current implementation:
|
|
| complete |
| 10 | In Source view for MARC source records, identify the specific MARC fields (not to the point of indicators or subfields) changed |
|
|
| complete |
| 11 | 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 |
|
|
| complete |
| 12 | Add a “Load more” button to the bottom of the version history pane |
|
|
| complete |
| 13 | Present a toast message that loading additional changes may take time | Test |
|
| review |
| 14 | When records are promoted to shared:
|
|
|
| complete |
| 15 | For repeatable fields, if multiple values (such as multiple contributors) are added/edited/removed, show as a single line on the card. All fields as plural. |
|
|
| complete |
| 16 | For inner fields:
|
|
|
| complete |
| 17 | Do not show changes to the 005 fields for MARC record version history |
|
| complete | |
| 18 | Add a version counter to the Version history paneheader |
|
| complete |
Modal requirements
Requirement | Notes | Folijet | Spitfire | Status | |
|---|---|---|---|---|---|
| 1 | Add a hyperlink to the “Changed” header on the version history cards |
|
| complete | |
| 2 | Hyperlink to “Changed” header should open a modal that contains field value-level change details for the selected card |
|
| complete | |
| 3 | Header of modal should contain the date, time and the user source of the change |
|
| complete | |
| 4 | Modal should contain columns:
Table should be sorted by Action, ascending, with no manual sorting capabilities |
|
| complete | |
| 5 | For repeatable fields: Show each high level field on one line |
|
| complete | |
| 6 | For inner fields: Show each field value in bullets |
|
| complete | |
| 7 | MARC-specific modal:
|
|
| complete |
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 - @Khalilah Gambrell - is this correct?
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? | Replace “Changed” to “Shared” and remove the audit history from the previous local record 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 - to determine UI wording We do not need to retain the local version history when shared. |
| Jan 21, 2025 | complete |
| 4 |
@Khalilah Gambrell - Acq does not include reordering in the audit trail. I think we should also ignore it.