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

[Bug 43540] New: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43540 Bug ID: 43540 Summary: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When switching the OPAC interface language on a page reached via Koha's own /bib/<biblionumber> short URL (see the RewriteRule shipped in apache-shared-opac.conf / etc/koha-httpd.conf), the user is redirected to the OPAC homepage instead of staying on the record they were viewing. The same applies on the staff side for /bib/<biblionumber> against catalogue/detail.pl. Root cause: the /bib/ RewriteRule uses the [PT] flag, meaning it is an internal rewrite - the browser's address bar and Referer header keep showing /bib/<id>, never /cgi-bin/koha/opac-detail.pl. Koha::Util::Navigation::local_referer() (used by opac-changelanguage.pl and changelanguage.pl to work out where to send the user back to after a language switch) treats a referer as local only if it matches the site's OPACBaseURL/staffClientBaseURL AND contains the literal substring /cgi-bin/koha/. Since /bib/<id> never contains that substring, local_referer() falls through to its fallback (the site root), so the language switch drops the user on the homepage. This patch extends local_referer()'s recognized local-path pattern to also accept Koha's own /bib/<digits> short URL, in both the OPACBaseURL/staffClientBaseURL branch and the no-base-URL fallback branch. Test plan: 1. Enable mod_rewrite and confirm the /bib/<biblionumber> short URL works for an OPAC record (e.g. /bib/123 loads the same page as opac-detail.pl?biblionumber=123). 2. On that page, switch OPAC language using the language selector in the header or footer. 3. Before this patch: you are redirected to the OPAC homepage, losing the record. 4. After this patch: you are redirected back to /bib/123, now in the newly selected language. 5. prove t/Koha/Util/Navigation.t - all tests pass, including two new /bib/ short url cases. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 41825] New: Holds cannot be cancelled after a checkout on the patron checkout page
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41825 Bug ID: 41825 Summary: Holds cannot be cancelled after a checkout on the patron checkout page 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce: 1- Find two items, A and B, from two different bibliographic records. 2- Place a hold on item A for a patron. 3- Go to the patron Checkout page and check out item B. 4- Click on the Holds tab. 5- Click on the Delete icon to cancel the hold and confirm the cancellation. 6- Go back to the patron Checkout page and open the Holds tab. ---> The hold is not deleted. 7- Check out another item. 8- In the Holds tab, select the hold and click Cancel selected. ---> Nothing happens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43727] New: SIP no block checkouts and offline checkouts leave another patron's waiting hold in place
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43727 Bug ID: 43727 Summary: SIP no block checkouts and offline checkouts leave another patron's waiting hold in place Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal 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: --- When a SIP2 client sends a checkout with the no block flag set to Y, Koha has to accept it, so the checkout skips every check and goes through ProcessOfflineIssue. ProcessOfflineIssue calls AddIssue without a cancelreserve value, so a hold that is waiting, in transit, or in processing for a different patron is left alone. The item ends up checked out to one patron while it is still on another patron's holds waiting list. The hold sits there until it expires off the hold shelf, so the patron who placed it never gets the item. When staff check out an item with a waiting hold in the staff interface, Koha defaults to reverting the hold's waiting status. No block and offline checkouts should do the same, so the hold goes back to the top of the queue and is filled by the next copy. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 42860] New: UNIVERSAL::require is deprecated and should be replaced
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42860 Bug ID: 42860 Summary: UNIVERSAL::require is deprecated and should be replaced Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor 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: --- UNIVERSAL::require is used only for the SIP server and nowhere else. We should be able to replace it with Module::Load which is already used in Koha elsewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43498] New: UNIMARC: authority search returns no results when the authority type is only in 942$a
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43498 Bug ID: 43498 Summary: UNIMARC: authority search returns no results when the authority type is only in 942$a Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org Depends on: 41795 Target Milestone: --- Bug 41795 added the completeness attribute (@attr 6=3) to the authtype clause in C4::AuthoritiesMarc::SearchAuthorities. Complete-field matching resolves against Zebra's phrase ('p') register. The UNIMARC authority index definitions build the authtype index from two places: - 152$b -> authtype:w authtype:p - 942$a -> authtype:w (word register only) On UNIMARC installations whose authority records carry the authority type in 942$a only (no 152 coded data field -- common in real-world UNIMARC sites), the authtype phrase register is empty, so every type-filtered authority search returns zero results. In particular, the authority finder launched from the bibliographic editor (e.g. on field 600) always passes an authtypecode, so cataloguers cannot search or link authorities at all. We hit this on three independent production UNIMARC installations (different servers, different Koha and Zebra builds) immediately after upgrading to releases containing Bug 41795 (26.05.00 / 25.11.05). On all of them nearly all authority records have the type in 942$a and no 152$b. Reproduced on current main with KTD (unimarc flavour, Zebra 2.2.8): 1) Create an authority whose type is in 942$a only; full authorities reindex. 2) Authority search with a type filter -> 0 results; the same search without a type filter finds the record. 3) yaz-client against the authority socket confirms the mechanism: @attr 1=authtype @attr 5=100 @attr 6=3 <value> -> 0 hits @attr 1=authtype @attr 5=100 <value> -> 1 hit The Bug 41795 follow-up ("add a phrase Zebra index for 'authtype'") fixed exactly this for MARC21 after the Jenkins failures, but the UNIMARC definitions were not updated (their 152$b block already had a :p index, which masked the 942$a case). The patch (to be attached) applies the same one-line change to the UNIMARC definitions: add authtype:p to the 942$a block in authority-koha-indexdefs.xml, with the regenerated authority-zebra-indexdefs.xsl. A full authorities reindex is required after applying -- worth flagging prominently if this gets backported (cf. Bug 41795 comment 19). Elasticsearch is not affected. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 [Bug 41795] UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43723] New: Superlibrarian is bit 0 of borrowers.flag
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43723 Bug ID: 43723 Summary: Superlibrarian is bit 0 of borrowers.flag Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- And only this one. The test in C4::Context::IsSuperLibrarian is using % 2, so flags = 3 will be considered superlibrarian. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43443] New: Terminology: Issued should be "Checked out" in bookings
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43443 Bug ID: 43443 Summary: Terminology: Issued should be "Checked out" in bookings Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Found while translating: koha-tmpl/intranet-tmpl/prog/en/modules/bookings/list.tt: issued: () => _("Issued"), koha-tmpl/intranet-tmpl/prog/en/modules/bookings/list.tt: { status: _("Issued"), class: "bg-info" }, Confirmed on Mattermost that "Issued" here means "Checked out", so we should change it to that :) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43220] New: Patron name and card number should not be clickable in headings
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43220 Bug ID: 43220 Summary: Patron name and card number should not be clickable in headings Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 29768 Target Milestone: --- Since Bug 29768 the patron name and card number in the sidebar of patron pages is linked to the patron detail page. On the checkout page the patron name in the main heading is also clickable. This change happened in Bug 29768, "hidepatronname hides guarantor name on borrower edit screen." I think this was unintended and should be considered a bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 [Bug 29768] hidepatronname hides guarantor name on borrower edit screen -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 43799] New: cart_to_shelf cron waits an extra hour to update items
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43799 Bug ID: 43799 Summary: cart_to_shelf cron waits an extra hour to update items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Depends on: 43546 Target Milestone: --- The cart to shelf cron says: --hours | -h The number of hours that need to pass before the location is updated. But it's query is: SELECT itemnumber FROM items WHERE location = 'CART' AND TIMESTAMPDIFF(HOUR, items.timestamp, NOW() ) > ? TIMESTAMPDIFF returns the number of full hours between two times. This means that if I give the cron a parameter of 1, my item will not update until it's been 2 full hours since the item was returned. Assume the item was returned at 8:00 and I've given the cron a parameter of --hours 1 At 8:59, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 0 At 9:00, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 1 At 9:59, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 1 at 10:00, TIMESTAMPDIFF(HOUR, items.timestamp, NOW()) = 2 -- it's finally greater than 1 and my item updates Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43740] New: Notice module "Patrons (custom slip)" is sometimes "Patron (custom slip)"
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43740 Bug ID: 43740 Summary: Notice module "Patrons (custom slip)" is sometimes "Patron (custom slip)" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- The notice module "Patrons (custom slip)" reads "Patron (custom slip)" in the notice creation/edit screen. To recreate: 1 - go to Tools, Notices and Slips 2 - click New notice 3 - select "Patrons (custom slip)" 4 - in the notice creation screen, see the module reads "Patron (custom slip)" 5 - save your notice 6 - in the list of existing notices, see your notice shows "Patrons (custom slip)" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6