In some cases (eg. when Staf Client Search is active), when user choose Edit->Delete record on record tool bar, browser don't wait for confirmation and goes immediately to delete record. To reproduce: 1. Search for some biblio records and choose one without items attached. 2. Note that there, must be "Return to search results" box on left side, bug works in that case, when in normal view everything work fine. 3. Click Edit->Delete record, watch that confirmation box shows, but don't wait for OK and runs immediately. If you are fast enough to click OK, then you get error as below, because record was deleted earlier. "Software error: Can't call method "title" on an undefined value at /home/koha/kohaclon/cataloguing/addbiblio.pl line 826."
This sounds like Bug 11817 which I thought was fixed. Are you testing in master?
(In reply to Owen Leonard from comment #1) > This sounds like Bug 11817 which I thought was fixed. Are you testing in > master? Yes, today's master. It's maybe similar but removing (unnecessary) href from delete link in cat-toolbar.inc fixes problem. I'll attach patch for a while.
Created attachment 33568 [details] [review] Bug 13254 - Delete record don't wait for confirmation In some cases (eg. when Staf Client Search is active), when user choose Edit->Delete record on record tool bar, browser don't wait for confirmation and goes immediately to delete record. To reproduce: 1. Search for some biblio records and choose one without items attached. 2. Note that there, must be "Return to search results" box on left side, bug works in that case, when in normal view everything work fine. 3. Click Edit->Delete record, watch that confirmation box shows, but don't wait for OK and runs immediately. If you are fast enough to click OK, then you get error as below, because record was deleted earlier. To test: 1. Apply patch. 2. Follow reproduce steps. 3. Check if waits for confirmation in all cases. 4. Check if deletes record after confirm.
I can reproduce the bug. After step 3 the confirmation dialog disappears after some seconds and advanced search page is displayed. After that, the biblio is gone. Setting to P3 since the Bug leads to data loss.
Created attachment 33581 [details] [review] Bug 13254 - Delete record don't wait for confirmation In some cases (eg. when Staf Client Search is active), when user choose Edit->Delete record on record tool bar, browser don't wait for confirmation and goes immediately to delete record. To reproduce: 1. Search for some biblio records and choose one without items attached. 2. Note that there, must be "Return to search results" box on left side, bug works in that case, when in normal view everything work fine. 3. Click Edit->Delete record, watch that confirmation box shows, but don't wait for OK and runs immediately. If you are fast enough to click OK, then you get error as below, because record was deleted earlier. To test: 1. Apply patch. 2. Follow reproduce steps. 3. Check if waits for confirmation in all cases. 4. Check if deletes record after confirm. Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch>
Created attachment 33586 [details] [review] [PASSED QA] Bug 13254 - Delete record don't wait for confirmation In some cases (eg. when Staf Client Search is active), when user choose Edit->Delete record on record tool bar, browser don't wait for confirmation and goes immediately to delete record. To reproduce: 1. Search for some biblio records and choose one without items attached. 2. Note that there, must be "Return to search results" box on left side, bug works in that case, when in normal view everything work fine. 3. Click Edit->Delete record, watch that confirmation box shows, but don't wait for OK and runs immediately. If you are fast enough to click OK, then you get error as below, because record was deleted earlier. To test: 1. Apply patch. 2. Follow reproduce steps. 3. Check if waits for confirmation in all cases. 4. Check if deletes record after confirm. Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Confirmed the problem and that the patch fixes it. Good catch!
Patch pushed to master. Thanks Rafal!
Dirty bug indeed. Can this be backported to 3.16.x ?
This bug shows that the behavior of the browser is sometimes dangerous : $('a[href*="biblionumber="]').click(function (ev) { ev.preventDefault(); window.location = $(this).attr('href') + '&searchid=' + me.searchid; }); In my opinion the selector 'a[href*="biblionumber="]' is too large. It may impact future code.
Please see also bug 13644 - this piece of code can also break links under some circumstances.
(In reply to Fridolin SOMERS from comment #8) > Dirty bug indeed. > Can this be backported to 3.16.x ? Pushed to 3.16.x, will be in 3.16.9
(In reply to Mason James from comment #11) > (In reply to Fridolin SOMERS from comment #8) > > Dirty bug indeed. > > Can this be backported to 3.16.x ? > > Pushed to 3.16.x, will be in 3.16.9 Thanks a lot ;)
Pushed to 3.14, will be in 3.14.15.