| Page Properties | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Overrides/Supersedes
...
This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.
Background/Context
The new Data export approach was designed for the following features:
- Export orders in bulk via delimited file format: https://issues.folio.org/browse/UXPROD-2318
- Build a report with rollover errors and store in CSV file: https://issues.folio.org/browse/MODFISTO-173
- Circulation log export to CSV: https://issues.folio.org/browse/UXPROD-2691
- Cornell Library's go-live requirements to transfer fees/fines to the Cornell bursar system: https://issues.folio.org/browse/UXPROD-2862
- The ability to import/export fund updates via CSV file in order to bulk edit funds: https://issues.folio.org/browse/UXPROD-199
...
- 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
...