[Bug 7255] New: Information on Holds Transfer Slips is Inconsistent
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Bug #: 7255 Summary: Information on Holds Transfer Slips is Inconsistent Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall@gmail.com ReportedBy: nengard@gmail.com QAContact: ian.walls@bywatersolutions.com CC: ago@bywatersolutions.com, gmcharlt@gmail.com 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 --- Comment #1 from Kyle M Hall <kyle.m.hall@gmail.com> --- Created attachment 8767 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8767&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8767|0 |1 is obsolete| | --- Comment #2 from Kyle M Hall <kyle.m.hall@gmail.com> --- Created attachment 8768 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8768&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8768|0 |1 is obsolete| | --- Comment #3 from Kyle M Hall <kyle.m.hall@gmail.com> --- Created attachment 8769 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8769&action=edit Bug 7255 - Information on Holds Transfer Slips is Inconsistent -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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'? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 --- Comment #5 from Kyle M Hall <kyle.m.hall@gmail.com> --- (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'?
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #6 from Chris Cormack <chris@bigballofwax.co.nz> --- (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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Albert Oller <ago@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwagner@ptfs.com --- Comment #7 from Albert Oller <ago@bywatersolutions.com> --- *** Bug 3686 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hbraum@nekls.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Rafal <rkk0@poczta.onet.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@ccsr.qc | |.ca --- Comment #8 from Rafal <rkk0@poczta.onet.pl> --- *** Bug 10770 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 --- Comment #9 from Heather Braum <hbraum@nekls.org> --- 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Rafal <rkk0@poczta.onet.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkk0@poczta.onet.pl --- Comment #10 from Rafal <rkk0@poczta.onet.pl> --- (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? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Kyle, could you take a look at the patch on bug 10770? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@quecheelibrary.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #12 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 --- Comment #13 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=13482 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7255 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|In Discussion |RESOLVED --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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 *** -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org