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

[Bug 32748] New: Library limitations will cause data loss when editing items
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Bug ID: 32748 Summary: Library limitations will cause data loss when editing items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Moving this from bug 31422 where another issue was fixed to a new bug report: The library limitations are used to limit down the selection in pull downs in several spots. If you are editing data from library B while logged in at library A, doing so might result in data loss as the value stored in the modified object might be missing from the drop downs your user sees. Example 1: Item values Itemtype: BK Books - limited to Centerville AV LOC: FIC Fiction - limited to Centerville Your user: logged in for Centerville * Edit an item and make sure it uses the itemtype Books and location Fiction. * Switch library to any but Centerville. * Edit item: Both item type and location drow downs will be empty. * Saving now will empty out itemtype (if not set mandatory) and location resulting in data loss. I initially thought that bug 20256 might help here, but it won't as there is a mismatch of one feature checking the login library and the other checking the home library of the staff patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 99

[Bug 30319] New: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30319 Bug ID: 30319 Summary: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a field is hidden for self-registration, Koha is mistakenly discarding values for that field in self-modification. Somehow these two sysprefs are not being enforced distinctly. To test: 1 - turn on OPACPatronDetails 2 - confirm PatronSelfModificationBorrowerUnwantedField is blank, all fields allowed 3 - set PatronSelfRegistrationBorrowerUnwantedField to hide Title 4 - log into the opac, go to self mod (/cgi-bin/koha/opac-memberentry.pl), set a title (it is not hidden, which is correct), and save your updates 5 - go to the patron modification page in the staff interface (/cgi-bin/koha/members/members-update.pl), confirm your modification request is there but shows no changes 6 - update PatronSelfRegistrationBorrowerUnwantedField to allow title 7 - repeat step 4 8 - your new modification request shows a change to title -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 20846] New: Suppressed Records Still Appear in Public Lists
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20846 Bug ID: 20846 Summary: Suppressed Records Still Appear in Public Lists Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1. Add a title to a public list 2. Edit the 942$n to suppress the record 3. Confirm that the record isn't visible in the opac 4. Confirm that the title still shows in the list It'd be great to have suppressed records hidden from lists. Even if the link from the list to the bib takes the user to the blocked record page, showing the title in the list is confusing. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 42503] New: Optimize retrieval and display of the holds queue
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42503 Bug ID: 42503 Summary: Optimize retrieval and display of the holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com The holds queue page (view_holdsqueue.pl) should be reworked to fetch data via API to improve performance for large systems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 180

[Bug 38407] New: Eliminate event handler attributes in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 Bug ID: 38407 Summary: Eliminate event handler attributes in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Like bug 34709 but for the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 43257] New: Remove event attributes from circulation.tt
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43257 Bug ID: 43257 Summary: Remove event attributes from circulation.tt Initiative type: --- Sponsorship Sponsored 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 Blocks: 38407 Target Milestone: --- circulation.tt has a couple of "onclick" event attributes which should be moved to checkouts.js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 43241] New: REST API: q= parameter bypasses datetime conversion for values nested in DBIC operators
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43241 Bug ID: 43241 Summary: REST API: q= parameter bypasses datetime conversion for values nested in DBIC operators Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- When datetime filter values are passed inside DBIC operators (-and, -or) in the q= parameter, _recursive_fixup is never called on them. This means RFC3339 timestamps (e.g. 2026-08-05T00:00:00Z) reach MySQL unconverted. On tables with many rows (e.g. action_logs), MySQL cannot use the timestamp index when comparing against ISO 8601 format with the T separator, causing full table scans and very slow responses. The root cause is architectural: 1. _parse_dbic_query (in Koha::REST::Plugin::Query) maps field names but does not convert values 2. attributes_from_api (which calls _recursive_fixup for the conversion) is called on the merged result, but only iterates top-level keys 3. When the top-level key is -and or -or, the nested column values are passed through without fixup This affects any kohaTable-based page that combines default_filters with a global search term, since the DataTables layer wraps the combined query in -and. The fix: - Move attributes_from_api to process named query params before merging with q params - Teach _parse_dbic_query to call _recursive_fixup when it encounters a key that maps to a known column This ensures RFC3339 values are converted to MySQL-native format regardless of query nesting depth. Related: Bug 43208 (reported as a viewlog performance issue, same root cause) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 43215] New: Checkbox/sortable system preferences show one 'Saved preference' message per option instead of per preference
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43215 Bug ID: 43215 Summary: Checkbox/sortable system preferences show one 'Saved preference' message per option instead of per preference Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration 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 Depends on: 42553 Target Milestone: --- Found while testing bug 42553 (multiple_sortable: authval dispatcher for admin/preferences.pl). When a system preference uses the multiple_sortable (checkbox-group) widget in admin/preferences.pl - e.g. OPACAuthorIdentifiersAndInformation, ArticleRequestsSupportedFormats, or a new authval-sourced pref such as the one added by bug 42553 - saving the preference from Administration > System preferences pops up one "Saved preference ..." confirmation line per checkbox/option, instead of a single line for the preference itself. For example, saving a pref called TestSortableAV with two selected authorised values produces: Saved preference TestSortableAV_CASH Saved preference TestSortableAV_SIP00 Root cause: in koha-tmpl/intranet-tmpl/prog/js/pages/preferences.js, the ".preference-checkbox" change handler marks every checkbox of every checkbox-group preference on the page as "modified" (not just the ones belonging to the changed preference), and dragging an item in the SortableJS list synthetically fires change() on the list's first checkbox, triggering the same global marking. KOHA.Preferences.Success() then builds the confirmation message by iterating every ".modified" element and using its own DOM id (which is per-checkbox, e.g. pref_TestSortableAV_CASH), rather than grouping by the underlying preference name. This is pre-existing behaviour, reproducible today on main with the existing checkbox-group prefs. It is not introduced by bug 42553, but that patch makes the widget easier to reach for new prefs, which is how it was noticed during QA. Test plan: 1. On a system with a multiple_sortable/checkbox-group syspref (e.g. OPACAuthorIdentifiersAndInformation), select two or more checkboxes and save. 2. Note the confirmation message contains one "Saved preference ..." line per checkbox rather than one line for the preference. 3. Expected: a single confirmation line per changed preference, regardless of how many checkboxes/options it contains. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42553 [Bug 42553] preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 42553] New: preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42553 Bug ID: 42553 Summary: preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The 'choices' renderer in admin/preferences.pl already supports a dynamic 'authval' source pattern, where the YAML can say: choices: authval source: SOMECATEGORY and the choices are populated from the named authorised value category at render time. The 'multiple_sortable' renderer (the SortableJS-backed drag-and-drop multi-select used by OPACAuthorIdentifiersAndInformation and ArticleRequestsSupportedFormats) does not have an equivalent. Choices must be hardcoded in the .pref YAML. This bug adds the same dynamic-source pattern to multiple_sortable so prefs needing an ordered, picker-driven multi-select of authorised values can declare: multiple_sortable: authval source: PAYMENT_TYPE Motivation: Bug 33501 (cashup amount should be configurable) needs an ordered multi-select of PAYMENT_TYPE auth values for a new CashupPaymentTypes preference. Adding it generically here means future prefs benefit too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43239] New: Serial items item type can be set incorrectly when receiving multiple items
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43239 Bug ID: 43239 Summary: Serial items item type can be set incorrectly when receiving multiple items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- It is possible to create serial item with wrong itemtype if syspreference makePreviousSerialAvailable is enabled and field "item type for older issues" isn't filled when creating a subscription for biblio record. This happens when multiple items are created. In installations where itemtypes differ between items and biblios, this causes data inconsistencies and leads to errors in biblios Holdings table. To reproduce: 1. Enable systempreference makePreviousSerialAvailable. 2. Create new biblio record. 3. Create a new subscription for biblio record you made, select option "Create an item record", select different item type from "Item type" selection than biblio record has but leave selection "item type for older issues" empty. 4. Receive a serial item for subscription. Check from biblio records Holdings table that its item type matches item type selected in step 3. 5. Now receive 3 serial items. After creating them check Holdings table again. => Note that last item created now has same item type as biblio record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17