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

[Bug 3492] Move hold fee setting into circulation rules
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #24 from Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> --- Hi, all my tests were good. A couple minor issues remain: * The db_rev is weird. Should be using the built-in column_exists. Please fix inline. * I expected to see the HoldFeeMode system preference in the holds area. It is in the 'Fines policy' one, which I believe is incorrect. Please fix that and we should find testers so I can do the final QA. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 38661] New: Add warning when deleting import batch
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38661 Bug ID: 38661 Summary: Add warning when deleting import batch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If a user deletes a Manage staged MARC records batch which is associated with imported records, they lose the ability to roll back the attached records. Sometimes this will be the intention, but other times they will simply have forgotten to revert a test import and those records are then impossible to roll-back. Could we have a warning message when deleting a batch with attached records such as "There are x imported records attached to this batch which cannot be reverted if you proceed. Do you wish to continue and delete the batch record?" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 40343] New: Koha to MARC mapping should suggest to run batchRebuildItemsTables.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40343 Bug ID: 40343 Summary: Koha to MARC mapping should suggest to run batchRebuildItemsTables.pl 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If changes are made to Koha to MARC mappings that affect the items table, the batchRebuildItemsTables.pl script needs to be run. Koha only suggests running the batchRebuildBiblioTables.pl script (and it took me an embarrassing amount of time to realise there was a second script that might be useful). It would be nice to also suggest the second script so other system administrators don't waste as much time as I did. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 39897] New: Make EDI accounts a configurable DataTable
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39897 Bug ID: 39897 Summary: Make EDI accounts a configurable DataTable Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The EDI accounts page seems odd without DataTable functionality! -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 39066] New: Fix "To screen into the browser"
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39066 Bug ID: 39066 Summary: Fix "To screen into the browser" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I'm not a native English speaker, but "To screen into the browser" sounds wrong. To find an example: Reports > Patrons with the most checkouts To find all occurrences: $ grep -rn --include=*.tt "To screen into the browser" * -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 40825] New: CGI::param called in list context from koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/itemsearch.tt
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40825 Bug ID: 40825 Summary: CGI::param called in list context from koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/item search.tt Change sponsored?: --- 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This is an TT issue with default list context on this template line: [% IF query.param(name _ '_op') == '=' || !query.param(name _ '_op') %] I am not sure if passing query to a template is a good idea anyway. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38417] New: Notification to the customer when their existing hold is about to expire and they are still waiting for it
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38417 Bug ID: 38417 Summary: Notification to the customer when their existing hold is about to expire and they are still waiting for it Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org It would be great if Koha would send a notification to the customer when their existing hold is about to expire (and is not yet waiting for pickup), e.g. "Your hold will expire in a month, do you still want to wait for it?" Sometimes waiting for a hold takes longer than the hold is valid. If the customer made the reservation several years ago, he may not remember its existence or notice its expiration date and the hold disappears. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40823] New: Default privacy setting should be renamed
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40823 Bug ID: 40823 Summary: Default privacy setting should be renamed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org The default privacy (borrowers.privacy=1) wording is problematic. It claims to be the default, yet it can also be not the default if patron category has set another default value (i.e. forever or never). OPAC privacy currently states the following: "Default: keep my history according to library policy. This is the default option : the library will keep your history for the duration set by library policy" I propose it to be changed to "Library policy" So they would look like this: Forever: keep my history without limit. This is the option for users who want to keep track of what they are reading or placed a hold on. Library policy: keep my history according to library policy. The library will keep your history for the duration set by library policy. Never: Delete my history immediately. This will delete all record of the item that was checked-out upon check-in, and hold history upon fulfillment or cancellation. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 40595] New: Privacy setting when changing patron category
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '25

17 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40595 Bug ID: 40595 Summary: Privacy setting when changing patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kalle(a)imcode.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When a patron's category is changed, the associated privacy setting (privacy) is not updated accordingly. For example, if the original category has privacy = 1 and the new category has privacy = 0, the patron's privacy setting remains at 1 after the change, instead of reflecting the new category's setting. This is problematic for clients who use specific patron categories to control whether circulation history should be stored and displayed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2