| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Problem(s):
- 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:
| Requirement | Status | Use cases | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| User is shown what field was edited and when it was edited (Date and Time), in local timezone |
| 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 |
| 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 |
| 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" |
| 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 |
| Changes are only a concern after an order has been opened for the first time. | ||||||||
| User can reveal what fields have been edited, if needed. |
| 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. | ||||||||
| Track changes made by system users. Track updates made by the order to related records. Ie. pieces or encumbrances created or deleted. |
| System actions taken on the record are also recording in Aleph. When an order is rolled over or renewed for example, or encumbrances are released. |
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
Search and sort
User can filter by Category (Which accordion the field is found in), Source, Date and time of change
Users can search by Field name, Old value, New value
Highlight edited fields
System will indicate that a field has been edited
Requirements Board:
https://miro.com/app/board/uXjVObQrl6w=/?invite_link_id=742203032673
| Miro | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Questions:
Question | Status | Conclusion | Comments | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Should change log include user information? Would it need to be masked in some cases? |
| 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? |
| 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 Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
UI Stories
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
MOD Stories
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|