https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #1 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- 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.. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=23705 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31791 CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #5 from David Cook <dcook@prosentient.com.au> --- In bug 34164 there is a need to track what page a user is/was on, so that they can be redirected back to it. We do that by storing data in the user session. In this bug, there's a need to know who else is on the same page as the user. But we don't currently have a robust way to query every user's session at the same time... I suppose one way to do it would be to have another table like "session_activity" which is keyed off the "sessions.id". We could populate that for all session activity or just for bib record changes to start. In the bib editor, we could send a heartbeat message to the API every X seconds, and the API could reply saying if anyone else has been editing that records in the last Y seconds. (Note: We'd have cascading delete set up for the foreign key to sessions.id, so that cleanup_database.pl would automatically clean up session_activity too on a nightly basis.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #6 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 167373 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167373&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #8 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 167375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167375&action=edit Bug 31109: Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167192|0 |1 is obsolete| | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167373|0 |1 is obsolete| | --- Comment #9 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 167415 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167415&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167375|0 |1 is obsolete| | --- Comment #11 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 167417 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167417&action=edit Bug 31109: Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- Overall, I think that this concept is a nice simple way of dealing with record modification collisions. Although I don't think I'd call it "Add ability to lock bibliographic record or alert staff when another user is int he same bibliographic record", as it does neither of those things. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167415|0 |1 is obsolete| | Attachment #167416|0 |1 is obsolete| | Attachment #167417|0 |1 is obsolete| | --- Comment #20 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 167436 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167436&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #22 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 167438 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167438&action=edit Bug 31109: Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. Sponsored-by: Ignatianum University in Cracow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add ability to lock |Prevent overwriting |bibliographic record or |bibliographic records in |alert staff when another |case of simultaneous |user is in the same |modification |bibliographic record | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |januszop@gmail.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167436|0 |1 is obsolete| | --- Comment #24 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 167492 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167492&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167439|0 |1 is obsolete| | --- Comment #26 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 167494 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167494&action=edit Bug 31109: Prevent overwriting bibliographic records in case of simultaneous modification Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #27 from David Cook <dcook@prosentient.com.au> --- (In reply to Janusz Kaczmarek from comment #18)

(In reply to David Cook from comment #16)

...

Also, why create Koha::Util::Misc when you could just use Digest::MD5 on the MARCXML representation of the record returned by $biblio->metadata?

Thanks for your comments, David.

First off all, to save time. The proposed solution is time efficient, and generating MARCXML costs time (like 12 times more than the proposed approach).

Except that you're fetching the MARCXML from the database already, so you don't need to generate it ;). Instead of '$orig_rec = $biblio->metadata->record' you'd have $orig_rec = $biblio->metadata->metadata' Theoretically, your approach should actually take longer than using the MARCXML as fetched from the DB, as it's fetching the MARCXML then turning it into a MARC::Record object, and then turning it into a binary format. That's a lot of extra steps, which aren't really necessary.

Secondly, to have a general digest procedure, not only for MARC records, but for all types of objects. (It works fine also for Koha::Object objects, like Koha::Patron, Koha::Item, etc.).

That sounds a bit like premature optimization to me.

Also, I couldn't find an existing module suitable to house the digest function. Hence the Koha::Util::Misc.

I thought we had a bit of a prohibition against "Util" and "Misc" in the coding guidelines but apparently not. I think it might be a bit of an unspoken rule, which keeps getting broken heh. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #29 from David Cook <dcook@prosentient.com.au> --- Going to Fail QA again for the use of the Exporter. Curious to get other QAers/RM input about Koha::Util::Misc. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #31 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Phil Ringnalda from comment #30)

Making users of the basic editor deal with merging changes after collisions while users of the advanced editor still get to just clobber changes doesn't sound like a nice idea.

I think maybe sometimes it's just one step after the other. Having a working concept in one place can lead to more improvements in other spots. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #33 from Phil Ringnalda <phil@chetcolibrary.org> --- Sweet that Bugzilla gave me a "mid-air collision detected" warning :) Not sure what to propose other than maybe behind a pref, off-by-default. I can absolutely see the benefit of this, say in a university library with a small number of well-trained catalogers who either know how to merge or can ask someone at the next desk over. But for me, with a couple users of the advanced editor and a large number of users of the basic editor who mostly know how to import a record and save it, but will sometimes notice a typo ten minutes later (by which time I've corrected five autocreated authority records) it's going to be baffling. And some of those are elementary school library aides behind generic logins that I don't even have a way to contact, much less to train to use the biblio merge UI. So whether or not it only affects basic editor users, I'll still have to find a way to make sure that for us, it pretty much never gets hit. If it lands unpreffed, I'll have to modify about 30 reports of cataloging errors to only tell me about them when the 005 says the record has been idle for several hours, and probably switch correcting bogus new authority records to leaving them bogus for at least 24 hours. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167492|0 |1 is obsolete| | Attachment #167493|0 |1 is obsolete| | Attachment #167494|0 |1 is obsolete| | --- Comment #34 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 168352 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168352&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #36 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 168354 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168354&action=edit Bug 31109: Prevent overwriting bibliographic records in case of simultaneous modification Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. N.B., this should work both with the basic and with the advanced editor. Sponsored-by: Ignatianum University in Cracow -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168352|0 |1 is obsolete| | --- Comment #37 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 168472 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168472&action=edit Bug 31109: Koha::Util::Misc - utility class with miscellaneous routines New module with only one function now: digest -- to calculate a md5_hex digest of the given argument (any Perl data structure). Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Roman Dolny <roman.dolny@jezuici.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #168354|0 |1 is obsolete| | --- Comment #39 from Roman Dolny <roman.dolny@jezuici.pl> --- Created attachment 168474 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168474&action=edit Bug 31109: Prevent overwriting bibliographic records in case of simultaneous modification Koha, till now, lacks the controll of concurrent modification of data. Perhaps the most urgent case is parallel modifications of a bibliograhic record by two independent agents. The proposed procedure, collision detection when saving a record, comes from Nick, who is also the author of the original version of the patch. This idea is simpler to implement than introducing a record lock. The idea of using a checksum to confirm that a record has not changed during editing comes from Jonathan. The other elements, including the implementation of redirecting to the merge page after a failed attempt to modify a record, come from Janusz. The checksum is passed to C4::Biblio::ModBiblio as an optional original_digest parameter, which in the future should perhaps be mandatory for all record modifications, including authority records and other Koha objects. The patch prevents also a possible collision between edit and merge. Test plan: ========== 1. In two independent browsers, A and B, open in parallel for edit the same bibliographic record. Make different changes in each browser. Save first A, then B. Reload the record in each browser. You should see, in both browsers, the version of the record modified in B. Note that you have lost the changes made in browser A without any warning. This is a serious problem. 2. Apply the patch; restart_all. 3. Repeat p. 1. While trying to save the record in browser B, you will be redirect to a merge page, with a warning about a conflict in modification, and with a possibility to merge your modification to the current version of the record, and, possibly, amend the record again in the regular editor. N.B., this should work both with the basic and with the advanced editor. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 --- Comment #41 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to David Cook from comment #40)

The functionality added by this patch could be done more simply using $biblio->metadata and Digest::MD5 on its own.

Note that we do not have a Koha::Biblio object for the modified version coming from the editor/mergeform. We just have the MARC::Record object.

I also notice that "koha-tmpl/intranet-tmpl/prog/en/includes/cateditor-ui.inc" uses a new SVC API called "svc/mid_air_collision".

While I don't think we have an explicit coding guideline forbidding new SVC API endpoints, I think there is an unwritten rule about this. I think all new API endpoints must be REST API endpoints.

The functionality of svc/mid_air_collision does not fit to REST API. I'm not quite happy happy with my svc/mid_air_collision idea, but: Feci, quod potui, faciant meliora potentes -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #43 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- I think I agree with David here - rather than a new svc route we should simply pass forward the record from the advanced editor and adjust merge,pl to be able to accept that as an input to compare against the existing record. If that proves very difficult I think we should instead save the record as a new record and direct to the merge, then if canceled the two records can be kept or the new one deleted. The Util class should probably be an object method should be avoided if possible as well -- You are receiving this mail because: You are watching all bug changes.