Bug 11039 - SIP Server responds with valid CHECKIN to SC but fails to checkin item on Koha
Summary: SIP Server responds with valid CHECKIN to SC but fails to checkin item on Koha
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: 3.18
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact: Testopia
Depends on:
Reported: 2013-10-11 14:45 UTC by Barry Cannon
Modified: 2019-06-27 09:24 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Barry Cannon 2013-10-11 14:45:46 UTC
If a patron borrowers an item from Branch_A and attempts to return it in Branch_B, via a selfcheck system, the SIP server will respond with an valid CHECKIN response giving the impression the item has been checked in successfully. However, when the borrower record is viewed via the Staff client the patron still has the item checked out. This only appears to happen if the SysPref "AllowReturnToBranch" is set to "only the library the item is from". Switching this SysPref to "to any library" does apply the checkin. 

The same item - checked out in Branch_A and checked in at Branch_B - does flag an error on the staff client, dissallowing the checkin. This is not passed correctly to the SIP server.
Comment 1 Katrin Fischer 2015-10-01 07:48:34 UTC
We are seeing this behaviour as well it seems in a 3.18.8 installation.
Comment 2 Colin Campbell 2016-03-02 15:07:57 UTC
I managed to reproduce this when Barry first reported it. But rerunning the test script I used then against master the buggy behaviour does not occur, nor with the current 3.22 and 3.20 releases. I wonder if a subsequent patch to C4/Circulation or the ILS routines has rectified this as a side effect
Comment 3 Katrin Fischer 2016-03-03 06:39:22 UTC
That would be nice - thx for the update Colin!
Comment 4 Owen Leonard 2016-06-21 15:50:59 UTC
Since 3.18.x is now unmaintained and the bug is fixed in more recent versions I'm marking this as resolved.