Prevent update conflicts when doing manual edits (User A and User B)
Description
Priority
Fix versions
None
Development Team
Core: Platform
Assignee

Solution Architect
None
NoneParent Field Value
None
Parent Status
None
defines
is blocked by
is defined by
relates to
Checklist
hideTestRail: Results
Activity
Show:

Khalilah Gambrell June 14, 2021 at 8:27 PM
After talking with , I have decided to close this feature. will/have addressed the work to prevent conflicts. Each app/dev team will create a feature(s) to implement the work noted with
outlines the work to implement optimistic locking (OL) for the Inventory app. It is the first app to implement OL and will serve as the pattern for dev teams to apply OL to their apps/systems.
Duplicate
Details
Details
Reporter

Rank: FLO (MVP Sum 2020)
R2
Rank: 5Colleges (Full Jul 2021)
R1
Rank: Cornell (Full Sum 2021)
R1
Rank: GBV (MVP Sum 2020)
R1
Rank: TAMU (MVP Jan 2021)
R1
Rank: Chicago (MVP Sum 2020)
R1
Rank: MO State (MVP June 2020)
R1
Rank: U of AL (MVP Oct 2020)
R1
Rank: Leipzig (Full TBD)
R1
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created November 2, 2020 at 8:29 AM
Updated April 27, 2022 at 9:29 AM
Resolved June 14, 2021 at 8:27 PM
TestRail: Cases
TestRail: Runs
Problem statement
In FOLIO, most storage modules follow the "last writer wins" strategy for handling record updates. From the UI perspective this may lead to a situation when a stale record (older version of a give record) previously loaded into the UI may override a more recent version on the server. Hence relevant updates may get lost in the process and the user is not made aware of what has happened.
Proposed solution
From the storage and API perspective, optimistic locking is the proposed strategy to handle conflicts (). Handling of updates in FOLIO should rely on more explicit semantics, both in the storage (backend) APIs and the way it is communicated to the user through the UI.
Use cases
2 users editing the same record at the same time
User A and User B editing the same record at the same time (not frequent) – users, orders, instances, holdings, items, requests
User A editing an item and User B creating a request for that item
User A editing and item and User B putting that item on course reserve at the same time
User A editing an invoice and User B trying to approve the same invoice at the same time
User A editing an item and User B deleting the item before User A's edits are saved (see UIIN-730)
User A editing a request and User B cancelling the request before User A's edits are saved (see UIREQ-344)
When attempting to update holdings and their items concurrently the holdings updates will ever so often interfere with the item updates, effectively nullifying the latter (see MODINVSTOR-516). This particular item is being addressed via RMB-388.