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

[Bug 43805] New: Logging back in after a session timeout 404s on Vue pages served through a RewriteRule (record_sources, circulation_triggers)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43805 Bug ID: 43805 Summary: Logging back in after a session timeout 404s on Vue pages served through a RewriteRule (record_sources, circulation_triggers) 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 Target Milestone: --- Staff interface pages that are served through a RewriteRule of the form RewriteRule ^/cgi-bin/koha/admin/record_sources(.*)?$ /cgi-bin/koha/admin/record_sources.pl$1 [PT] (etc/koha-httpd.conf and debian/templates/apache-shared-intranet.conf; the same shape is used for admin/circulation_triggers) cannot be logged back in to after the session times out. The pattern also matches the script's own name, so a request for record_sources.pl is rewritten to record_sources.pl.pl and returns 404. When the login form is shown on such a page, its action is the script name (/cgi-bin/koha/admin/record_sources.pl). Submitting it therefore 404s, no session is created, and the user is stuck on an error page until they log in through another page (for example mainpage.pl) and navigate back. To reproduce (main, 26.06.00.035, in KTD): 1. Log out (or let the session expire). 2. Open /cgi-bin/koha/admin/record_sources. The login page is shown; its form action is /cgi-bin/koha/admin/record_sources.pl. 3. Enter valid credentials and submit. Expected: you are logged in and see the record sources page. Actual: "Error 404 > Koha". No session is created. Evidence with curl (cookie jar, valid csrf_token taken from the login page): - POST to the form action /cgi-bin/koha/admin/record_sources.pl -> 404 - POST of the same fields to /cgi-bin/koha/admin/record_sources -> 200 GET /cgi-bin/koha/admin/record_sources.pl and /cgi-bin/koha/admin/circulation_triggers.pl also return 404. Not affected: acquisition/vendors, whose rule maps acquisition/vendors to acqui/vendors.pl, so acqui/vendors.pl is reachable (200). Found while building a new Vue page under Cataloguing (bug 30800), which copies the same rule and so has the same problem. Possible directions (not verified): - Guard the rules so the script's own name is not rewritten, as is already done for preservation in the same file: RewriteCond %{REQUEST_URI} !^/cgi-bin/koha/preservation/.*.pl$ A similar RewriteCond for each of these pages would let the .pl URL reach the script. The Vue router base paths are the extensionless URLs, so it needs checking what the app does when it is loaded on the .pl URL after login. - Or have the login form post back to the URL the user actually requested instead of the script name when the request was rewritten. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 41809] New: Waiting holds fulfilled by another copy should be marked for return to stacks
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Bug ID: 41809 Summary: Waiting holds fulfilled by another copy should be marked for return to stacks Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This may be related to bug 38650 The use case we have run into is: A patron has a hold waiting on the hold shelf. They check out a different copy on the same bib from the stacks and this copy fulfills the hold. The waiting hold does not appear on the holds with cancellations or holds waiting over X days reports. This causes confusion for our branch staff and items sitting on the hold shelf longer than they should be. Ideally these would move to the holds with cancellation requests report, but I'd be interested if others feel differently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 36063] New: Add Holds to Pull info to intranet-main page
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36063 Bug ID: 36063 Summary: Add Holds to Pull info to intranet-main page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 We often use JS to add a display to the intranet-main page when there are holds to pull. It would be nice to just add that into Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 41608] New: Ability to select multiple values of a facet in the professional interface
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41608 Bug ID: 41608 Summary: Ability to select multiple values of a facet in the professional interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In the professional interface, we should be able to select several values from a facet in a single operation (e.g., several libraries, several languages, etc.), so that Koha applies the "OR" operator between each value (e.g., return documents present in library A or library B) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 93

[Bug 43370] New: Holdings table displays a user-selected column on the pages where it is empty
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 Bug ID: 43370 Summary: Holdings table displays a user-selected column on the pages where it is empty Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- On the holdings table of the catalogue detail page, a column that has no value on the current page is hidden. update_columns_visibility() applies the user's column visibility choices after that pass, so a column the user turned on is displayed, empty, on the pages where it has no value. To reproduce: 1. Have a record with more than 20 items, e.g. biblionumber=4: kj build 42 items with biblionumber=4 2. Give a call number to the items of the first page only. UPDATE items SET itemcallnumber = NULL WHERE biblionumber = 4; UPDATE items SET itemcallnumber = CONCAT('CN-', itemnumber) WHERE biblionumber = 4 ORDER BY itemnumber LIMIT 20; 3. Go to /cgi-bin/koha/catalogue/detail.pl?biblionumber=4 4. In the column visibility menu, turn "Call number" off then on again. => The column is displayed on the first page, as expected. 5. Go to page 2. => The "Call number" column is displayed and empty for all rows. It should be hidden. 6. Go back to page 1. => The column is displayed again (correct). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[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 14 Oct '26

14 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 4

[Bug 43654] New: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 Bug ID: 43654 Summary: Item search: DataTables column filters ignored when 2+ conditions are combined (follow-up to Bug 36930) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 36930 fixed item search returning wrong results when 2+ added conditions were combined, by making the filter constructor in catalogue/itemsearch.pl detect whether parameters arrived as 'f[]' (bracket notation, sent by JS when there are 2+ conditions) or plain 'f' (single condition), and read/write consistently. However, the JSON-preprocessing block that merges DataTables column filters (free-text search box and dropdowns for library, item type, etc. in the results table) still unconditionally reads from multi_param('f') without brackets. With 2+ conditions, that call returns empty (JS sent 'f[]'), so the column filters get pushed onto an empty array and written back to the plain 'f' param — which the filter constructor further down (fixed by Bug 36930) never reads, since it's looking at 'f[]'. The column filters are silently ignored and the results table gets stuck on "Processing". Steps to reproduce: 1. Go to Cataloging > Item search. 2. Add 2 search conditions (e.g. Library = X AND Item type = Y). 3. Run the search, then try to filter further using one of the result table's column filters (e.g. type a value in a free-text column filter, or pick a value from a dropdown column filter). 4. The column filter has no effect / the table stays on "Processing". With only 1 condition, column filters work correctly. Fix: read/write the same 'f[]'/'q[]'/'op[]'/'c[]' vs 'f'/'q'/'op'/'c' convention in the preprocessing block, detected the same way the Bug 36930 filter constructor already does (checking for the bracketed param name among $cgi->multi_param). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 36644] New: Add option for 'Holds per item group' to circulation rules
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36644 Bug ID: 36644 Summary: Add option for 'Holds per item group' to circulation rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Not sure if this was a staff interface or hold request bug, so took a stab at it. We need a bit more granularity to hold policy on circulation rules for libraries using item group holds. Currently, libraries can only specify 'holds per record' in circulation rules, which is not a one-size-fits-all-holds solution - if they generally only want patrons to have one hold on a record for, say, books, but their manga collection is also a book item type, they have to set Holds per record (count) to a high or unlimited threshold to accommodate group holds. It would be great if circ rules could indicate a limit to holds per item group to give libraries flexibility in using item groups; many libraries probably only want one hold per item group, but they may have a collection where patrons can make multiple requests per group. Circ rules are a logical place to set this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 38181] New: Extreme slow search results on OPAC (only) search when result records contain multiple items.
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38181 Bug ID: 38181 Summary: Extreme slow search results on OPAC (only) search when result records contain multiple items. Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org When performing a search on the OPAC, if the results containing records that are having a large number of holdings (e.g serials with over 1000 issues/items or even less) there is a huge delay on showing the results (~x8 times slower for the same search if we remove the multiple items from the resulting records) The odd is that the exact same search on the intranet interface works without these delays so I'm guessing that this is a problem on the OPAC search implementation? The problem exists with zebra but also with the use of Elasticsearch engine. Using elasticsearch tried also removing all the item related indexes - 952* subfields (and re-indexing) but the result is the same. In the following google drive link you can find a demo bib record with 1809 items (MarcXML - Marc21) if it helps to reproduce it.https://drive.google.com/file/d/11SQmfdWal9tzcovS0mrgu6vIOPf1aCbc/view You will have to import the record, and then try searching for the title on OPAC: The Journal of biological chemistry. In my case with a decent server without load (Debian, 4cpu cores, 16gb RAM) with plack enabled takes about ~50sec to get the result. Regards -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 43811] New: Patron attribute types not sustainable across libraries
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43811 Bug ID: 43811 Summary: Patron attribute types not sustainable across libraries Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If a patron has a patron attribute type value that is limited to specific libraries, and another library that is not allowed to assign that value updates that patron without touching that attribute, they are forced to change the attribute. Values that are limited to specific branches should be sustainable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0