Bug 7255 - Information on Holds Transfer Slips is Inconsistent
Summary: Information on Holds Transfer Slips is Inconsistent
Status: RESOLVED DUPLICATE of bug 13482
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Kyle M Hall
QA Contact: Ian Walls
URL:
Keywords:
: 3686 10770 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-11-23 14:40 UTC by Nicole C. Engard
Modified: 2015-04-20 15:16 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 7255 - Information on Holds Transfer Slips is Inconsistent (14.31 KB, patch)
2012-04-02 12:49 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 7255 - Information on Holds Transfer Slips is Inconsistent (14.31 KB, patch)
2012-04-02 12:51 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 7255 - Information on Holds Transfer Slips is Inconsistent (14.29 KB, patch)
2012-04-02 12:54 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2011-11-23 14:40:31 UTC
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.
Comment 1 Kyle M Hall 2012-04-02 12:49:37 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2012-04-02 12:51:32 UTC Comment hidden (obsolete)
Comment 3 Kyle M Hall 2012-04-02 12:54:47 UTC
Created attachment 8769 [details] [review]
Bug 7255 - Information on Holds Transfer Slips is Inconsistent
Comment 4 Katrin Fischer 2012-04-02 12:57:22 UTC
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'?
Comment 5 Kyle M Hall 2012-04-02 13:01:54 UTC
(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'?
Comment 6 Chris Cormack 2012-04-07 05:38:17 UTC
(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.
Comment 7 Albert Oller 2012-06-26 13:52:45 UTC
*** Bug 3686 has been marked as a duplicate of this bug. ***
Comment 8 Rafal Kopaczka 2013-10-30 09:06:39 UTC
*** Bug 10770 has been marked as a duplicate of this bug. ***
Comment 9 HB-NEKLS 2013-10-30 14:55:23 UTC
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.
Comment 10 Rafal Kopaczka 2013-11-06 13:31:50 UTC
(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?
Comment 11 Katrin Fischer 2013-12-05 00:18:29 UTC
Kyle, could you take a look at the patch on bug 10770?
Comment 12 Christopher Brannon 2014-10-02 19:06:31 UTC
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
Comment 13 Christopher Brannon 2014-11-25 19:45:43 UTC
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.
Comment 14 Katrin Fischer 2015-04-20 15:16:40 UTC
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 ***