If hold items info is requested using a patron information request it is not returned. Sip devices need this to show to the user what books they have on hold and what holds they have awaiting collection. While the software goes through the motion of supplying this data, it has not retrieved it to populate the fields.
Created attachment 20777 [details] [review] Proposed Patch
Created attachment 20799 [details] [review] Revised patch Revised the patch to deal with a compile time error thrown by older (no longer supported) versions of perl. (unfortunately debian ships one of these)
Created attachment 20804 [details] Test script This script can be used to test the patch. Set up a user with some holds. Set up the configuration in the script and the script should setup a tcp socket connection to the designated server and will output the requests and responses
Created attachment 20838 [details] [review] Bug 10817 Return hold items info in Sip Patron Info Resp When requested by the summary flags the sipserver should return in the patron info response barcodes of the relevant titles. For available holds this is the barcode of the captured items. For unavailable holds ( i.e. icurrent unsatisfied holds ) We need to send a barcode so that the unit can use this to request the title info. The barcode could be any one belonging to the title. This patch also corrects the erroneous return of empty items in the patron information response. If the unir supplies a range 1 - 100 unless the title has a hundred or more copies the unit expects all copies. The server was erroneously stuffing the returned arrays with null copies so that all summary requests returned 100 copies (mainly without barcodes) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Hi Colin, working on this now - thank you for providing the test script! It's a great help in figuring this out.
Created attachment 20878 [details] [review] [PASSED QA] Bug 10817 Return hold items info in Sip Patron Info Resp When requested by the summary flags the sipserver should return in the patron info response barcodes of the relevant titles. For available holds this is the barcode of the captured items. For unavailable holds ( i.e. icurrent unsatisfied holds ) We need to send a barcode so that the unit can use this to request the title info. The barcode could be any one belonging to the title. This patch also corrects the erroneous return of empty items in the patron information response. If the unir supplies a range 1 - 100 unless the title has a hundred or more copies the unit expects all copies. The server was erroneously stuffing the returned arrays with null copies so that all summary requests returned 100 copies (mainly without barcodes) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Testing notes: Using the test script provided on the bug report, but changed it to match sip user and patron existing in my database. Before applying the patch the SIP responses show the behaviour pointed out above regarding the 100 items. After applying the patch and restarting the SIP server responses are much more clean not returning empty IDs. 64 Patron information response AS = hold items hold items count is correct. AS contains barcodes of waiting holds. Before patch, all AS were empty. AT = overdue items overdue items count is correct. AT contains barcodes of overdue items. AU = charged items charged items count is correct. AU contains barcodes of charged items. AV = fine items Judging from behaviour seen and comment in Patrons.pm currently not implemented. BU = recall items Recalls are not implemented in Koha yet. CD = unavailable hold items unavailable items count is correct. CD contains barcode for item level holds and is empty for title level holds where no item can be determined. Before patch, all CD were empty.
Pushed to master. Thanks, Colin!
This patch has been pushed to 3.12.x, will be in 3.12.7. Thanks Colin!