| Summary: | Improve the AllowItemsOnHoldCheckoutSIP system preference description | ||
|---|---|---|---|
| Product: | Koha | Reporter: | David Nind <david> |
| Component: | SIP2 | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | alexander.wagner |
| Version: | Main | Keywords: | Academy |
| Hardware: | All | ||
| OS: | All | ||
| 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: | |||
|
Description
David Nind
2024-07-22 21:57:37 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. |