Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2796

Prevent update conflicts when doing manual edits (User A and User B)

    XMLWordPrintable

Details

    • Core: Platform
    • R1
    • R1
    • R1
    • R1
    • R2
    • R1
    • R1
    • R1
    • R1
    • R1

    Description

      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 (UXPROD-1752). 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.

      TestRail: Results

        Attachments

          Issue Links

            defines

            Umbrella - UXPROD-3058 Optimistic Locking

            • TBD - To be determined
            • In progress
            is blocked by

            Task - A task that needs to be done. RMB-719 SPIKE: design protocol and implementation for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests UXPROD-1752 Prevent update conflicts (via optimistic locking): platform support for detection

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed
            is defined by

            New Feature - New feature requests MODINVSTOR-713 Enable support for optimistic locking (failOnConflict) in instances/holdings/items (part1)

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Task - A task that needs to be done. RMB-719 SPIKE: design protocol and implementation for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests RMB-727 Implement support for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIIN-1245 Implement optimistic locking in Inventory

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed
            relates to

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DEBT-1 No optimistic locking/update conflict resolution

            • P1 - highest priority item, drop everything else before this is resolved, reserved for critical bugfixes
            • Closed

            New Feature - New feature requests RMB-388 PostgresClient.getById with transaction, with "SELECT … FOR UPDATE"

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests RMB-688 PATCH to update only some JSONB properties

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Open

            Tech Debt - UIIN-730 Error message when item has been deleted from another window

            • P4 - lowest priority level, nice-to have things that require future discussion and design
            • Blocked

            Tech Debt - UIREQ-344 Deleting already-deleted request causes ungraceful error

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. FOLIO-2027 Data Problems from Front-End Record Caching

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Open

            Bug - A problem which impairs or prevents the functions of the product. MODINVSTOR-516 Cannot safely update holdings and items concurrently for any given instance

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests UXPROD-2798 Prevent update conflicts (two automated processes acting on the same record)

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            New Feature - New feature requests UXPROD-3089 Inventory. Implementing Optimistic Locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Activity

              People

                jakub Jakub Skoczen
                charlotte Charlotte Whitt
                Votes:
                0 Vote for this issue
                Watchers:
                18 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases