Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jira
serverFOLIO Issue Tracker
serverId6ccf3fe4-3301-368a-983e-20c466b11a49
keyUXPROD-3215

Problem(s):

  1. Order numbers in FOLIO can live for multiple fiscal years. Ongoing orders have a tendency to change over time and ideally users can edit things like publish and vendor reference numbers. Not knowing what the recent edit are can make orders confusing and delete old numbers etc means sacrificing historical information that could be valuable for acquisitions workflows.

Use Cases & Requirements:

RequirementStatusUse cases
User is shown what field was edited and when it was edited (Date and Time), in local timezone

Status
colourGreen
titleValidated

When updating vendor reference number on account of a publisher or platform change the library needs to know what is the most current vendor number.

When managing integrations having multiple numbers that could be a match point would be problematic. Users should be able to replace these without loosing the original historical information.

User is shown what the original value was and what new value was input

Status
colourGreen
titleValidated

When non-repeatable fields are changed we loose track of what the original value was. Perhaps the publisher changes or the assignee changes etc. knowing who was originally assigned to the order makes it easier to recover knowledge
User can filter through list of changes. Filtering on original value, new value or field name

Status
colourGreen
titleValidated

Over time many things can change on an order. After ten years it can be difficult to navigate the edit history, making it possible to loose information that you actually have in the system.
User is able to enter a note or reference a note such that it can be seen in the "change log"

Status
colourGreen
titleValidated

For ongoing e-resources or print. When publisher bought by other pub the prices can increase dramatically (Could be 200%). Valuable to make note why this jump happened as it could impact decision making moving forward

Entered into a 3 year contract and would get a certain price with specific increase over three years. Their system didn't catch it so the billing was done differently than expected. A deal was made to split the remaining payment over the remaining years and then the cost structure would be reverted. However the vendor didn't keep track of this. The notes about what happened help the library hold the vendor accountable. We may update this note a handful of times as this event plays out.

Changes tracking begins after order has been opened for the first time

Status
colourGreen
titleValidated

Changes are only a concern after an order has been opened for the first time.

User can see clearly reveal what fields have been edited.

Status
colourYellow
titlePending

In some systems certain fields are highlighted when changed (Eg. Vendor, Fund code) but not all. These are fields that are less likely to be changed.


Proposed workflow:

Access change log

Option 1

The "change log" live in an accordion on the record (Possible performance issue)

 Option 2

User clicks records action menu

Action menu includes "Change log"

User is presented the change log in a full screen overlay.

User can select an entry from the log and add a note. Note then displays in result list

View change log entry options

Option 1

Option 2 and 3


Show versions in log and display edits for the version. Either in third pane or with hierarchical list. Notes would be added for each version rather than each field in this scenario

Highlight edited fields

System will indicate that a field has been edited


Questions:

Question

Status

Conclusion

Comments

Should change log include user information? Would it need to be masked in some cases?

Status
colourGreen
titleCLOSED

Whatever is being done for last updated and created should be followed. No need for a specific solution for this log.

Ideally libraries could choose to mask source for GDPR

Should changes be tracked before order is opened?

Status
colourGreen
titleCLOSED

Changes should only be tracked after the order has been opened for the first time.Changes are only a concern after an order has been opened for the first time.


Work Breakdown Structure:

Features:

Jira
serverFOLIO Issue Tracker
serverId6ccf3fe4-3301-368a-983e-20c466b11a49
keyUXPROD-204

Jira
serverFOLIO Issue Tracker
serverId6ccf3fe4-3301-368a-983e-20c466b11a49
keyUXPROD-3215

UI Stories

Jira
serverFOLIO Issue Tracker
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQuery(issuekey in linkedIssues("UXPROD-3215") AND project in (UIOR, UIREC, UIV, UIF, UINV, UIORGS, STFORM, UIAC, UIPFO, UIPFCONT, UIPCITEM, UIPFINT, UIPFPOL)) OR (issuekey in linkedIssues("UXPROD-204") AND project in (UIOR, UIREC, UIV, UIF, UINV, UIORGS, STFORM, UIAC, UIPFO, UIPFCONT, UIPCITEM, UIPFINT, UIPFPOL))
serverId6ccf3fe4-3301-368a-983e-20c466b11a49

MOD Stories

Jira
serverFOLIO Issue Tracker
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQuery(issuekey in linkedIssues("UXPROD-204") AND project in (MODORDERS, MODVEND, EDGOAIPMH, EDGORDERS, MODCRED, MODFISTO, MODFUND, MODGOBI, MODINVOICE, MODINVOSTO, MODOAIPMH, MODORDSTOR, MODREC, MODORGS, MODINV, MODCONF, EDGOAIPMH, mod-organizations-storage, mod-organizations, MODEBSNET)) OR issuekey in linkedIssues("UXPROD-3215") AND project in (MODORDERS, MODVEND, EDGOAIPMH, EDGORDERS, MODCRED, MODFISTO, MODFUND, MODGOBI, MODINVOICE, MODINVOSTO, MODOAIPMH, MODORDSTOR, MODREC, MODORGS, MODINV, MODCONF, EDGOAIPMH, mod-organizations-storage, mod-organizations, MODEBSNET)
serverId6ccf3fe4-3301-368a-983e-20c466b11a49