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

[Bug 38436] New: Unable to hide a column in the holdings table in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38436 Bug ID: 38436 Summary: Unable to hide a column in the holdings table in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the holdings table in the staff interface, if a column has a value, it is show regardless of the table settings. I think this is a regression from previous behaviour. I tested it on 23.05 and 24.05 and the table settings are taken into account and hide the undesired column. A use case example is for single-library system who want to simplify/shorten the holdings table, they might choose to hide the holding library column as it's always going to be the same as the home library. Having those two columns only doubles the information uselessly for them. To recreate : 1. View a record in the staff interface 2. In another tab, go to Administration > Table settings > Catalog > holdings_table and check 'is hidden by default' for holdings_holdingbranch 3. Go back to the tab with the record and refresh the page --> The 'Current library' column is still there -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 136

[Bug 33462] New: Force password change for new patrons
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33462 Bug ID: 33462 Summary: Force password change for new patrons Change sponsored?: --- Product: Koha Version: master 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.m.hall(a)gmail.com Patrons that register via OPAC create whatever password they want. But when staff create a patron account, patrons are given a password. It would be preferred if patrons were forced to change their password after first logging in when a staff member creates the account. Unfortunately, the password expiration field is not available when creating the account. It is only editable after. It would be ideal if the password field were shown, even when adding a new patron, and the patron category setup page had an option next to expiration settings to force patron to change password at login when entered by staff. Then, when a staff member is adding the new patron, the date could be defaulted to today. The OPAC self registration would not need to do this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 121

[Bug 34551] New: Don't allow Z39.50 import if MARC can't be converted to MARCXML
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34551 Bug ID: 34551 Summary: Don't allow Z39.50 import if MARC can't be converted to MARCXML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As I note on bug 34014 and bug 34549, if you've got the wrong encoding on your Z39.50 server, you can wind up importing MARC data that contains invalid data (like control characters). During copy cataloguing, there should be a warning that there's a problem with the data (possibly because of Z39.50 server config). That way we have librarians raising the flag that there's a problem before the data is in Koha rather than us doing cleanup after it's been imported. (Of course, bulk loaded MARC will still be a problem, but baby steps...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 21391] New: Add per user interface settings
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21391 Bug ID: 21391 Summary: Add per user interface settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are some setting in system preference, which are related to user interface and could be useful to have an ability to set it for each user separately and use global preference as fallback only. For example: StaffLangSelectorMode AudioAlerts intranetbookbag IntranetCatalogSearchPulldown viewISBD viewLabeledMARC viewMARC hide_marc IntranetBiblioDefaultView advancedMARCeditor CircSidebar ExportCircHistory previousIssuesDefaultSortOrder todaysIssuesDefaultSortOrder EnableSearchHistory numSearchResults defaultSortField defaultSortOrder displayFacetCount expandedSearchOption NumSavedReports And in the future the cash register from Bug 11373 There could be admin page where the system administrator could enable/disable the settings for users and then in users menu could be new item - interface settings where users could change their preferences. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 31383] New: Additional contents: We need a parent and child table
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31383 Bug ID: 31383 Summary: Additional contents: We need a parent and child table Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In the design of additional contents the idea of a parent-child relation is implicitly present. You have a default page and translations. But we do this in one table coming from the old news items. Several reports show (imo) that we would be better off creating a parent table listing the main news items, CMS pages or HTML content. And a child table containing all language related stuff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 173

[Bug 34952] New: Ability to limit visibility of CMS pages by logged in patron category
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34952 Bug ID: 34952 Summary: Ability to limit visibility of CMS pages by logged in patron category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org It would be awesome if we could choose which patron categories could view/access CMS pages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 37624] New: Link system preference to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37624 Bug ID: 37624 Summary: Link system preference to entry in the manual Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Each system preference in the manually can directly be linked to. So wouldn't it be nice if we could link to the entry directly from each system preference in the administration module? Maybe with a small icon or similar, separate from the help link on top of the page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 33991] New: Inventory tool should be run in the background for performance reasons
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33991 Bug ID: 33991 Summary: Inventory tool should be run in the background for performance reasons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The inventory tool takes a long time to run even for small batches of barcodes. This can lead to timeouts and other undesirable user behaviour. It would make sense to perform this computationally heavy workload via the background jobs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41416] New: Poor performance when clicking 'Update hold(s)' on request.pl for records with many holds
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41416 Bug ID: 41416 Summary: Poor performance when clicking 'Update hold(s)' on request.pl for records with many holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When updating holds priority or other fields on a record with many holds it can take a long time for the server to return. Looking at the code we call ModReserve for each hold on the page - ModReserve call _FixPriority for each hold - _FixPriority loops through every hold on the record an updates the priority to ensure correct ordering. The same outcome can be achieved in less time by calling _FixPriority a single time (per bib) after the loop -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 40896] New: Run report button should be disabled after click
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40896 Bug ID: 40896 Summary: Run report button should be disabled after click Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com When a staff member clicks the run report button in the guided reports interface, we should disable the button, and display some indication an action is occurring (such as a spinner). Jake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40