Bug 15729 - SIP server allows checkin of reserved item
Summary: SIP server allows checkin of reserved item
Status: RESOLVED DUPLICATE of bug 25541
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: 3.22
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Barry Cannon
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-03 14:55 UTC by Barry Cannon
Modified: 2021-03-30 13:01 UTC (History)
8 users (show)

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


Attachments
Bug 15729 - SIP server allows checkin of reserved item (7.12 KB, patch)
2019-11-04 16:54 UTC, Barry Cannon
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Cannon 2016-02-03 14:55:34 UTC
At present the SIP server will allow an item to be returned even if there is an outstanding hold on it. Some libraries do not see this as an issue and run reports for reserves before re-shelving. However, some prefer to have the item denied at the selfservice unit and force the borrower to return the item to the desk. With this in mind there should be a SIP systempreference which allows libraries to specify if a reserved item should be permitted to be checked in via the selfservice unit
Comment 1 Katrin Fischer 2016-02-23 21:58:54 UTC
Barry, I am very interested in the current workflow - is there a report you could share maybe?
Comment 2 Barry Cannon 2016-02-29 10:48:13 UTC
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.
Comment 3 Katrin Fischer 2016-02-29 11:28:28 UTC
Hi Barry, still helpful information - thx!
Comment 4 Magnus Enger 2016-10-05 12:11:31 UTC
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.
Comment 5 Magnus Enger 2016-10-05 14:05:00 UTC
(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.
Comment 6 Barry Cannon 2019-11-04 16:54:54 UTC
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
Comment 7 Martin Renvoize 2020-09-16 16:36:27 UTC
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?
Comment 8 Martin Renvoize 2021-03-30 13:01:19 UTC

*** This bug has been marked as a duplicate of bug 25541 ***