Category

Folijet

Spitfire

Jira

Version history

UI

• Instances

• FOLIO holdings

• Items

• MARC source view

  • Bibs

  • Authorities

Domain events & rest endpoints

• MARC bibs

• MARC authorities

• Instances

• FOLIO holdings

• Items

Change log feature toggle

Retention period configuration

Display configuration

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)

• When the feature flag is disabled, previous history is retained but edits after disabling are not tracked. If the flag is later enabled, the history will start being recorded.

ECS:

• Enabled on central tenant, disabled on member tenant

  • Central tenant: Version history will show (all shared records)

  • Member tenant: Version history icon will show on shared records, will NOT show on local records

• Enabled on central tenant, enabled on member tenant

  • Central tenant: Version history will show (all shared records)

  • Member tenant: Version history will show on all records

• Disabled on central tenant, enabled on member tenant

  • Central tenant: Version history will not show

  • Member tenant: Version history will NOT show on shared records, will show on local records

• Disabled on central tenant, disabled on member tenant

  • Central tenant: Version history will NOT show

  • Member tenant: version history will NOT show

Note: “Local” refers to local instance, holdings, and item records

25 10 cards on version history to show as default

• Add configuration for number of cards to show at once with a maximum value in Settings

• Inventory display settings

• 10 as default

Managed at the tenant level - each tenant (Central or member) can configure how many cards appear in the version history pane

Allow for configuration of retention period

Default to all

• ECS:

  • Central tenant: all shared

  • Member tenant: local to that tenant

Add icon to open change log

After clicking change log icon, suppress accordions/tags/actions menu

Include version history on:

• Instance detail view (fourth pane)

• Holdings detail view (second pane)

• Items detail view (second pane)

• source view for MARC source records (bibs & authorities - second pane)

Display the date and time of the change in local timezone

Display the user source of the change

.

• Hyperlink user name and once clicked, redirect to Users app and the User record

• If the user does not have permissions to view User records, make the hyperlink inactive

When record is first created, only included a record-level change of created. Do not include field-level changes on the card.

Identify as a “Change”, and indicate whether the field was:

• Added

• Edited

• Removed

Identify as a “Change” when holdings/item records are moved

When holdings are moved, show change on holdings record of:

• Holdings record (Moved)

When item records are moved, show change on item record of:

• Item record (Moved)

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:

• If multiple repeatable fields are changed AND reordered in a single version, “changed from” and “changed to” values may not be correlated in the right order

• If a new repeatable field is added when there are existing fields of the same tag, the action will show as “Edited”

In Source view for MARC source records, identify the specific MARC fields (not to the point of indicators or subfields) changed

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

Add a “Load more” button to the bottom of the version history pane

Present a toast message that loading additional changes may take time

Test

When records are promoted to shared:

• Capture and show that the record has been shared in the audit log

  • Instead of “Original version”, replace with “Shared”

• Do not retain the history of the local record

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.

For inner fields:

• Do not show as a change on the card in the Version history pane (for example, just show that “Contributors” at a higher level changed)

Do not show changes to the 005 fields for MARC record version history

Add a version counter to the Version history paneheader

Add a hyperlink to the “Changed” header on the version history cards

Hyperlink to “Changed” header should open a modal that contains field value-level change details for the selected card

Header of modal should contain the date, time and the user source of the change

Modal should contain columns:

• Action (such as Added, Edited, Removed)

• Field

• Changed from

• Change to

Table should be sorted by Action, ascending, with no manual sorting capabilities

For repeatable fields:

Show each high level field on one line

For inner fields:

Show each field value in bullets

MARC-specific modal:

• “Field” column should contain the field number

• “Changed from” should contain the indicator values and the field string with subfields

• “Changed to” should contain the indicator values and the field string with subfields

In the mockups, the user name is hyperlinked - does this just go to the user record?

Yes

20 Dec 2024

Assuming that the highlight of fields changed (as implemented by Acquisitions) should be considered out of scope?

Yes

20 Dec 2024

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

20 Dec 2024

(CSR needs to come up with the list of fields to exclude)

• If we don’t want to include these changes to the item record audit log: Need list of fields to ignore on the item record that are updated from the holdings record changes

16 Jan 2025

Do we include a change of “Shared” for ECS?

Yes. If a local record is shared, include a change of promoted to shared

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.

• To be able to show that the record (instance and related MARC bib record) was not created but shared we need to solution

  • 1/16/24: Specific event sent by mod-inventory so we can do this

• For retaining local history when shared: Need to review with Folijetto think about if we need to move audit history to central tenant

  • Determine scope and LOE for retaining the local history

    • Would require moving local mod-audit to central mod-audit

    • Would potentially require both Folijet and Spitfire; depending on solution

    • Note: If user does not have a shadow user in central tenant

• Need more detailed requirements

20 Dec 2024

• • • , this would not be able to be shown in the audit log for a shared record

  • Decided that it will not be included

21 Jan 2025

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.

• Potentially not feasible: On backend, we do not specify whether it’s duplicated/derived, only that it is created *

*could be similar to effort of “via” line that we omitted

20 Dec 2024

14 Jan 2025

Do we include a change if

• holdings moved to another instance

• items moved to another holdings

Yes

• Moving to another instance/holdings

  • Show some sort of indication that record was moved “Record (moved)” under a header of “Changed”

• Christine Schultz-Richert to talk to Kimie

Changed

• Holdings ownership in ECS: Need to review with Folijet about implementation

• Moving holdings/items: Will have change on backend; more of a question about how to show on UI

• record (Moved)

• Moving the record just changes the id (not recording this change would be more effort)

21 Jan 2025

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

16 Jan 2025

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?

Needs further discussionExisting story for configuring retention period

• For now there is no archiving capability included in design; configuration for retention period but not for archiving

• Need to define what we mean by “archive” and if it’s really needed

16 Jan 2025

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:

• there is a situation where data is reordered within the record?

• there is a situation where record is moved?

Do not include as a change

27 Jan 2025

Confirm whether there will be changes logged when records are linked together? (might show with parent/child?)

Confirm whether a tag added to holdings will be reflected in change log

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
PS: Relationships are stored in the instance_relationship table, treating relationships as separate entities. Therefore, incorporating them into the audit log would require additional effort: creating domain events for relationships, consuming these events, and documenting the changes in the instance audit database table.

21 Jan 2025

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

27 Jan 2025

Do we need to implement this issue (

Requires Kalibek Turgumbayev to review question.

Specific story not related to feature

14 Jan 2025

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?

Requires Kalibek Turgumbayev to review question.

Not related

14 Jan 2025

Requirement for showing only 15 cards at one time (need UI requirements)

• What if the entire card won’t fit on the screen, do we wrap or something else (collapsing, additional see more button?)

• Do not make cards expandable/collapsible

14 Jan 2025

How do we show change history when the multiple 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 show the inner fields that have changed, just the higher level field.

• See answer

• Need requirements:

  • Potentially just show that the contributors list was updated

  • If there are multiple contributors changed, do we have one line that contributor(s) were changed or multiple lines with each contributor

  • For inner fields of objects, how should we display these changes?

  • Do we append the index/order into the name of the field, like "contributors.0.xxx" or "contributors[0].xxx" when showing in the change history

26 Jan 2025

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)

16 Jan 2025

Will we add the highlighted fields on the record in the future?

How will we show which values have been changed?

• Modal that contains the field changed at the value level (changed from/changed to)

• 23 Jan 2025 CSR worked with UX and there is a proposal for UI implementation that would deviate from the acquisitions pattern if we do not change our design. There is a meeting with POs on Friday 24 Jan 2025 to talk about any differences in patterns.

• Potential for changing implementation to capture the snapshots of entire records; awaiting more data on the impact

  • Example from testing environment is that ~96% of records were touched in the last year and there were millions of records in audit log compared to ~500k in acquisitions (but this is just testing environment and we haven’t yet tested elsewhere so it is not production environment)

    • Christine Schultz-Richert - ask about stats regarding record changes vs individual field changes.

27 Jan 2025

Will we add the rollback capability in the future?

Yes

• N/A until planned in future release (would require some level of changes to current design)

14 Jan 2025

Do we include bound-with changes?

No

16 Jan 2025

What do we do with records that are already in the system?

• Check with Thunderjet FE - maybe pulling metadata component?

  • Capture just at the first update

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

16 Jan 2025

Do/where we display deletions for instances and authorities?

No, we do not need to display deletions for instances or authorities

16 Jan 2025

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.

21 Jan 2025

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

• Keep only last update of delete

If it’s more difficult to not track create, then keep. If it’s easier to ignore, then just do that.

16 Jan 2025

30 Jan 2025