Occasionally the ReserveSlip doesn't have any values from the koha.items-table. There is no apparent reason why. The issue seems to be more prevalent when fulfilling holds (checkin-in) to be transferred to another branch. Traced the issues to a race condition between printing a just-fulfilled hold and writing the itemnumber to the reserves-table. Can be reproduced by entering the following to a javascript console. Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&op=slip'); After this patch, one can confirm that it works by using this command: Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&itemnumber=10563811&op=slip'); MAKE SURE TO REPLACE PARAMETERS WITH CORRECT VALUES.
Created attachment 34528 [details] [review] Bug 13482 - A race condition prevents item info from being available for ReserveSlip (hold notice) printing. Occasionally the ReserveSlip doesn't have any values from the koha.items-table. There is no apparent reason why. The issue seems to be more prevalent when fulfilling holds (checkin-in) to be transferred to another branch. Traced the issues to a race condition between printing a just-fulfilled hold and writing the itemnumber to the reserves-table. TEST PLAN: 1. Find a borrower, make a hold for him, and check-in the book to trigger the "Hold found:"-prompt. Do not Confirm it! 2. Reproduce the print error by entering the following to a javascript console at the same page. Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&op=slip'); 3. Notice the missing item fields. After this patch, one can confirm that it works by using this command: Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&itemnumber=10563811&op=slip'); MAKE SURE TO REPLACE PARAMETERS WITH CORRECT VALUES.
Created attachment 34529 [details] [review] Bug 13482 - A race condition prevents item info from being available for ReserveSlip (hold notice) printing. Occasionally the ReserveSlip doesn't have any values from the koha.items-table. There is no apparent reason why. The issue seems to be more prevalent when fulfilling holds (checkin-in) to be transferred to another branch. Traced the issues to a race condition between printing a just-fulfilled hold and writing the itemnumber to the reserves-table. TEST PLAN: 1. Find a borrower, make a hold for him, and check-in the book to trigger the "Hold found:"-prompt. Do not Confirm it! 2. Reproduce the print error by entering the following to a javascript console at the same page. Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&op=slip'); 3. Notice the missing item fields. After this patch, one can confirm that it works by using this command: Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&itemnumber=10563811&op=slip'); MAKE SURE TO REPLACE PARAMETERS WITH CORRECT VALUES.
Could this be a duplicate to bug 12514 and bug 7255?
(In reply to Katrin Fischer from comment #3) > Could this be a duplicate to bug 12514 and bug 7255? Yes, I believe those should be marked as duplicates of this bug. The one has no patches, and the other has a patch that will never pass qa.
Created attachment 35664 [details] [review] [SIGNED-OFF] Bug 13482 - A race condition prevents item info from being available for ReserveSlip (hold notice) printing. Occasionally the ReserveSlip doesn't have any values from the koha.items-table. There is no apparent reason why. The issue seems to be more prevalent when fulfilling holds (checkin-in) to be transferred to another branch. Traced the issues to a race condition between printing a just-fulfilled hold and writing the itemnumber to the reserves-table. TEST PLAN: 1. Find a borrower, make a hold for him, and check-in the book to trigger the "Hold found:"-prompt. Do not Confirm it! 2. Reproduce the print error by entering the following to a javascript console at the same page. Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&op=slip'); 3. Notice the missing item fields. After this patch, one can confirm that it works by using this command: Dopop('hold-transfer-slip.pl?transfer=1&borrowernumber=10904891&biblionumber=469263&itemnumber=10563811&op=slip'); MAKE SURE TO REPLACE PARAMETERS WITH CORRECT VALUES. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Olli, could you please provide a couple of tests for this change?
Would be nice to see this moving - I could reproduce the issue whenever a hold is confirmed for the first time in Koha 3.18.5.1.
Created attachment 37956 [details] [review] [ALTERNATIVE PATCH] Bug 13482: Prevent race condition on printing a ReserveSlip The problem has been well described by Kyle and Nicole on bug 7255 description and comment 1. With this counter patch, I suggest to popup AFTER the return has been confirmed. This will remove the race condition and avoid to pass itemnumber to the pl file as in the patch submitted by Olli. Only the borrowernumber and biblionumber are needed (transfer and op are never used by circ/hold-transfer-slip.pl). Test plan: It is very hard to know all cases (at least 6) where the popup is displayed. Try at least to get the hold and the transfer confirmation messages. You should get the popup if you click on "print slip" button.
*** Bug 12514 has been marked as a duplicate of this bug. ***
*** Bug 7255 has been marked as a duplicate of this bug. ***
Tested alternate patch, I receive no popup print notice on the initial checkin, print & confirm hold, but I do on the second time around: http://screencast.com/t/s7lnVcBwox
Created attachment 38234 [details] [review] [ALTERNATIVE PATCH] Bug 13482: Prevent race condition on printing a ReserveSlip The problem has been well described by Kyle and Nicole on bug 7255 description and comment 1. With this counter patch, I suggest to popup AFTER the return has been confirmed. This will remove the race condition and avoid to pass itemnumber to the pl file as in the patch submitted by Olli. Only the borrowernumber and biblionumber are needed (transfer and op are never used by circ/hold-transfer-slip.pl). Test plan: It is very hard to know all cases (at least 6) where the popup is displayed. Try at least to get the hold and the transfer confirmation messages. You should get the popup if you click on "print slip" button.
(In reply to Kyle M Hall from comment #11) > Tested alternate patch, I receive no popup print notice on the initial > checkin, print & confirm hold, but I do on the second time around: > > http://screencast.com/t/s7lnVcBwox The print_slip hidden input was not set to 1 for 1 button, the one you tested :) Please try again.
Created attachment 38282 [details] [review] Bug 13482: Prevent race condition on printing a ReserveSlip The problem has been well described by Kyle and Nicole on bug 7255 description and comment 1. With this counter patch, I suggest to popup AFTER the return has been confirmed. This will remove the race condition and avoid to pass itemnumber to the pl file as in the patch submitted by Olli. Only the borrowernumber and biblionumber are needed (transfer and op are never used by circ/hold-transfer-slip.pl). Test plan: It is very hard to know all cases (at least 6) where the popup is displayed. Try at least to get the hold and the transfer confirmation messages. You should get the popup if you click on "print slip" button. Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
I found a problem, I hope this will be enough to reproduce: It's a transfer slip with a hold. What I did: - record with 1 item - staff user is in Midway - place record level hold with pickup location Fairfield - check item in in Midway - transfer slip is triggered (status is transfer now) - check the item in a second time in Midway - transfer slip is triggered BUT: Slip reads: no hold found Without the patch the slip is printed correctly.
Created attachment 38304 [details] [review] Bug 13482: Sent biblionumber to the template The biblionumber is sent to the template as 'itembiblionumber' at 1 place, the template get the 'biblionumber' variable. I don't understand why but the easy way is to sent the variable twice.
(In reply to Katrin Fischer from comment #15) > I found a problem, I hope this will be enough to reproduce: > > It's a transfer slip with a hold. > > What I did: > - record with 1 item > - staff user is in Midway > - place record level hold with pickup location Fairfield > - check item in in Midway - transfer slip is triggered (status is transfer > now) > - check the item in a second time in Midway - transfer slip is triggered > BUT: Slip reads: no hold found > Without the patch the slip is printed correctly. Good catch Katrin. This template is a mess, I tried to fix the problem easily.
Created attachment 38359 [details] [review] [PASSED QA] Bug 13482: Prevent race condition on printing a ReserveSlip The problem has been well described by Kyle and Nicole on bug 7255 description and comment 1. With this counter patch, I suggest to popup AFTER the return has been confirmed. This will remove the race condition and avoid to pass itemnumber to the pl file as in the patch submitted by Olli. Only the borrowernumber and biblionumber are needed (transfer and op are never used by circ/hold-transfer-slip.pl). Test plan: It is very hard to know all cases (at least 6) where the popup is displayed. Try at least to get the hold and the transfer confirmation messages. You should get the popup if you click on "print slip" button. Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 38360 [details] [review] [PASSED QA] Bug 13482: Sent biblionumber to the template The biblionumber is sent to the template as 'itembiblionumber' at 1 place, the template get the 'biblionumber' variable. I don't understand why but the easy way is to sent the variable twice. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Patches pushed to master. Thanks Jonathan!
Found an issue with this patch. Although most content now appears on first printing, it appears that the items.holdingbranch has incorrect data on first scan of item. It seems it prints the library code of the library receiving the item on the first scan. If you scan it again, it then shows the correct library code (the library that is scanning the item). Before the patch, this field was blank on first scan. Now it has the incorrect information on first scan. Christopher
Hi Christopher, this patch is already pushed - so it would be better to have the problem description on a separate bug depending on this one and linkng them. Can you tell which slip is the one that prints the wrong information? With a step by step instruction maybe?
Bug 14099 - thx Christopher!
Pushed to 3.18.x will be in 3.18.7
As a note, this change cause print window pop-up to be blocked by default by both Firefox and Chrome. In previous behavior, a print window pop-up is created when the print button is clicked so most browsers will allow it. In the new behavior, a print pop-up is created when the page reload, hence most browsers will block it by default. So now we have to explicitly set the browser to allow pop-up from Koha staff interface.