Summary: | SIP server allows checkin of reserved item | ||
---|---|---|---|
Product: | Koha | Reporter: | Barry Cannon <bc> |
Component: | SIP2 | Assignee: | Barry Cannon <bc> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | clodagh.kerin, colin.campbell, magnus, marjorie.barry-vila, martin.renvoize, ujjwalguptax202, veron |
Version: | 3.22 | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25541 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: | Bug 15729 - SIP server allows checkin of reserved item |
Description
Barry Cannon
2016-02-03 14:55:34 UTC
Barry, I am very interested in the current workflow - is there a report you could share maybe? Katrin - not really. The libraries tend to just use the "Holds to pull" report in Circulation. This causes problems though if the item is re-shelved before the pull list is generated as it can led to a borrower trying to checkout an reserved item. Hi Barry, still helpful information - thx! I have another variation on this. Some of my libraries would like the checkin to go through, but then the borrower should be alerted that the books sh/he just returned has one or more holds on it, so it needs to be placed somewhere special. (In reply to Magnus Enger from comment #4) > I have another variation on this. Some of my libraries would like the > checkin to go through, but then the borrower should be alerted that the > books sh/he just returned has one or more holds on it, so it needs to be > placed somewhere special. When a book is returned on a self check machine, and the book has one or more holds on it, Koha adds these two fields to the checkin response: |CY<hold patron id|DA<hold patron name> (<patron email>, <phone number>)| So in theory, the self check machines that my customers have should be able to check if these fields are present, and act accordingly. If so, my scenario does not require any changes to Koha. Created attachment 95019 [details] [review] Bug 15729 - SIP server allows checkin of reserved item This patch allows the library to allow or dissallow items that are reserved to be checked in via a selfcheck machine. Some libraries perfer to deny the checkin transaction to force the borrower to return via the circ desk. Adds a new systempreference called AllowSIPCheckInOnHolds. To Test, apply the patch and run database update - Check Administration > System preferences > Circulation > AllowSIPCheckInOnHolds and set to "Don't Allow" - Find, or create, a biblio in the catalogue with more that one item and place a bib level hold. - Restart SIP instance on the server - Issue a checkin transaction call from a selfcheck machine or via the sip_cli emulator - Observe the checkin has been denied with screen message explaining why. - Delete the hold on the biblio record. - Create a new hold item-level hold on the same biblio record - Try the transaction again with the item that has an item-level hold. - Observe the checing has been denied. - Try the transaction again with an item attached to the biblio that does not have an item-level hold - Observer the checkin is allowed. - Change the System preference AllowSIPCheckInOnHolds to "Allow" - Restart the SIP instance on the server - Preform the checkin transaction above again and notice they are now permitted Can we parhaps mark this as resolved duplicate of bug 25541 now? I realise they work in different ways and perhaps this still has something to offer as a global option? |