|#||Use case / Feature||Themes||Requirements and/or bug reports | Comments||Apps||Source of truth||Goal(s)||Proposed Solution|
Courses records store instructor information that can be pulled from the instructor's record in the Users app. (This is optional - instructors can also simply be added as text.)
|Courses, Users||Users is the source of truth for the instructor name, if the instructor was added from Users.||When an instructor on a course is linked to a FOLIO user object, and the instructor's name changes, Users should update the name in Courses.||FOLIO Cross-Application Data Sync Proposal|
Course records pull information about an item into the Courses app when an item is added to a course. (Information includes things stored on the item's parent holding and instance, like title, contributors, and electronic access information.) This is meant to support reserves-specific search needs in the Courses app, as well as integrations with outside course management systems like Sakai and Canvas. Once an item has been added as a reserve, if information about that item has been changed, it does not propagate to the Courses app.
Note that there have been some choices made in the Courses UI to pull information from Inventory for display to make sure that Courses staff are seeing the most up to date information - for example, an item's location. However, even though those changes display in the UI, they do not propagate to the underlying reserve data that is stored in the app itself.
|Courses, Inventory, Data Import||Inventory (source of truth for item information.)|
Courses (able to push updates on temporary location and temporary loan type back to Inventory, and have Inventory accept them.)
|Courses should be able to edit the temporary location and temporary loan type, and listen to changes in Inventory||FOLIO Cross-Application Data Sync Proposal|
|5||User ID or username, and password, are needed for login.||Users, mod-login|
Maintain relationship between apps when holdings/items are moved
Example use cases: a title is ordered as a separate monograph. When it arrives, it is actually a volume of a larger set and needs to be moved to the set record. A title is ordered is a second copy, but is accidentally placed on a record-bearing account, so a separate catalog record is supplied for it. It needs to be moved to a different record so both copies are associated with the same instance.
|FOLIO Cross-Application Data Sync Proposal|
|9||Update requester data (names, barcode) on requests if changed in the requesting user record||users, mod-circulation (Requests)||FOLIO Cross-Application Data Sync Proposal|
|10||Update item and instance attributes copied to requests when the inventory instance, holdings, or item records are updated (if necessary)||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|
|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|
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|
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
|Users, other applications|
Delete instance records in UI with check for dependencies in other apps.
Implications for other apps (added by related POs)
|Inventory, other applications||Inventory|
Delete Organization record in UI with check for dependencies in other apps and/or inform other apps that organization record has been deleted
e.g. Agreements and Licenses both store organization UUIDs to link an agreement or license to a organization. If that organization is deleted then agreements/licenses continues to reference and link UUID even though record deleted
|Organizations, Agreements, Licences|
|21||On attempt to delete License, do not delete if license is related to an agreement||Already implemented with a hardcoded lookup at the point the user tries to delete a license||Licenses, Agreements|
Delete Purchase Order Line record in UI with check for dependencies in other apps and/or inform other apps that organization record has been deleted
Delete Order line check for dependencies or inform agreements app (as POL UUID stored as link between agreement entitlement and a POL)
|23||Check on linked POLs/records when an Inventory Item/Holding/Instance is deleted via online update signal from union catalogue||Inventory, Orders, external system|