This page is to outline issues and expectations on cross-app workflows, the handling of deletions and hanging references.
Define and describe the architecture for how to keep data in sync across multiple apps
Define and describe the architecture for seamless push and pull of data between apps (interaction)
Links & documentation
|Use case / Feature||Themes||Expected solution and/or bug reports||Apps|
Courses records store instructor information that can be pulled from the instructor's record in the Users app. If an instructor is added to a course, and then information on their user record changes, the updated/changed information does not propagate to the Courses app.
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. 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.
|When importing users using mod-user-import, externalSystemID, personal.lastname, and username are needed to prevent duplicate user records. In the UI, the following fields are also required to create a user: patron group, personal email, preferred contact type, and the active flag.||Users, mod-user-import|
User Barcode is required for checkout
(comment from Erin Nettifee-
|User ID or username, and password, are needed for login.||Users, mod-login|
|User Barcode, PIN, externalSystemID, password, in whatever combination are needed for SIP-2||Users, SIP2|
|When logging in using SAML, the mod-login requires externalSystemID, barcode, username, email, and possibly the Folio record number.||Users, mod-login-saml|
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.
|Update requester data (names, barcode) on requests if changed in the requesting user record||users, mod-circulation (Requests)|
|Update item and instance attributes copied to requests when the inventory instance, holdings, or item records are updated (if necessary)||inventory, mod-circulation (Requests)|
|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|
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.
|Users, Inventory, loans data|
|Delete user record in UI with check for dependencies in other apps.|
In the UI:
Through the API:
Do a general dependency check without deleting a user:
|Users, other applications|
Next steps as agreed on in Tech Leads meeting on May 12th 2021
- Provide a document/page that gathers information that we have to date and lists the problems in various apps
- List solutions that have been found for some of the issues as options
- Collect expectations how users would like the solution to be
There is a working group formed with App Interaction and Tech Leads members
From AI will take part: