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

[Bug 41882] New: Batch hold modification tool updates pickup locations to disallowed libraries
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41882 Bug ID: 41882 Summary: Batch hold modification tool updates pickup locations to disallowed libraries Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library's 'Holds and bookings policies by item type' is set to only allow pickup at an item's home library, the batch hold modification tool can still be used to update a hold's pickup location to other libraries such that the hold will never trigger to fill. To replicate: -Set ReservesControlBranch to 'item's home library' -Set Main library's 'Holds and bookings policies by item type' so that PASS items can only be picked up at Main -Place a hold on a bib whose only item is a PASS belonging to Main -Use the Batch hold modification tool to identify the hold you just placed -Update the pickup location to North. Note that the update is successful, and there's no indication that the pickup location is now a problem. -Check in Main's PASS, and note that the hold doesn't trigger to fill The batch update shouldn't process for holds where the change will make the hold unfillable per a library's 'Holds and bookings policies by item type'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 36135] New: Add tool to batch edit pick up dates of holds
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36135 Bug ID: 36135 Summary: Add tool to batch edit pick up dates of holds 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are sometimes situations where libraries have to extend their holds pick up dates. We should at same kind of tool for this like "Batch extend due dates". However criteria for dates to extend can be complicated (we've excluded e.g. items with specific state, holds with found status, items on transfer to specific library). So rather than using predefined criteria for holds to edit (at least for the start), tool should have option to upload file of SQL query results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 270

[Bug 32031] New: Sidebars and Breadcrumbs
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32031 Bug ID: 32031 Summary: Sidebars and Breadcrumbs 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the staff client refresh I've had a nagging feeling about the breadcrumbs appearing above the sidebar navs.. it feels a bit messy but I hadn't come up with a better solution. I wonder about shifting the sidebar so it goes all the way to just under the top header and shift the breadcrumbs to the right... a bit like gitlab? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42322] New: Collapse sidebar
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42322 Bug ID: 42322 Summary: Collapse sidebar Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 On bug 42190 we discuss the possibility to collapse the sidebar in order to enlarge the screen and specifically the table in the main div. It would be good to have the behaviour available everywhere, not only on the report result view. -- You are receiving this mail because: You are watching all bug changes.

1 184

[Bug 43469] New: Duplicate records in biblio and deletedbiblio tables if deleting records metadata fails
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43469 Bug ID: 43469 Summary: Duplicate records in biblio and deletedbiblio tables if deleting records metadata fails Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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: --- A while ago we faced a deadlock problem with our biblio_metadata table. This led to our biblio record deletion background jobs to fail, leaving duplicate records in biblio and deletedbiblio tables, moving biblioitems row to deletedbiblioitems and leaving metadata to biblio_metadata table. While this really is an edge case and happened because our own scripts were interfering delete process of metadata, I suggest that we add rollback to addbiblio.pl in case something goes wrong with delete. Also we should handle FIXME in line 867 and move error message to template alert. This is tricky to reproduce and only way I could think of is to break code in sub _koha_delete_biblio_metadata directly. To reproduce: 1. Create a biblio record. 2. Find sub _koha_delete_biblio_metadata from Biblio.pm and break it e.g. remove one column from SQL query. 3. Attempt to delete biblio. => Error "ERROR when DELETING BIBLIO x : Exception raised - DBI Exception: DBD::mysql::db do failed..." is raised but not as standard template error as in other error cases. 4. Search your biblio from database. => Note that biblio is in both biblio and deletedbiblio table. => Note that biblio has been inserted to deletedbiblioitems table and deleted from biblioitems table. => Note that biblios metadata is still in biblio_metadata table but not in deletedbiblio_metadata table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32776] New: Choose to convert oldest reserve or all possible reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32776 Bug ID: 32776 Summary: Choose to convert oldest reserve or all possible reserves to recalls Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 31415 introduces a script to convert reserves to recalls. By default, it will take the oldest reserve on a record and convert it to a recall. We should be able to customise which reserve(s) are converted to recalls. Options may include: - oldest reserve - one reserve for each issued item available to be recalled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 43407] New: Database permissions, different users and "schemas"
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43407 Bug ID: 43407 Summary: Database permissions, different users and "schemas" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- A standard Koha instance defines one database account in koha-conf.xml. Koha::Database uses this account for normal DBI and DBIx::Class connections. The Debian installation creates this account with ALL PRIVILEGES on the complete instance database. Consequently, the same database identity is used by the OPAC, staff interface, background workers, command-line tools, database updates, reports, and plugins. It can read and modify operational data, but can also create, alter, and drop database objects. The same logical database/schema contains data with very different ownership and lifecycle requirements: * primary transactional and catalogue data; * configuration and mapping data; * denormalised or generated data; * transient state such as sessions, saved report results, tmp_holdsqueue, and zebraqueue; * plugin-owned tables and indexes. The problem is not merely that Koha uses one database. The problem is the assumption that one highly privileged service account and one schema should be used for every workload. Separate database identities could materially improve security by applying the principle of least privilege. For example: * An OPAC database account could have SELECT access to catalogue, availability, and public configuration data, no access to unrelated tables such as acquisitions or administrative plugin data, and narrowly scoped INSERT or UPDATE permissions only for supported patron operations such as holds, renewals, suggestions, tags, and account changes. It would have no DDL privileges. * A reports account could be strictly read-only. Preferably it would query an allowlisted of tables/views instead of receiving SELECT access to every table. This would also permit sensitive patron, authentication, or financial columns to be excluded or masked. * A staff runtime account could receive the DML permissions required for normal staff operations but no CREATE, ALTER, or DROP privileges. * A dedicated migration account could hold DDL privileges and only be made available while installing or upgrading Koha. Web applications and background workers would not have access to these credentials. * Background workers, search components, and plugins could use separate accounts with permissions limited to their queues, indexes, caches, or plugin-owned schemas. This would reduce the impact of a compromised component. For example, an OPAC vulnerability would not automatically provide access to every Koha table or permit schema changes. A reporting error or malicious report could not modify production records. Separate identities would also improve auditing, credential rotation, and attribution of database activity. Database permissions would not replace Koha's application-level authorization. Some OPAC features require writes, and permissions would need to reflect enabled features. The initial implementation could therefore be optional and use documented privilege profiles rather than attempting an immediate mandatory split. A possible incremental improvement would be support for named database connections in koha-conf.xml. Individual interfaces and components could select an appropriate connection, while the current single-account configuration remains the compatibility default. Such support would need defined behaviour for installation, upgrades, transactions, connection selection, backups/restores, testing, reporting, and deployments where cross-schema foreign keys are unavailable or undesirable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43571] New: (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '26

19 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43571 Bug ID: 43571 Summary: (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 12757 Target Milestone: --- In the data collected by libraries, there are sometimes strings that "look like numbers" but are actually strings. The change introduced by Bug 12757 is confusing for libraries in such cases. Such strings should therefore not be automatically converted to the float format without user control. Instead, this behavior should preferably be controlled by a global system preference, or possibly by an option for a specific report or export. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 [Bug 12757] Integers in saved SQL report ODT export prepended with single quote -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 12757] Integers in saved SQL report ODT export prepended with single quote
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '26

19 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 Janusz Kaczmarek <januszop(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43571 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43571 [Bug 43571] (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43564] New: Add ability to pass arguments to plugins in plugins_nightly.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43564 Bug ID: 43564 Summary: Add ability to pass arguments to plugins in plugins_nightly.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: bastien.chauvet(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- It would be beneficial for plugins_nightly.pl to accept arguments to pass to plugins using the cronjob_nightly() method. As it would allow those plugins to more easily adapt their behaviour depending on the situation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2