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

[Bug 43785] New: 2FA code fields should use autocomplete="one-time-code" so password managers can fill the TOTP code
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43785 Bug ID: 43785 Summary: 2FA code fields should use autocomplete="one-time-code" so password managers can fill the TOTP code Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: mr.dugi(a)gmail.com QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Target Milestone: --- The staff interface 2FA login field (otp_token in koha-tmpl/intranet-tmpl/prog/en/modules/auth.tt) is a plain <input type="text"> inside a form with autocomplete="off" (added by Bug 33253). Password managers that store TOTP secrets (Apple Passwords on iOS/macOS, 1Password, Bitwarden...) only offer to fill a verification code when the field is marked autocomplete="one-time-code". As a result, staff who keep their Koha TOTP in such a manager have to switch apps and copy the code by hand, and on phones the field opens the full text keyboard instead of a numeric one. Bug 33253's concern still holds with this change: browsers do not store one-time-code values in form history, so it does not bring back suggestions of previous codes. The same applies to the PIN field on the 2FA setup page (pin_code in includes/auth-two-factor.inc, used by auth.tt when 2FA is enforced and by members/two_factor_auth.tt). To reproduce: 1. Set TwoFactorAuthentication to "Enabled" or "Enforced". 2. Enrol a staff account, saving the TOTP secret in Apple Passwords (or another manager that supports verification codes). 3. Log out, then log in to the staff interface with username and password in Safari on iOS or macOS. 4. On the "Two-factor authentication code" step, focus the field. Expected: the browser offers the current code from the password manager; on mobile a numeric keypad opens. Actual: no code is offered and the full text keyboard opens; the code has to be copied manually. Proposed fix: - auth.tt: add autocomplete="one-time-code" inputmode="numeric" autocapitalize="off" to the otp_token input (an element-level value overrides the form's autocomplete="off"; optionally drop autocomplete="off" from that form). - includes/auth-two-factor.inc: add the same attributes to the pin_code input. - Optionally pattern="[0-9]*". Test plan: 1. Apply the patch. 2. Enrol a staff account with Apple Passwords or 1Password; log out and log in again. 3. Confirm the code is offered and fills in, and login succeeds. 4. Confirm previous codes are not suggested from form history (Bug 33253 behaviour unchanged). Related: Bug 33253 (2FA form excluded from autofill), Bug 29487 (autocomplete off on login fields). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 40186] New: Show additional fields in search form on acquisition start page
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40186 Bug ID: 40186 Summary: Show additional fields in search form on acquisition start page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu At the moment the search form on the acquisition start page and on the Advanced search page are slightly different: the first is missing the additional fields. It would be nice if the additional fields showed on both search forms or if that was configurable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43088] New: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43088 Bug ID: 43088 Summary: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43078 Target Milestone: --- Koha::File::Transport has no consistent, side-effect-free way to query a transport's current remote working directory. Bug 43078 unified list_files() across FTP/Local/SFTP, but left this gap: Net::SFTP::Foreign's cwd() is a pure read-only accessor, but Net::FTP's own cwd() is a mutator - called with no argument it defaults to "/" and issues a real CWD command, changing the connection's directory as a side effect and returning a boolean rather than a path. This surfaced in the koha-plugin-transport-browser plugin, which read $transport->{connection}->cwd directly to capture the initial working directory for its root/breadcrumb navigation. That happened to work for SFTP, but for FTP it silently reset the connection to the server's root directory and captured "1" (a boolean) as the "path", breaking directory navigation for FTP transports - clicking into a subdirectory just reloaded the same listing instead of navigating in. Depends on bug 43078. Test plan: 1. Apply the attached patch on top of bug 43078. 2. prove t/db_dependent/Koha/File/Transport.t t/db_dependent/Koha/File/Transport/FTP.t t/db_dependent/Koha/File/Transport/Local.t t/db_dependent/Koha/File/Transport/SFTP.t 3. koha-qa.pl -v 2 --more-tests reports [PASS] for all changed files with no critic/pod warnings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43078 [Bug 43078] File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 28740] New: Delete old ILL requests with cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 Bug ID: 28740 Summary: Delete old ILL requests with cleanup_database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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: robin(a)catalyst.net.nz, tomascohen(a)gmail.com We should teach cleanup_database to delete old ILL requests after a given period. Over in bug 23391, we introduced a syspref in which one can define statuses for which to hide ILL requests. Following that same idea of allowing whatever statuses a given back-end may use, the cron should take a number of days and a status and delete any request with that status that is more than that many days old. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42881] New: Improve Elasticsearch Indexing performance
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42881 Bug ID: 42881 Summary: Improve Elasticsearch Indexing performance Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- An epic bug to collect elasticsearch (re)indexing performance improvements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 43858] New: Checking in a bundle from patron account does not ask to confirm contents
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43858 Bug ID: 43858 Summary: Checking in a bundle from patron account does not ask to confirm contents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1. From the Bibliographic record, mark the bib record for bundling by setting the leader position 7 to c. This will be HOST_ITEM 2. Click manage bundle and add two other items, from separate records, to the bundle. CHIILD_ITEM1 and CHILD_ITEM2 3. Now check out the bundle 4. Check it in normally, you'll see a modal asking you to confirm the contents on the bundle 5. Check the bundle out again. 6. From the patron's issue table find the row for the bundle and select check in. 7. Below the table click "Check in selected items", you are not asked to confirm the contents of the bundle. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43857] New: Inaccurate usage example in holds_reminder.pl
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43857 Bug ID: 43857 Summary: Inaccurate usage example in holds_reminder.pl 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 Target Milestone: --- The first usage example in holds_reminder.pl claims that running the cron with no arguments will return the help. This is not true. As the second usage example tells us, running the script with no arguments is the most basic usage and processes hold reminders for all libraries and all waiting holds. We should remove the first example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42334] New: Introduce Koha::Calendar::DateCalculator for date arithmetic
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42334 Bug ID: 42334 Summary: Introduce Koha::Calendar::DateCalculator for date arithmetic Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::Calendar currently mixes two concerns: calendar data (which days are closed) and date arithmetic (calculating due dates, counting open days, finding next open day). The arithmetic methods all depend on a days_mode parameter that gets passed into the Calendar constructor even though it has nothing to do with the calendar itself, it's a circulation policy. The goal is to extract the date arithmetic methods into a new Koha::Calendar::DateCalculator class that takes a calendar and a days_mode as constructor parameters: ``` my $calc = Koha::Calendar::DateCalculator->new( calendar => $library->calendar, days_mode => C4::Context->preference('useDaysMode'), ); my $due_date = $calc->add_duration( $start, $dur, 'days' ); ``` Methods to move: addDuration, addHours, addDays, get_push_amt, next_open_days, prev_open_days, days_forward, days_between, hours_between, has_business_days_between. This separates the calendar (what's closed) from the policy (how to handle closed days when calculating dates), and removes the days_mode parameter from Koha::Calendar->new where it never belonged. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 43708] New: Update subscription add page to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43708 Bug ID: 43708 Summary: Update subscription add page to use grid layout for forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 39780 Target Milestone: --- - serials/subscription-add.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 43484] New: Messaging preferences in OPAC differ to the actual settings in the staff interface.
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43484 Bug ID: 43484 Summary: Messaging preferences in OPAC differ to the actual settings in the staff interface. Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: janet.mcgowan(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Messaging preferences in the OPAC do not match what is selected in the user account on the staff interface. To test: -set up a user on the staff interface with all messaging preferences selected for email and digests. - message_transport_type is correctly set to Email in the database. - Log in as that user on the OPAC and in the user account go to Messaging. - In opac-messaging.pl the Email column tick boxes are empty and all the Print boxes are ticked. -- You are receiving this mail because: You are watching all bug changes.

1 5