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

[Bug 40575] New: Transferring order will reload the page and its form
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40575 Bug ID: 40575 Summary: Transferring order will reload the page and its form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Test plan: 1 - Create two baskets: "Source Basket" and "Dest Basket" 2 - Add one command line to "Source Basket" 3 - Close the basket 4 - Receive shipment 5 - Receive order 6 - Cancel the order receive 7 - Transfer the order to the Dest Basket -> When clicking on chose, you will be asked if you want to send again infos (which were sent to cancel the order receive), and if accepting, you will be printed an error. 8 - Apply patch 9 - Repeat the process with another source Basket and notice the page is simply reloaded without sending form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42720] New: Add REST API equivalents for svc/report and opac/svc/report
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42720 Bug ID: 42720 Summary: Add REST API equivalents for svc/report and opac/svc/report 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have equivalent functionality as svc/report in the REST API. Perhaps some time in the future we could deprecate the old version. Having a REST equivalent would come with better better authentication, documentation, http responses ( somewhat fixed by bug 42596 ) and other things. It could have pagination for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42646] New: ModSuggestion: SMS status-change notices always contain email template content
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42646 Bug ID: 42646 Summary: ModSuggestion: SMS status-change notices always contain email template content 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org In C4/Suggestions.pm, ModSuggestion() selects the transport type (email or sms) at ~line 253 and stores it in $transport, but then calls GetPreparedLetter() at ~line 256 without passing message_transport_type. GetPreparedLetter() defaults message_transport_type to 'email' when the parameter is absent (C4/Letters.pm ~line 585), so it always fetches the email template variant of the notice â even when $transport was resolved to 'sms'. The result is that any patron who legitimately receives an ACCEPTED/AVAILABLE/REJECTED/ORDERED/CHECKED notice via SMS receives the email-formatted body text rather than the SMS-specific template content. Related to: Bug 39984, Bug 42645 Test plan: 1. Configure SMSSendDriver and a patron with smsalertnumber but no email. 2. Enable FallbackToSMSIfNoEmail. 3. Create SMS-specific templates for the ACCEPTED notice code (Notices > ACCEPTED > SMS tab). 4. Submit a suggestion as that patron and accept it. 5. Check the message_queue table: the content column will contain the email template body, not the SMS template body. 6. Apply patch (add message_transport_type => $transport to the GetPreparedLetter() call in ModSuggestion). 7. Repeat: the content column now contains the SMS template body. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 42809] New: Notification falls to print back when two messaging preferences are set but only one is valid.
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Bug ID: 42809 Summary: Notification falls to print back when two messaging preferences are set but only one is valid. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960#c18 This [Bug 40960] causes problem for patrons with their messaging preferences set to receive both sms and mail and one of the transport types fails. For example when the patron does not have a mail registered but both message types are checked on their account they will receive both sms and printed notices. When using standard/pre-filled messaging preferences based on patron category this can create a large number of unwanted print notices. When a notice is sent with sms OR mail you don't want to create a print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 21266] New: Missing doc-head-close and cssinclude in sco-main.tt
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21266 Bug ID: 21266 Summary: Missing doc-head-close and cssinclude in sco-main.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Custom stylesheet themes set in the OpacAdditionalStylesheet are not applied to the sco-main.tt page because this page is missing the following lines of code in the header: doc-head-close cssinclude -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 42218] New: ERM Usage – remove Database table erm_usage_yus ?
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42218 Bug ID: 42218 Summary: ERM Usage – remove Database table erm_usage_yus ? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk The erm_usage_yus table could be removed completely, as it contains redundant information which already exists in the erm_usage_mus -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 21217] New: No error when doing Renewals for expired borrowers
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21217 Bug ID: 21217 Summary: No error when doing Renewals for expired borrowers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)phe.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have had a couple of instances when books were being renewed in the staff client where the renewal was failing but there was no error message. It turned out in both cases that the user accounts had expired. Is it possible for an alert to show in the staff client when trying to renew an items for an expired borrower? The alert shows if trying to check out items to an expired borrower but this does not appear from the renewals screen. I have had a look in the system preferences but can't see anything obvious. Thanks, Jeremy -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 33260] New: Show message queue on staff interface and make notices printable
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33260 Bug ID: 33260 Summary: Show message queue on staff interface and make notices printable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Some Koha libraries need to get messages out to borrowers who do not have email addresses, so they need to be able to view generated notices, and optionally print them so they can be delivered offline. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 799

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

30 Oct '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 22