---- Reported by colin.campbell@ptfs-europe.com 2009-09-16 08:22:11 ---- When an Item is returned via SIP2 the unit is being correctly alerted that it is required for a hold and the details of the hold. However unlike a normal check in the status of the hold does not reflect that the item has been captured. This causes problems in the work flow, forcing sip2 checked in items to be manually checked in before the hold is shown as waiting or in transit to pickup location. ---- Additional Comments From colin.campbell@ptfs-europe.com 2009-09-16 08:28:00 ---- Patch sent. ---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-16 17:15:28 ---- Created an attachment Proposed Patch Patch added to bug report --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:13 UTC --- This bug was previously known as _bug_ 3638 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3638 Imported an attachment (id=1471) Actual time not defined. Setting to 0.0 The original submitter of attachment 1471 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
What is the current status of this bug? There was some discussion about it on koha-patches, see below: -----Original Message----- From: koha-patches-bounces@lists.koha.org [mailto:koha-patches- bounces@lists.koha.org] On Behalf Of Colin Campbell Sent: Wednesday, September 16, 2009 1:48 PM To: Galen Charlton Cc: patches@koha.org Subject: Re: [Koha-patches] [PATCH] bug 3638 On CheckIn via SIP update the Hold status to waiting if Reserved On 09/16/2009 12:19 PM, Galen Charlton wrote: > I have a question about the workflow. Are most or all SIP2 > self-checkout devices capable of making sure that there's enough > notice given to the circulation desk so that the item actually gets > picked up and placed on the hold shelf or transferred? > Same concern occurred to me. You can assume if its captured at a circ desk it probably goes to the holdshelf, but for a selfcheck you lack that certainty. That said, most devices now have some kind of capturing and the recently added support for the extensions is basically info on the hold for that. Some libraries are using SIP2 to implement RFID so they are forced to check-in twice. I'm not sure of the best implementation for all workflows. It might be a case of needing a per account or institution flag as people could have both situations. One where the device checks-in and routes holds and transits as if a normal checkin and one where it checks in the book but needs a second manual checkin before placing the book on the hold-shelf (much as if the pickup location was another branch). Comments and suggestions welcome. C.
I am not sure how this can be tested. For us it's a big problem that checked-in books at the selfcheck don't change their status to waiting. It means another patron can check it out, because the hold has not been triggered on check-in. Would this problem be fixed by the patch?
Created attachment 4571 [details] [review] Improved Patch This more recent version captures items for holds at the self check and places them in transit if required. It also means that only one item is captrured rather than issuing hold messages on multiple items but capturing none
I am very interested in testing this and I see that some other SIP patches are pending in 'Needs Signoff'. Is it possible to setup a test environment for SIP2 that works with a local Koha installation? Are there tools that can be used for that? Any hints appreciated.
A while ago, I wrote very simple SIP2 implementation which enables me to send messages directly to Koha SIP2 server. https://github.com/dpavlin/Biblio-SIP2 We are using it to push same messages which we collected from network dumps with 3M SIP2 self-check implementation. They are just a few messages from complete SIP2 implementation, so this approach worked for us. sc-emulator.pl contain a lot of hard-coded values specific to our Koha installation, but can be easily modified, I hope :-) acs-proxy.pl is simple protocol wrapper which can be inserted in-between SC and ACS server to provide protocol dumps. We also experimented with 3M\ SIP2\ Development\ Kit/Program/SCEmul.exe running under Wine on Linux, but it's a complex emulator, and we don't see most of messages on wire anyway. We have some notes in Croatian at http://saturn.ffzg.hr/koha/index.cgi?sip2 but hopefully examples can be useful (and Google translate does a fair job of replacing few Croatian words with something understandable).
I've got a test directory with some SIP config files and startup and shutdown scripts so I can run up the SIP software using these config files in development branches. I've got a number of test scripts that open a socket to these sip ports then do basic sip operations charge/discharge etc. The sip messages are built up from the docs or if I'm looking at a specific problem its easy enough to copy the contents of messages from the logs. (really vim id my test tool) I'd second Dobrica's comments about not using the development kit emulator. I've used it in the past but found it didn't support lots of the fields that are important to libraries just doing very basic transactions.
Hi Dobrica and Colin, thx for your comments! Colin - could you share one of your test scripts?
Created attachment 5019 [details] test script example And example of a test script. This one issues two items then discharges them. Other requests like the various patron info request could be substituted.
Created attachment 5423 [details] [review] Proposed patch
Created attachment 5424 [details] [review] Proposed Patch
Testing in production showed that the initial patch while setting the status correctly did not address the whole of the problem. If the item is captured at branch X for a hold set to pickup at branch Y in needs to generate a branchtransfer to that branch otherwise the status is easily lost by staff and general dissatisfaction ensues have added a second patch which builds on the first, initiating the transfer
Colin, Are the two patches currently shown competing implementations, or complements to each other?
Patches complement each other see previous comment
Created attachment 9901 [details] [review] Bug 3638 Self Check Should Capture Hold Items Shelf Check was receiving messages saying item was wanted for a hold but the item was discharged to the shelf not associated with the hold or transited to the pickup location. The message was also being sent on discharge of items when a suitable item had already been captured. Checkin now associates the item with the hold and sets the appropriate data for a correct checkin response Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 9902 [details] [review] Bug 3638 : Captured Holds may need to generate a transfer If a discharged item is captured for a hold at another branch the selfcheck should generate a branchtransfer for it. This was complicated as the checkin routine was setting its own location from a field not set in many scm machines (e.g. 3M) also in ILS::Transaction the test for location was incorrect assuming that an empty string or undefined was a valid location Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Thanks for the test script example Colin, was very handy for testing.
First patch: modifies some subroutines in SIP/ILS/Item.pm to take borrowernumber/branchcode params, and set them for the hold. Moves hold handling to do_checkin instead of handle_checkin, and adds the processing from C4::Reserves we'd normally get in the staff client. Also strips out some commented lines. Marking as Passed QA. Second patch: Better handling of conditional (separate lines and shift instead of a Perl one-liner). Adds return_date to do_checkin call. Adds a call to ModItemTransfer where applicable. Bulk of work is to set a default current location, as the self check machine may not. Also marked Passed QA.
QA comment: I couldn't test the patch with a true selfcheck machine, but patch pushed. Colin, before the patch there was some perlcritic problems, they are still here after the patch. If you can submit a follow-up to fix them, that would be nice. Should be very easy (removal or "return undef" in favour of "return" and removing prototyping of subs) 16:11 ~/koha.dev/koha-community (new/bug_3638 $%)$ perlcritic C4/SIP/ILS/Item.pm C4/SIP/ILS/Transaction/Checkin.pm C4/SIP/Sip/MsgType.pm C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 89, column 3. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: Subroutine prototypes used at line 350, column 1. See page 194 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 352, column 26. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 353, column 51. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: Subroutine prototypes used at line 356, column 1. See page 194 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 359, column 28. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 360, column 28. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 361, column 61. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: Subroutine prototypes used at line 364, column 1. See page 194 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 366, column 25. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Item.pm: "return" statement with explicit "undef" at line 368, column 24. See page 199 of PBP. (Severity: 5) C4/SIP/ILS/Transaction/Checkin.pm source OK C4/SIP/Sip/MsgType.pm: "return" statement with explicit "undef" at line 408, column 3. See page 199 of PBP. (Severity: 5) C4/SIP/Sip/MsgType.pm: Subroutine prototypes used at line 797, column 1. See page 194 of PBP. (Severity: 5) C4/SIP/Sip/MsgType.pm: "return" statement with explicit "undef" at line 798, column 24. See page 199 of PBP. (Severity: 5)
Pushed to 3.8.x, will be in 3.8.2