Bug 10817

Summary: SIPserver does not return holds info when requested
Product: Koha Reporter: Colin Campbell <colin.campbell>
Component: SIP2Assignee: Colin Campbell <colin.campbell>
Status: CLOSED FIXED QA Contact: Katrin Fischer <katrin.fischer>
Severity: normal    
Priority: P5 - low CC: colin.campbell, gmcharlt, jonathan.druart, katrin.fischer, tomascohen
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Medium patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 11783    
Attachments: Proposed Patch
Revised patch
Test script
Bug 10817 Return hold items info in Sip Patron Info Resp
[PASSED QA] Bug 10817 Return hold items info in Sip Patron Info Resp

Description Colin Campbell 2013-09-04 10:15:16 UTC
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.
Comment 1 Colin Campbell 2013-09-04 13:10:14 UTC Comment hidden (obsolete)
Comment 2 Colin Campbell 2013-09-05 13:27:52 UTC Comment hidden (obsolete)
Comment 3 Colin Campbell 2013-09-05 14:56:51 UTC
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
Comment 4 Chris Cormack 2013-09-07 00:33:05 UTC Comment hidden (obsolete)
Comment 5 Katrin Fischer 2013-09-08 09:24:20 UTC
Hi Colin,
working on this now - thank you for providing the test script! It's a great help in figuring this out.
Comment 6 Katrin Fischer 2013-09-08 10:28:38 UTC
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.
Comment 7 Galen Charlton 2013-09-08 19:54:36 UTC
Pushed to master.  Thanks, Colin!
Comment 8 Tomás Cohen Arazi 2013-11-06 14:35:54 UTC
This patch has been pushed to 3.12.x, will be in 3.12.7.

Thanks Colin!