Some of my libraries are experiencing situations where the items barcode number and call number sometimes print on the hold transfer slip and sometimes not. Other libraries have never had this information print on the slip. We've discovered that they've got a race condition in the code; when you click "confirm and print slip", you're both submitting the form that confirms the hold, as well as opening the transfer slip page. If this is a title-level hold originally, the item information (barcode and callnumber) isn't filled in until the form you've submitted completes it's action. So, depending on all kinds of server-level variables, the transfer slip process will either complete first, and not show item information, or complete second, and include barcode/callnumber. There is no way to tell which process will win the race ahead of time. So that's WHY it's a problem. As to how to fix it, we're not sure yet. The best solution would be to modify the page so that submitting the form completes, then triggers the hold slip (rather than both starting up at once), but that would involve an extensive reworking of the system. A quicker solution is to introduce a delay, but we're not sure exactly where yet.
Created attachment 8767 [details] [review] Bug 7255 - Information on Holds Transfer Slips is Inconsistent We've discovered that they've got a race condition in the code. When you click "confirm and print slip", you're both submitting the form that confirms the hold, as well as opening the transfer slip page. If this is a title-level hold originally, the item information (barcode and callnumber) isn't filled in until the form you've submitted completes it's action. So, depending on all kinds of server-level variables, the transfer slip process will either complete first, and not show item information, or complete second, and include barcode/callnumber. There is no way to tell which process will win the race ahead of time. This commit adds a new 'tool' to allow any popup to be loaded with a delay. A new javascript function has been added to allow this script to be used easily. Use the function as follows: delayPopup( url, message, delay ) where url is the url of the page to load ( supports GET variables ), message is an optional message to display, and delay is the amount of time in seconds to delay the loading of this new url. This tools is put into use in returns.tt to delay those slips that have a race condition.
Created attachment 8768 [details] [review] Bug 7255 - Information on Holds Transfer Slips is Inconsistent We've discovered that they've got a race condition in the code. When you click "confirm and print slip", you're both submitting the form that confirms the hold, as well as opening the transfer slip page. If this is a title-level hold originally, the item information (barcode and callnumber) isn't filled in until the form you've submitted completes it's action. So, depending on all kinds of server-level variables, the transfer slip process will either complete first, and not show item information, or complete second, and include barcode/callnumber. There is no way to tell which process will win the race ahead of time. This commit adds a new 'tool' to allow any popup to be loaded with a delay. A new javascript function has been added to allow this script to be used easily. Use the function as follows: delayPopup( url, message, delay ) where url is the url of the page to load ( supports GET variables ), message is an optional message to display, and delay is the amount of time in seconds to delay the loading of this new url. This tools is put into use in returns.tt to delay those slips that have a race condition.
Created attachment 8769 [details] [review] Bug 7255 - Information on Holds Transfer Slips is Inconsistent
I am not sure, but is a delay the right answer here? You wrote: >There is no way to tell which process will win the race ahead of time. So even with a delay it still needs 'luck' to get the right value and it will perhaps also depend on the installation/hardware? Shouldn't we fix the 'race condition'?
(In reply to comment #4) In theory you are correct, but in practice this has worked 100% of the time. A fix like this has been in place at the CCFLS for years now. A fix such as you propose would require much deeper alterations where clicking 'confirm and print' would send you to a new page which would then have another link for the printable popup, and then you'd have to click another link to get back to the returns page. Not only would it require more work, but I think it would slow librarians down and they would be more unhappy with such a solution. > I am not sure, but is a delay the right answer here? You wrote: > > >There is no way to tell which process will win the race ahead of time. > > So even with a delay it still needs 'luck' to get the right value and it > will perhaps also depend on the installation/hardware? Shouldn't we fix the > 'race condition'?
(In reply to comment #5) > (In reply to comment #4) > > In theory you are correct, but in practice this has worked 100% of the time. > A fix like this has been in place at the CCFLS for years now. A fix such as > you propose would require much deeper alterations where clicking 'confirm > and print' would send you to a new page which would then have another link > for the printable popup, and then you'd have to click another link to get > back to the returns page. Not only would it require more work, but I think > it would slow librarians down and they would be more unhappy with such a > solution. > > > I am not sure, but is a delay the right answer here? You wrote: > > > > >There is no way to tell which process will win the race ahead of time. > > > > So even with a delay it still needs 'luck' to get the right value and it > > will perhaps also depend on the installation/hardware? Shouldn't we fix the > > 'race condition'? I think this might work most of the time, when it didn't people probably wouldn't notice. I think fixing the actual problem not plastering over the cracks with a javascript delay is a much better solution.
*** Bug 3686 has been marked as a duplicate of this bug. ***
*** Bug 10770 has been marked as a duplicate of this bug. ***
There was discussion on this bug more than a year ago--is it going to move anywhere? What will it take for that to happen? I see Chris' comment that there's a deeper issue going on. Just curious -- this issue is affecting our libraries, too.
(In reply to Heather Braum from comment #9) > There was discussion on this bug more than a year ago--is it going to move > anywhere? What will it take for that to happen? I see Chris' comment that > there's a deeper issue going on. Just curious -- this issue is affecting our > libraries, too. In our library we are using solution that I've provided in patch for Bug 10770. So before printing in hold-transfer-slip.pl we call ModReserveAffect. Maybe it's not to good to call 2 times (in returns and hold-print-slip) this function for 1 reserve?
Kyle, could you take a look at the patch on bug 10770?
We would like to see this resolved. We are in 3.14 and still see this problem. My vote would be to not use a pause or call something twice. Perhaps I am oversimplifying this, but couldn't it be setup so that submitting the form with the "confirm and print slip" button just submits the form, and then calls the next step (printing) when completed? Or is the problem that both the "confirm" and "confirm and print slip" buttons both call the same submit form function? Could a switch be added to the function so that if "confirm and print slip" were clicked, it would pass on an extra switch or value to the submit function that would trigger the print when the function is complete? Again, I could be oversimplifying this, not knowing the code at all. Christopher
Would like to see this bug resolved. Aside from not having some important information on the list, it is impossible to add any logic functionality to the slips (which we do) that involves values that are not being populated properly.
There are another 2 patches on bug 13482 - marking this one duplicate to join all efforts on the bug that saw more work recently. *** This bug has been marked as a duplicate of bug 13482 ***