Bug 22259 - If two catalogers work on same record, one overwrites the other
Summary: If two catalogers work on same record, one overwrites the other
Status: RESOLVED DUPLICATE of bug 23705
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-01 14:01 UTC by Hochschein
Modified: 2019-10-01 12:02 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 22249: Mana - Move comment process in a dedicated sub (5.87 KB, patch)
2019-06-06 15:08 UTC, Alex Arnaud
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Hochschein 2019-02-01 14:01:05 UTC
If 2 librarians edit the same cataloguing record at the same time, the last one to save overwrites the work of the other. There is not way to block the catalogue record for other cataloguers in your library.
Comment 1 David Cook 2019-02-04 06:52:21 UTC
I raised this issue many years ago but I don't think there was any interest in fixing it. 

My original idea was to implement row locking in the database.
Comment 2 Katrin Fischer 2019-02-04 06:58:59 UTC
(In reply to David Cook from comment #1)
> I raised this issue many years ago but I don't think there was any interest
> in fixing it. 

I think the problem is not interest, we can easily agree that this is not a good situation. But it will also need funding and agreeing on the right method in order to be able to fix it. 

I think it's good the problem is on bugzilla now, thx Karin!
Comment 3 David Cook 2019-02-04 23:07:57 UTC
(In reply to Katrin Fischer from comment #2)
> But it will also need funding and agreeing on the right
> method in order to be able to fix it. 

This is the part where my optimism fails.

> I think it's good the problem is on bugzilla now, thx Karin!

This is true. I'm actually surprised there aren't any Bugzilla issues about this already. Maybe Robin talked me down from posting it years ago...
Comment 4 Marcel de Rooy 2019-02-05 11:43:55 UTC
Hmm. This *issue* will probably not come up often in a well defined workflow? But on the other hand it should not be that hard to lock it somehow. Only when would you unlock if the page was abandoned?
Comment 5 David Cook 2019-02-06 05:11:26 UTC
(In reply to Marcel de Rooy from comment #4)
> Hmm. This *issue* will probably not come up often in a well defined
> workflow? 

I think that relies on a number of assumptions. I've had complaints about this from multi-branch/multi-library users of Koha, but you could have the following scenario in a single branch:

1. Library technician transcribes book and sends it to cataloguer for subjects and classification and leaves the catalogue editor open
2. Librarian starts opens record on screen and does their work
3. Library technician notices a typo in the existing editor tab on their browser. Saves it and accidentally erases the librarian's work

> But on the other hand it should not be that hard to lock it
> somehow. Only when would you unlock if the page was abandoned?

I don't think DBIx::Class is database lock friendly at all. 

In general, locking does seem difficult, as how would you know if a page was abandoned or some other related scenario. 

I suppose that's where session timeouts would come in, but that could also be problematic.
Comment 6 Alex Arnaud 2019-06-06 15:08:13 UTC Comment hidden (obsolete)
Comment 7 Katrin Fischer 2019-10-01 12:02:33 UTC

*** This bug has been marked as a duplicate of bug 23705 ***