Summary: | If two catalogers work on same record, one overwrites the other | ||
---|---|---|---|
Product: | Koha | Reporter: | Hochschein <karin.hochschein> |
Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | alex.arnaud, black23, dcook, josef.moravec, m.de.rooy |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
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 |
Description
Hochschein
2019-02-01 14:01:05 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. (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! (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... 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? (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. Created attachment 90378 [details] [review] Bug 22249: Mana - Move comment process in a dedicated sub |