Version history requirements - Inventory & MARC authority
- Khalilah Gambrell
- Christine Schultz-Richert
- Ryan Taylor
- Pavlo Smahin
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 |
|
| MODAUD-209: [Instance/Item/Holding/Bib/Authority Audit] Feature Flag ConfigurationClosed |
Retention period configuration |
|
| MODAUD-207: [Instance/Item/Holding/Bib/Authority Audit] Retention Period ConfigurationClosed UIIN-3206: [Instance/Item/Holding/Bib Audit] Settings: Retention Period ConfigurationClosed |
Display configuration |
|
| UIIN-3213: Create Inventory settings to configure number of cards in version historyClosed
|
Tech design
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 | MODAUD-209: [Instance/Item/Holding/Bib/Authority Audit] Feature Flag ConfigurationClosed | complete |
| 2 | 25 10 cards on version history to show as default
| Managed at the tenant level - each tenant (Central or member) can configure how many cards appear in the version history pane | UIIN-3213: Create Inventory settings to configure number of cards in version historyClosed UIMARCAUTH-444: Create MARC authority settings to configure number of cards in version historyClosed MODAUD-222: Support settings to configure number of cards in version historyClosed
| complete |
| 3 | Allow for configuration of retention period Default to all |
| MODAUD-207: [Instance/Item/Holding/Bib/Authority Audit] Retention Period ConfigurationClosed UIIN-3206: [Instance/Item/Holding/Bib Audit] Settings: Retention Period ConfigurationClosed | complete |
Version history pane requirements
Requirement | Notes | Folijet | Spitfire | Status | |
|---|---|---|---|---|---|
| 1 | Add icon to open change log |
| UIIN-3170: Instance: Add Change log icon to details viewClosed UIIN-3171: Holdings: Add Change log icon to details viewClosed |
| 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-Richert - to determine UI wording We do not need to retain the local version history when shared. |
| Jan 21, 2025 | complete |
| 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
Changed
|
| Jan 21, 2025 | complete |
| 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 |
| Jan 16, 2025 | 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 |
| Jan 27, 2025 | complete |
| 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 Based on additional effort needed, we will not be logging this in the change history. | @Pavlo Smahin needs to review how the relationships are stored | Jan 21, 2025
| complete |
| 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 - tracked by the addition/removal of the subfield $9 |
| Jan 27, 2025 | complete |
| 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? |
| Specific story not related to feature | 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? |
|
| Jan 26, 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 | How will we show which values have been changed? |
|
| Jan 27, 2025 | complete |
| 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 (keep only last update of delete) | @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? | Based on conversation below, we should retain audit history for Instances even when marked as set for delete. 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. |
| Jan 21, 2025 | complete |
| 23 | Do we retain history for authority records that are in the archive? |
We can retain the history ( Mar 18, 2025 ) | If it’s more difficult to not track create, then keep. If it’s easier to ignore, then just do that. | Jan 16, 2025 Jan 30, 2025 | complete |
@Khalilah Gambrell - Acq does not include reordering in the audit trail. I think we should also ignore it.