JIRA | columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | FOLIO-2474 |
---|
|
| inventory, mod-circulation (Requests) |
|
| FOLIO Cross-Application Data Sync Proposal |
11 | Fee/fine syncing - when a fee/fine is created, some information on the inventory record is copied to the fee/fine. If information on the inventory record(s) changes after that point, the changes are not updated to the fee/fine record.
Note that some attributes on the fee/fine record should NOT be updated if they change in inventory, because the historical data was the basis of the charge. For example, an item's effective location should remain what it was when the fee/fine was charged, even if it is later updated in Inventory. |
|
| Users, check in, loans data, fee/fines data |
|
| FOLIO Cross-Application Data Sync Proposal |
12 | Loans data - when a loan is created, information about the item and the user is copied to the loan record. If information on the user changes after the loan is created, it's unclear if information is updated on the loan. For example, if a patron's name changes, it should copy over to the loan.
Similarly, if a holding/item is moved, it's unclear what information is updated or not on the loan (and some of that information perhaps should not be updated, or the move of the holding/item should be prevented.)
|
| N/A
Loans doesn't actually copy much data, other than effective location at checkout and patron group at checkout, and those aren't meant to be updated.
| Users, Inventory, loans data | Users is source of truth for patron identifying information. |
| N/A |
13 | Show dependencies/Backlinks in user record to all the apps the user is listed in eg as contact in eManagement or Licenses |
| N/A | Users |
|
| N/A |
14 | Organization name updated should be synced with cached name in Agreements and Licenses |
|
| Users, Agreements, Licenses |
|
| FOLIO Cross-Application Data Sync Proposal |
15 | Request state and details: some modules outside of mod-circulation may need to be aware of changes in the state or details of a request to perform actions such as communicating with a 3rd-party request broker. Other possible use-cases are modules/systems to monitor request and perform real-time printing of page slips or other automated monitoring. |
| An event queue of actions on requests that can be consumed by modules outside mod-circulation when actions are performed on open requests (create, update) | mod-circulation (Requests), mod-inn-reach (INN-Reach) |
|
| FOLIO Cross-Application Data Sync Proposal |
16 | Loan state and details: some modules outside of mod-circulation may need to be aware of changes in the state or details of a loan in order to perform actions such as communicating with a 3rd-party request broker. Other possible future use-cases include alternative notice systems. |
| An event queue of actions on loans that can be consumed by modules outside mod-circulation when actions are performed on open loans (create, update) | mod-circulation (Loans, Check in, Check out), mod-inn-reach (INN-Reach) |
|
| FOLIO Cross-Application Data Sync Proposal |
17 | Updates to Tags should be notified in such a way that any cached tag label in Agreements and Licenses can also be updated NB currently tags cannot be updated so this is not an immediate issue |
|
| Tags, Agreements, Licenses |
|
|
|
| Deletions |
|
|
|
|
|
|
---|
18 | Delete user record in UI with check for dependencies in other apps and/or inform other apps that user record has been deleted
e.g. Agreements and Licenses both store user UUIDs to link an agreement or license to a user. If that user is deleted then agreements/licenses continues to reference and link UUID even though record deleted |
| |