[Koha-bugs] [Bug 24800] New: Koha does incomplete checkin when no return date is provided
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Wed Mar 4 15:31:20 CET 2020
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24800
Bug ID: 24800
Summary: Koha does incomplete checkin when no return date is
provided
Change sponsored?: ---
Product: Koha
Version: master
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P5 - low
Component: SIP2
Assignee: koha-bugs at lists.koha-community.org
Reporter: katrin.fischer at bsz-bw.de
QA Contact: testopia at bugs.koha-community.org
CC: colin.campbell at ptfs-europe.com,
kyle at bywatersolutions.com,
martin.renvoize at ptfs-europe.com
We found that when a checkin is requested by the self check without a return
date, Koha will check the item in, but fails to send a checkin response and
crashes and create inconsistent/invalid data:
- It will remove the issue from the patron account and move to old_issues. BUT:
- the old_issues.returndate will be an invalid date: 0000-00-00
- there is no return recorded in action_logs
- there is no reutrn recorded in statistics
- The reading history will show an empty return date.
We found this in the context of an 'cancel checkout' feature in a lot of
libraries using hardware and software by one of the big international RFID
providers. We identified several 100 of those over a period of 1.5 years.
What happens?
- Self check requests checkout
- Koha responds that item was checked out
- Self check tries to desensitize
- Item has been removed from the self check already!
- Self check requests checkin with cancel flag set to Y and return date empty
- Koha doesn't respond, but dies
This all happens within a second or less.
>From the logs:
Sip::MsgType::_initialize('Checkin',
'N20200303 151300 APXXXX|AOXXXX|ABb00000057|ACxxxxxx|BIY',
'CA18A18', '37', ...)
Mar 3 15:13:00 xxxx xxxx[16798]: new ILS::Item('b00000057'): found with title
'Irrlicht und Feuer :'
Mar 3 15:13:00 xxxx xxxx[16798]: raw_transport: shutting down
Note the BIY in the Checkin request.
In some older 3M documentation I found the following explanation about the
cancel functionality:
"Checkin, Message 09
Cancel (Y or N) This field is set to N when a normal checkin of materials is
being requested. This field shoudl be set to Y when a previous Checkout message
failed. It is possible for a checkout command to fail. This problem occurs when
a patron removes the item from the 3M selfCheck system creadle after it has
been checked out by the ACS software but before the item has been desensitized
by the 3M selfCheck system. If this happens, the 3M SelfCheck system would
cancel the Checkout by sending a Checkin message with the cancel field set to
Y. The ACS software can also use this feld process the checkin differently (for
example don't count it in the Checkin statistics and possibly decrement the
Checkout statistics, also) ...
Return date
In current applications this field is not used."
The last bit is strange as other documentation I found clearly list it as a
required field in the Checking message:
Some possible solutions:
1) Deny checkin, keep the item on the account.
- We don't support cancel checkout.
- The patron might have items on their account, that they have left in the
library.
2) Check-in item and use server time for return date
- The patron might leave with an item not checkout out, especially if the
library has no gates.
- We wil have entries of this happening in like a split second, which will help
diagnose the problem.
3) Implement the cancel checkin
- This would probably be the hardest to do - we'd need to set some kind of flag
that it was a cancelled checkout to indicate that there might have been an
issue on the self check machine (maybe 2) + note in the logs?)
It would be interesting if someone can tell if they also had issues with this
and what they think the best solution would be. Koha SIP2 crashing and making
incomplete database entries doesn't appear the right behaviour atm.
--
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.
More information about the Koha-bugs
mailing list