- Koha-bugs - lists.koha-community.org

[Bug 42988] New: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior.
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42988 Bug ID: 42988 Summary: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The migration from the SIP config file to the database leaves holds_get_captured NULL which makes the behavior default to on, but in the sip account editor, the off option is selected so when you save the profile edit, the behavior is changed! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42790] New: Bookings tab: action improvements
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42790 Bug ID: 42790 Summary: Bookings tab: action improvements Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This patchset improves the patron and biblio bookings tabs by unifying the available actions across both displays, syncing due dates with booking end dates at issue time, and introducing a booking-aware Extend action for issued bookings. Depends on: Bug 41898 (Booking status lifecycle: rename and extend) === 2.1 Unified action set across Patron and Biblio bookings displays === Both the Patron bookings tab and the Biblio bookings page show the same actions, gated on booking status and the logged-in user's permissions: Status | Edit | Cancel | Checkout | Extend new | manage_bookings | manage_bookings | circulate | â issued | â | â | â | circulate completed | â | â | â | â cancelled | â | â | â | â The Patron bookings tab currently shows only Cancel; it gains Edit and Checkout. The Biblio bookings page currently shows Edit, Cancel, and "Transform to checkout"; "Transform to checkout" is renamed Checkout and shortcuts to the checkout screen pre-populated with the patron and item. === 2.2 Due date sync at AddIssue === When a booked item is checked out, AddIssue uses booking.end_date as the default due date. If staff override the due date at checkout time, the override is synced back to booking.end_date server-side, keeping the booking and the checkout in sync from the moment of issue. === 2.3 Booking-aware extension for issued bookings === An Extend button appears in the Actions column for issued bookings. It opens a modal containing: - The current booking end_date - The current checkout date_due from the embedded issue record - A date picker that visually blocks dates where another new or issued booking exists for the same item - A Confirm button On confirm, a single API call handles all updates server-side: 1. Validates the new date against the maximum booking period 2. Checks for conflicting bookings for the same item 3. Updates date_due on the linked checkout 4. Updates end_date on the booking The Extend button is only visible to users with circulate permission. === 2.4 Checkout link and due date display for issued bookings === For rows with status = issued, the Item column additionally shows the checkout due date and a link to the checkout record. Staff can see at a glance when the loan is due back and navigate to it without leaving the bookings tab. === 2.5 Visual row indicators for uncollected past-window bookings === new bookings where start_date < today receive a table-info row class to highlight that the booking is awaiting collection. new bookings where end_date < today receive a table-warning row class to highlight that the collection window has passed. === Test plan === 1. Apply Bug 41898 patches first. 2. Create a booking for a patron on a specific item. 3. Confirm the Patron bookings tab shows Edit, Cancel, and Checkout actions for the new booking; Biblio bookings page shows the same. 4. Click Checkout â confirm it pre-populates the checkout screen with the patron and item; confirm the due date defaults to the booking end_date. 5. Override the due date at checkout; confirm booking.end_date is updated to match. 6. Confirm the issued booking shows the due date and a checkout link in the Item column on both tabs. 7. Click Extend on the issued booking; select a new date; confirm both date_due and booking.end_date are updated. 8. Create a subsequent booking for the same item and confirm its start_date is blocked in the Extend date picker. 9. Advance the clock past a new booking's start_date; confirm the row receives the table-info highlight. 10. Advance past end_date; confirm the row receives the table-warning highlight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42998] New: Allow a requested due date when renewing a checkout via the REST API
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42998 Bug ID: 42998 Summary: Allow a requested due date when renewing a checkout via the REST API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- Depends on bug 42997 (booking/checkout due date synchronisation). This patch extends the checkout renewal endpoints so API consumers can renew a checkout through to a specific date: - an optional request body may carry a due_date (RFC3339); it is used in place of the due date calculated from the circulation rules and is validated against any bookings for the item via CanBookBeRenewed. When the checkout is linked to a booking, AddRenewal keeps the booking end date in sync (bug 42997) - a new renewal_limit value is accepted in the x-koha-override header, skipping renewal count limits when AllowRenewalLimitOverride is enabled - intended for staff explicitly authorising an extension of a booked loan - the 403 error response now carries the CanBookBeRenewed error as a machine-readable error_code (e.g. 'booked', 'too_many') The requested due date is a body attribute rather than a query parameter or override: the POST creates a renewal resource and the date is data about that renewal. The existing 'seen' query parameter predates the current guidelines and has been left untouched. Both /checkouts/{checkout_id}/renewal and the newer /checkouts/{checkout_id}/renewals route to the same controller, so the body is accepted and documented on both. Test plan: 1. yarn api:bundle && restart_all 2. Run t/db_dependent/api/v1/checkouts.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42997] New: Keep booking end dates in sync with checkout due dates at issue and renewal
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Bug ID: 42997 Summary: Keep booking end dates in sync with checkout due dates at issue and renewal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Depends on bug 41898 (booking status lifecycle). With the 'issued' booking status in place, the booking and its linked checkout can drift apart whenever the due date differs from the booking end date - at issue time (staff due date overrides) and at renewal. This patchset makes the checkout due date authoritative and keeps the booking in step with it: - AddIssue syncs any due date override back to booking.end_date the moment the booking transitions to 'issued'; if the override would clash with a subsequent booking the checkout proceeds with the booking's original end date - CanBookBeIssued raises a new BOOKED_DUE_DATE_CLASH confirmation on the checkout screen when an explicitly requested due date runs into the next booking for the item, so staff are warned before continuing - circulation.pl now honours an explicit due date override for booked items instead of silently clamping it to the booking end date - CanBookBeRenewed no longer allows a renewal to run straight through the start of the next booking: the patron's own booking previously hid subsequent bookings from the clash lookup. Requested due dates (checkouts screen renewal date, circ/renew.pl hard due date) are now validated against bookings too - AddRenewal pulls the linked booking's end_date along with the renewed due date, mirroring the AddIssue behaviour Test plan: 1. Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2. Create two consecutive bookings on one item for two patrons; check the item out to the first patron with a due date beyond the second booking's start; confirm the warning appears and, on confirming, the checkout uses the requested date whilst the booking keeps its original end date 3. Check out a booked item with a non-clashing due date override and confirm the booking end date follows it 4. Renew a booked checkout and confirm the booking end date follows the new due date; attempt to renew past the next booking's start and confirm the renewal is refused -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42974] New: Acquisitions receiving is not limited by basket owning library
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42974 Bug ID: 42974 Summary: Acquisitions receiving is not limited by basket owning library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lena.hernandez(a)equinoxoli.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In acquisitions, when receiving order lines and adding them to the invoice, all pending items display, even those from other libraries. It is possible to update and receive items owned by other libraries on baskets managed by other libraries. I would expect that an account with the permissions order_manage and edit_items, but without the permissions order_manage_all or edit_any_item would not be able to receive or modify them. Indeed, the file basket.pl wants order_manage and then farther down it looks like it checks if you own the basket or have the order_manage_all perm, and if not throws the cannot_manage_basket, "You are not authorised to manage this basket." However, it appears that the parcel.pl file for receiving invoices only cares about the order_receive permission and doesn't check any other permissions. This stage of the process should follow other acq permissions and restrict receiving to managing libraries. Bug is applicable for at least versions 24.11 through 26.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 8292] clicking ignore on hold cancels transfer
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8292 Anni Mäki-Mantila <anni.maki-mantila(a)turku.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anni.maki-mantila(a)turku.fi --- Comment #21 from Anni Mäki-Mantila <anni.maki-mantila(a)turku.fi> --- (In reply to Owen Leonard from comment #16) > I think this is still worth fixing. It makes sense to me that if you check > in an item from another library and ignore the hold that it should behave as > if you'd checked in an item from another library without a hold. > > Maybe with a different button text, "Ignore hold and transfer to <library>" ? This sounds worth considering. In addition there should probably be a button with an option to ignore hold, transfer item ja print receipt. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42957] New: On additem.pl clicking on field columns no longer allow Edit/delete
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42957 Bug ID: 42957 Summary: On additem.pl clicking on field columns no longer allow Edit/delete Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: janet.mcgowan(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Created attachment 201352 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201352&action=e… inline column options on Manage items page Clicking ‘Edit’ and ‘Manage items’ from the bibliographic record. In the list of items (at 24.11) it used to be possible to click on a column cell - such as collection code and be presented with Edit item, Delete item options inline. See attachment. This is no longer the case at 25.11 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41898] New: Expired bookings do not display when expired filter is used in patron record
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41898 Bug ID: 41898 Summary: Expired bookings do not display when expired filter is used in patron record Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 193520 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193520&action=e… Show expired button does not display expired bookings The 'Show expired' button in the Bookings tab of the patron record does not show expired bookings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 21996] SPAM
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21996 Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42999 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38412] New: Koha should warn when hold on bibliographic record requires hold policy override
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38412 Bug ID: 38412 Summary: Koha should warn when hold on bibliographic record requires hold policy override Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 35573 When AllowHoldPolicyOverride is set to Allow, Koha will specifically mark items for which an item-level hold will require an override. However, nothing in the interface indicates when the bibliographic level hold will require an override. To recreate: - Have AllowHoldPolicyOverride set to Don't Allow - Have a bib record with just one item - confirm you can place a hold on either the biblio or the item - edit your item such that it become unholdable (mark it Not For Loan or something) - confirm that you cannot place a hold on either the biblio or the item - set AllowHoldPolicyOverride to Allow - confirm that Koha shows an alert on the item indicating that the hold will require an override - confirm that Koha does not indicate the bibliographic level hold will require an override Bug 33573 restored these alerts for items. I don't recall if we've ever had these alerts for biblios. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35573 [Bug 35573] Koha is not correctly warning of overridden items when placing a hold if AllowHoldPolicyOverride -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32