Bug 10817 - SIPserver does not return holds info when requested
Summary: SIPserver does not return holds info when requested
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Colin Campbell
QA Contact: Katrin Fischer
URL:
Keywords:
Depends on:
Blocks: 11783
  Show dependency treegraph
 
Reported: 2013-09-04 10:15 UTC by Colin Campbell
Modified: 2015-06-04 23:23 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Medium patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed Patch (4.32 KB, patch)
2013-09-04 13:10 UTC, Colin Campbell
Details | Diff | Splinter Review
Revised patch (4.32 KB, patch)
2013-09-05 13:27 UTC, Colin Campbell
Details | Diff | Splinter Review
Test script (3.34 KB, application/x-perl)
2013-09-05 14:56 UTC, Colin Campbell
Details
Bug 10817 Return hold items info in Sip Patron Info Resp (4.38 KB, patch)
2013-09-07 00:33 UTC, Chris Cormack
Details | Diff | Splinter Review
[PASSED QA] Bug 10817 Return hold items info in Sip Patron Info Resp (5.49 KB, patch)
2013-09-08 10:28 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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!