Summary: | Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record | ||
---|---|---|---|
Product: | Koha | Reporter: | Kelly McElligott <kelly> |
Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | bwsdonna, januszop, m.de.rooy, martin.renvoize |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23705 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31791 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Bug 31109: POC |
Description
Kelly McElligott
2022-07-06 14:36:59 UTC
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... |