[FOLIO-2027] Data Problems from Front-End Record Caching Created: 20/May/19  Updated: 18/Jan/21

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Jakub Skoczen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-2028 SPIKE: how to handle update conflicts? Closed
relates to UXPROD-1752 Prevent update conflicts (via optimis... Closed
relates to UXPROD-2796 Prevent update conflicts when doing m... Closed
relates to UXPROD-2797 Prevent update conflicts (1 user and ... Closed
relates to UXPROD-2798 Prevent update conflicts (two automat... Closed
relates to MODINVSTOR-656 enable "detection-only" OL for instan... Closed
Sprint:
Development Team: Core: Platform

 Description   

Background: This was reported by Björn Muschall and Annika Schröer

Steps to repro:

  1. Working with two browser sessions simulating the simultaneous work of several colleagues in one system
  2. User A opens a holding view page, User B opens the same holding view page
  3. User A edits this holding (e.g. location)
  4. User A updates the record
  5. User B clicks shortly afterwards on edit

Actual behavior: User B does not get the latest version of the record, because the form is filled with information from the state of his/her view page.

Expected behavior: The edit form should load the latest data from the database not from the view cache. Even though it may be unlikely that two colleagues are working on a record at the same time, this behavior leads to an incomprehensible inconsistency of the data. This is unacceptable for productive use.

Additional info: This behavior was already reported at a UAT for Vendors App months ago and should be discussed urgently in the community! This issue should not be underestimated.



 Comments   
Comment by Jakub Skoczen [ 20/May/19 ]

Cate Boerema I have linked this item to a more general issue: FOLIO-2028 Closed (which is a known tech-debt item). The description here suggests, however, that a ui-only "tweak" of refreshing the date in UI when the "edit" button is clicked might help alleviate the problem. I'd like to get feedback from Zak Burke and Marc Johnson. Also, please review FOLIO-2028 Closed because the technical approach there might impact the UX of record updates.

Comment by Marc Johnson [ 20/May/19 ]

Jakub Skoczen Refreshing the record upon edit might help to reduce the window of opportunity for concurrent editing.

However a user can leave the UI open in edit mode for as long as they choose.

It might stop sequential edits, where edit is clicked after save by the second user, it is unlikely to stop concurrent edits.

Comment by Björn Muschall [ 21/May/19 ]

Thanks, Jakub Skoczen and Marc Johnson. You're right, refreshing the data in UI when clicking the "edit" button does of course not prevent concurrent edits. Nevertheless, from my purely librarian standpoint, I think that the actual data should be loaded directly from the database. We can gladly merge with FOLIO-2028 Closed and close this one if both aspects are considered.

Comment by Julian Ladisch [ 28/May/19 ]

This and FOLIO-2028 Closed are distinct issues and should not be merged. I've reworded the title and the description for clarity.

Generated at Thu Feb 08 23:17:39 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.