Overrides/Supersedes
This decision was migrated from the Tech Leads Decision Log as part of a consolidation process. The original decision record can be found here.
This decision is now superseded by Data consistency and message driven approach.
RFC
N/A
Stakeholders
- Front-end and back-end devs of non-core modules that hold references to records in core-modules
Contributors
Approvers
This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.
Background/Context
- Deletion of records by core UI modules is problematic because it may leave dangling references to deleted records in non-core modules. Core modules are at the bottom of the hierarchy, unaware of the modules that sit above them in the hierarchy; this prevents core modules from issuing queries to identify such references. This is succinctly, if frustratingly, captured in the PR discussion related to UITEN-128.
- Even if we can resolve this in the UI (see notes, below) the possibility remains that direct API requests to delete records may leave dangling references in other parts of the system.
Assumptions
N/A
Constraints
N/A
Rationale
N/A
Decision
Yikes
Implications
- Pros
- N/A
- Cons
- N/A
Other Related Resources
Notes
- It may be possible to mitigate this in the UI by using the "handler" app-type to function as an event bus (since the UI bundle is deployed as a monolith, events published in one module could, potentially, be acted upon by another) but we don't actually have anything like this in production yet. We do have handler-modules, but don't have an established protocol for apps to issue their own events.
JIRAs
UITEN-128 - Permissions Architecture: Courses error when trying to delete location in BugFest CLOSED
UITEN-74 - Refuse to delete a location if it's in use by a course-listing or a course-reserve CLOSED
UICR-125 - Data corruption. When holding/item data are moved in Inventory, then the item in Courses is not updated accordingly OPEN