Page tree
Skip to end of metadata
Go to start of metadata

UXPROD-3215 - Getting issue details... STATUS

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

VALIDATED

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

VALIDATED

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

VALIDATED

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"

VALIDATED

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

VALIDATED

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

User can see clearly what fields have been edited

PENDING



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?

CLOSED

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?

CLOSED

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:

UXPROD-204 - Getting issue details... STATUS

UXPROD-3215 - Getting issue details... STATUS

UI Stories

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

MOD Stories

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

  • No labels