When a cataloger is in bibliographic record-making changes, it would be nice to alert other staff (if they happen to be in the same bibliographic record) with a message box to indicate another staff member is also making changes. Additionally, allow staff to view the bibliographic record but not make changes if another staff member is also in the bibliographic record. This is a concern for larger consortiums that share records to have some sort of fail-safe method of making sure edits by any staff are saved.
How do you remove the lock or whatever mechanism implemented when the record is opened and never saved (browser crashed etc.) ? To prevent keeping it locked for no reason..
Created attachment 139046 [details] [review] Bug 31109: POC This patch tries to use the 005 to determine if the record has been altered before saving We would need to adjust other areas, and maybe return a diff? Just a POC to play with
+10 for it! Cf. also bug 23705. If I understand well the Nick's idea, the looser would only get an info after all work he has done, that his record has not been saved. Am I right? This would be a pity especially when the cataloger just put a lot of effort in correcting the record (for a complicated, non standard material). And - if I get it right - this would not work even for the first to save if he touched 005 field in the editor an so automatically updated it. The topic is IMHO far more complex. It includes also a parallel case of authority editing and - to complicate it further - updating an authority record used in an biblio record currently open for edition. And even further: checking out/in an item currently in edition (may be purely theoretical case, but could happen), or the same user modified by two agents (two librarians, which may be only theoretical, but a librarian and an external system like a faculty software interacting through API is not a theoretical case, I think). So - don't we need a general locking/unlocking system for everything and inserted check actions when somebody/something tries to modify a locked resource? For human actions - as it points Marcel - probably a timeout would be needed for a case of abandoned session? And possibly a mechanism for extending the lock if the interactive edit takes more than the timeout time. Looking forward to the comments...