Bug 37625 - Update HoldsNeedProcessingSIP system preference description
Summary: Update HoldsNeedProcessingSIP system preference description
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords: Academy
Depends on:
Blocks:
 
Reported: 2024-08-13 14:00 UTC by Katrin Fischer
Modified: 2025-10-21 11:46 UTC (History)
2 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2024-08-13 14:00:52 UTC
The HoldsNeedProcessingSIP is very useful for libraries using SIP, but the system preference description doesn't tell you much. It would be nice to add some more information here about the intermediate status that will be assigned when you set it to "not fulfill" holds immediately. 

Also "returning" should be updated to "checking in".
Comment 1 Alexander Wagner 2025-10-21 10:48:19 UTC
Furthermore, one should also note here, that with `HoldsNeedProcessingSIP` set to `don't fulfill` items can not be promoted from `in preparation` to `waiting` by another SIP checkin. It seems that the second check in has to be performed from the Intranet only, as SIP checkins do not promote the items like regular check ins, but just set a fixed status. (Unfortunately.)

Sidenote: for a newbe like me the term `fulfill` was not really self explanatory in this context here as it referred only to the library having the item.
Comment 2 Katrin Fischer 2025-10-21 11:25:40 UTC
I think the fact that it doesn't work to move from processing to waiting via SIP2 is fully intentional. But documentation would be good, I agree. 

The idea here is that the email to inform about pick-up is not sent, until the item is handled at the circulation desk. Then the second check-in there fulfills the hold, triggers the email etc.
Comment 3 Alexander Wagner 2025-10-21 11:46:24 UTC
> The idea here is that the email to inform about pick-up is not sent, until the item is handled at the circulation desk.> Then the second check-in there fulfills the hold, triggers the email etc.

I understood that second check in. We have to get used to the ILS popping up modals all the time as the means to initiate some functions, though.

We currently use SIP as _the way_ to check in and out items. We hardly ever use any desk operations. Even if I have the patron at the desk to fetch her hold we walk over to the SIP terminal for the actual check out. (The patron barcode at the ready on the slip ;)

So, I was imagining that I could set `HoldsNeedProcessingSIP`, I fetch the item from the cart, place it on the SIP terminal right next to it and I then end up in the fulfill state to send notifications an print slips from the desk.

Koha does quite some magic here that we are used to do by explicit check _outs_ to a card. We e.g. SIP check out to "transport" or to "ready for pick up" depending on what we have. The barcode necessary for checkout gives the additional parameter we don't have at check in.

We'll adopt our procedures accordingly. It might be even advantageous as we check in every item from the cart again. (Quite a few of our patrons tend to place them in the cart _without_ returning them first.)


BTW: there is a similar behaviour, where Koha does not move on but sets a state is described in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37428