Bug 37428 - Improve the AllowItemsOnHoldCheckoutSIP system preference description
Summary: Improve the AllowItemsOnHoldCheckoutSIP system preference description
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (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-07-22 21:57 UTC by David Nind
Modified: 2025-10-20 15:14 UTC (History)
1 user (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 David Nind 2024-07-22 21:57:37 UTC
The AllowItemsOnHoldCheckoutSIP system preference description is confusing and could be updated to make it clearer and easier to understand.

Current description:
[Don't allow/Allow] checkouts of items reserved to someone else via SIP checkout messages. If allowed do not generate RESERVED warning. This allows self checkouts for those items. If using the holds queue items with pending holds will be marked as "unavailable" if this set to "Don't allow".

Discussed on chat: 
- General discussion: https://chat.koha-community.org/koha-community/pl/81zs86ckd7rypp94qnt7s9cu9e
- Explanation: https://chat.koha-community.org/koha-community/pl/yjrkugm99bgxdxy7h4snk6qyee
Comment 1 Alexander Wagner 2025-10-20 15:14:02 UTC
I am actually unsure if it is only the description that is confusing and not even the actual behaviour of Koha.

This seems to be:

1. Item on hold for patron A => the item is `RESERVED`
2. Patron B checks out -> `AllowItemsOnHoldCheckoutSIP` tiggers properly
3. Patron B returns the item
4. The item is promoted to `RESERVE_WAITING`
5. Patron C comes along and checks it out => ERROR regardless of `AllowItemsOnHoldCheckoutSIP`

IOW if a hold is placed before the first (non-intended) checkout at 2. the option works as expected. At 4. however, it fails as the items hold gets an unwanted(?), automatic status promotion.

At point 3 we should get hold of the item as it ends up in the cart, however.

Sidenote: in our (small) library we do not use any loan on desk, so any notifications on the intranet interface never show up. Even if a patron comes to the desk to fetch an item reserved for her we go to the SIP machine for the actual check out.