| Page Properties | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Overrides/Supersedes
...
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
...
- 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.
...
N/A
Constraints
N/A
Rationale
Analysis and options
Basically, 2 main alternatives can be suggested for the provided context:
...
It worth also noting that 
UICR-125 - Data corruption. When holding/item data are moved in Inventory, then the item in Courses is not updated accordingly OPENcase is slightly different and is about dangling references while not deletion but moving of a core-module record; neither cascade nor soft deletion is applicable here. At the same time, this case and cascade deletion case have one great similarity - in both, non-core-modules are to be notified about a change in core-module. In this context, a robust notification channel with guaranteed delivery to transfer change events from one module (say, module-source) to another module (say, module-recipient) is required. More details are on Data consistency and message driven approach # Notification channel.
Soft deletion option
More details regarding this option.
...
- 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
...