Contents

Overview

As of the Sunflower release, the ability to track and view record changes in a Version history pane was implemented for the following record types in FOLIO:

• Instances

• FOLIO holdings

• Items

• MARC bibliographic records

• MARC authority records

The goal of the version history is to track field-level changes (added, removed, edited) in the record, specify the user who made those changes*, and the ability to drill down into a detailed view of the values changed. If a user has permissions to view Inventory and/or MARC authority records, that user will have the ability to view the Version history pane of the corresponding records.

*Note: The feature itself will be controlled by a flag so that changes and any user information won’t be tracked. Please see “Configuration” section for more detail.

Open

Out of scope

• Ability to rollback to a previous version

• Ability to sort version history pane

• Information about the app that triggered the change

• Logging changes when different records are linked (such as in parent/child or bound-with relationships)

• Record-level Version history permissions (permissions to view record allow user to view Version history of corresponding record)

Configuration

There are multiple components of the version history that can be configured at the tenant level including a feature toggle, the retention period, and the number of cards that display in the version history pane. Information about using these APIs can be found here: GitHub - folio-org/mod-audit: Module for managing audit data

Feature toggle

By default, the ability to track and see the version history of Inventory & MARC authority records is enabled. However, this feature can be toggled off via API by individual libraries that do not wish to track this information.

ECS feature toggle rules

Retention period

Libraries can also configure for how long the change log should be retained via API. The default retention period is set without limits.

ECS retention period rules

For ECS, the retention period for shared records is set at the Central tenant, whereas the retention period for local records is set at the corresponding member tenant.

Cards to display in Version history pane

The number of cards that display on a single page of the Version history pane is configurable via the UI, separately for Inventory and MARC authority settings. If the total number of cards exceeds the configured cards per page, a “Load more” button will appear at the bottom.

ECS cards to display

Currently, the cards to display configuration at the central tenant controls that of all shared records, whereas the member tenant configuration only controls the display settings for local records.

Capabilities & permissions

There are multiple permissions required in order to change any of the above configurations for Version history. It is important to note however, that users that have permissions to view Inventory and/or authority records will have the ability to view the corresponding Version history pane.

The below capabilities are required in order to change the feature toggle, retention period, and cards to display per page configurations.

Open

Documentation about using the API for configuration can be found here:

• GitHub - folio-org/mod-audit: Module for managing audit data

• Inventory Audit API

Version history components

Version history pane

For all record types, the history of field changes is tracked in a separate pane, which will contain cards of all changes made in a single create/edit/delete action on the record.

A “change” occurs when:

• Field is added

• Field is removed

• Existing field value is edited

Each card will display:

• Date/time of the changes made

• The user name that made the change

  • For ECS environments, users need to have permissions to view users in the central tenant in order to the view user records from other tenants on shared records

• The field that changed as well as the action taken (Added, Edited, Removed)

Note on changes made to repeatable fields:

• When an existing repeatable field is changed, version history will display as a delete action with the new value tracked as an added field value.

• When multiple repeatable fields are saved in one edit, they will be collapsed into one line on the version history card by the action taken

Open

Version history modal

On each card, a hyperlink can be found either saying “Current version” for the most recent changes, or “Changed” on the previous cards. Once selected, a modal will appear that contains field value-level details, including:

• Action: Whether the field was added, removed, or edited

• Field: The changed field name

• Changed from: The original value, or “-” if the field was added

• Changed to: The new value, or “-” if the field was deleted

Open

MARC version history modal

Open

Instance version history modal

Linked data & Version history

In future releases, enhancements may be made to further refine the interaction between linked data resources and Inventory version history. For Sunflower, the following summarizes the current functionality. Note that there is no Version history pane implemented within the Linked data editor at this time.

Changes made in the Linked data editor

Changes made in the Linked data editor will be tracked in the Inventory Version history within the Instance detail view as well as the MARC bibliographic record source view. However:

• Changes will only reflect the fields that are currently mapped to Inventory records

• Field names from the Linked data editor will not be shown in Version history; the field names will reflect either the FOLIO Instance field names or the MARC bibliographic field name

When a node is changed within the Linked data editor, this will be tracked in the MARC bibliographic Version history as a change to an identifier. Currently the field is shown as an 035 in the MARC bibliographic view and an Identifier in the FOLIO Instance view. It will also show that this Identifier was removed and then added.

Open

Updates to node IDs in FOLIO Instance record

Open

Updates to node IDs in MARC bibliographic record

Editing existing MARC bibliographic records in the Linked data editor

When an existing MARC bibliographic record is edited in the Linked data editor and the source of the Inventory record is changed to linked data, the resulting card does not indicate that the source itself was changed. However, cards will be created that reflect that the mapping from the Linked data editor to the MARC bibliographic record has taken place based on the current mapping rules. If a field exists in the MARC bibliographic record that is not mapped between the two source types, the field will be removed and shown as a change in Version history.

Open

In the above example, some changes that were made in the MARC bibliographic record based on the mapping rules include:

• The existing 260 was removed and the data was instead added to a new 264 field

  • Open

    
  • Open

    

• The existing 100 field was changed to remove the period at the end that existed in the MARC record

  • Open

    

• The subfields in the existing 651 field were reordered

  • Open

    

     

Creating a new resource in Linked data editor

When a new resource is created in the Linked data editor, a change will be reflected in Version history indicating that the Inventory record is the original version:

Open

Sunflower

Trillium