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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected]
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.
_______________________________________________
Koha-bugs mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
