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

[Bug 42222] New: Use of uninitialized string in string eq in Auth.pm
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42222 Bug ID: 42222 Summary: Use of uninitialized string in string eq in Auth.pm Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org I noticed in the error logs "Use of uninitialized value in string eq at /kohadevbox/koha/C4/Auth.pm line 198". This occurs when you're 1) already authenticated and 2) doing any POST request, on both the public and staff sides. It's because `$in->{query}->param('login_op')` is undef when the user isn't logging in. Patch coming shortly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42521] New: Cannot login from suggestion.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42521 Bug ID: 42521 Summary: Cannot login from suggestion.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 39055 DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'login_op' in 'WHERE' at /kohadevbox/koha/Koha/Objects.pm line 401 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39055 [Bug 39055] Unauthenticated are not redirected properly in reports module after login -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 39336] New: Public Biblio endpoint should honour OpacSuppression syspref
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39336 Bug ID: 39336 Summary: Public Biblio endpoint should honour OpacSuppression syspref Change sponsored?: --- Product: Koha Version: unspecified 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com At the moment, if a record is suppressed in Koha it will still be accessible using the public get biblio endpoint... as the 'public' endpoint is in effect the opac equivalent of the API, then I believe these should not allow return of the record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 36942] New: Throw an exception if a KBART file can't be read
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36942 Bug ID: 36942 Summary: Throw an exception if a KBART file can't be read Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: matt.blenkinsop(a)ptfs-europe.com CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Currently we warn an error message if there is an error parsing a KBART file. We should change this to use an exception -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 38912] New: Elasticsearch record show is a 404 from staff catalog details
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '26

23 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38912 Bug ID: 38912 Summary: Elasticsearch record show is a 404 from staff catalog details Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 176694 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176694&action=e… screenshot of 404 To recreate: - Use Elasticsearch as search engine (SearchEngine = Elasticsearch) - Go to a record on the staff side /cgi-bin/koha/catalogue/detail.pl?biblionumber=1234 - Click the "show" link next to "Elasticsearch record:" - a 404 page appears in a pop-up window (see attached screenshot) The page is also a 404 if I inspect the link and open it in a new tab. The URL looks like /cgi-bin/koha/catalogue/showelastic.pl?id=1234 We are on 24.05.05. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 38833] New: Log merge of bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38833 Bug ID: 38833 Summary: Log merge of bibliographic records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When merging bibliographic records, the action logs should show specifically that a merge was performed. Currently, the cataloging log records modifications and deletions of the bibliographic and item records involved and that should all be kept. But we should also log a "merge" action for each bibliographic record involved in the merge. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 38550] New: Add dark mode option to the staff interface
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38550 Bug ID: 38550 Summary: Add dark mode option to the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: christian.stelzenmueller(a)bsz-bw.de, gmcharlt(a)gmail.com, me(a)paulderscheid.xyz It would be great if we could have a dark mode for the staff interface. While in the OPAC we can assume that libraries have done heavy customizations to the color scheme, this might be easier, assuming that most libraries stick to our standard design/color scheme. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75

[Bug 39495] New: [OMNIBUS] Staff Interface Theming
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39495 Bug ID: 39495 Summary: [OMNIBUS] Staff Interface Theming Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is an omnibus for theming options for the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 36028] New: When AutoLocation is on there is no error message when the user is at the wrong branch
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36028 Bug ID: 36028 Summary: When AutoLocation is on there is no error message when the user is at the wrong branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org When AutoLocation is on the user is supposed to be restricted to logging in at their branch. If the user is at a different branch and logs in, they get past the login page, but any action returns them to the login page. They should be returned directly to the login page with an error message. Test plan: 1. select a branch with branchip set to match the ip you are testing from. 2. select a user at a different branch. 3. login. 4. observe that there is no error, and login appears to succeed, but doesn't actually. 5. apply patch and restart services. 6. login again. 7. observe that the login page comes back immediately with an error message about AutoLocation being on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42608] New: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Bug ID: 42608 Summary: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode is set to Dayweek, the pickup expiration date set for a hold by Koha::Hold::set_waiting is inflated by a whole week whenever the pickup window crosses a single (one-off) closure on a normally-open weekday -- for example a Bank Holiday Monday. Steps to reproduce ================== System preferences: ReservesMaxPickUpDelay = 6 ExcludeHolidaysFromMaxPickUpDelay = ON ExpireReservesOnHolidays = ON useDaysMode = Dayweek Branch calendar: - Sundays marked as a weekly closed day. - A single (one-off) holiday on a Monday two weeks out -- for example 2026-05-04 (the early May Bank Holiday). Trap a hold to waiting at that branch on Tuesday 2026-04-28. Actual result ============= expirationdate is set to 2026-05-12 -- a 14-day pickup window. Expected result =============== expirationdate should be 2026-05-06 -- a 6-open-day pickup window. The intent of ExcludeHolidaysFromMaxPickUpDelay is to give the patron the full ReservesMaxPickUpDelay count of *open* days to come and collect the item, by extending the window by one calendar day for every closed day that falls inside it. useDaysMode (Dayweek / Datedue / Calendar / Days) is a loan-due-date concept -- the patron picks no weekday for a hold pickup; staff trap the item, and the only thing that should influence the expiration date is how many open days the patron should get to collect. Wider example table =================== Same configuration as above. Sunday 3 May and Monday 4 May 2026 are closed at the branch. Comparison of current (buggy) vs expected expiration dates for each weekday a hold could be trapped that week: Hold trapped on Current (buggy) Expected ----------------- ----------------- ----------------- Mon 27 Apr 2026 Mon 11 May 2026 Tue 5 May 2026 Tue 28 Apr 2026 Tue 12 May 2026 Wed 6 May 2026 Wed 29 Apr 2026 Wed 13 May 2026 Thu 7 May 2026 Thu 30 Apr 2026 Thu 14 May 2026 Fri 8 May 2026 Fri 1 May 2026 Fri 15 May 2026 Sat 9 May 2026 In each case the expected expiration is `waitingdate + ReservesMaxPickUpDelay` open days, with Sun 3 May and Mon 4 May skipped (not counted toward the 6-day window). The current buggy expirations are all 14 calendar days from the trap date -- a whole extra week. Reproduction snippet ==================== use Koha::Calendar; use Koha::DateUtils qw(dt_from_string); # Test branch: Sundays weekly closed, single holiday 2026-05-04. my $cal = Koha::Calendar->new( branchcode => 'BR', days_mode => 'Dayweek', ); # Bug: prints 2026-05-12 (14 days). # Expected: 2026-05-06 (6 open days). say $cal->days_forward( dt_from_string('2026-04-28'), 6 )->ymd; Notes ===== Loan due dates calculated by Koha::Calendar::addDays under useDaysMode=Dayweek behave correctly -- the bug only surfaces on hold pickup expiration dates. A fix should not regress the loan due-date behaviour, which is the original purpose of the Dayweek mode (keeping a Friday-due loan due on a Friday over closures). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7