http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12514 Bug ID: 12514 Summary: Pressing 'print and confirm hold' on check in triggers race condition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: barton@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Library has the following set for RESERVESLIP: <p><font size="15"><<borrowers.surname>></font> </p> <p> <h5>Transfer to/Hold in <<branches.branchname>></h5> </p> <br /> <h4>ITEM ON HOLD</h4> <h3><<biblio.title>></h3> <ul> <li><<items.barcode>></li> <li><<items.itemcallnumber>></li> <li><<reserves.waitingdate>></li> <li><<reserves.expirationdate>></li> </ul> <p>Notes: <pre><<reserves.reservenotes>></pre> </p> When an item filling a hold is checked in, the circ staff clicks the 'print and confirm' button. Borrower and biblio information is printed on the slip, but item and reserve information is not. If the circ staff re-scans the barcode for the item, the confirm hold dialog boxes will re-appear; clicking 'print and confirm' a second time will print correctly, because by that time the reserves record will be populated. All holds filled at this library process slowly enough to trigger this bug. Unlike bug 11621, this is *not* an intermittent condition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.