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

[Bug 37886] New: SQL reports - Multiselect parameters should be optional
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37886 Bug ID: 37886 Summary: SQL reports - Multiselect parameters should be optional Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: blawlor(a)clamsnet.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 37077 When a report is written with multiselect parameters and the the report is run with nothing selected the report results should not be limited. Multiselect reports use the IN() function, so the SQL should be generated with a comma separated list of all of the authorised values. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37077 [Bug 37077] SQL Reports - Picking only one option for each multiple selection results in wrong query -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 37077] New: SQL Reports - Picking only one option for each multiple selection results in wrong query
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37077 Bug ID: 37077 Summary: SQL Reports - Picking only one option for each multiple selection results in wrong query Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: andrewfh(a)dubcolib.org, blawlor(a)clamsnet.org, caroline.cyr-la-rose(a)inlibro.com Depends on: 35746 To reproduce: 1. Go to Reports and create a report from SQL select * from items where homebranch in <<Libraries|branches:in>> and itype in <<Item type|itemtypes:in>> 3. Run the report but pick only 1 library and 1 item type 4. Click the "Show SQL code" 5. Notice itype value is wrong. It's using the same value selected for library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35746 [Bug 35746] Multiple selections for parameters used in the IN function -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 39569] New: When cancelling a hold waiting past expiration date triggers a transfer the libraries name is not in alert
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39569 Bug ID: 39569 Summary: When cancelling a hold waiting past expiration date triggers a transfer the libraries name is not in alert Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: - Use a bib with a single item to make this easier - Place two holds on a bib with pickup at one library - Place some more holds for pickup at a different library - Check the item in to the first library - Set the expiration date back in time, using ktd --dbshell can help update reserves set expirationdate = DATE('2024-01-01') where branchcode='CPL'; - On Holds awaiting pickup > Holds waiting past their expiration date use the button in the actions tab to 'Cancel hold' the alert says: This item is on hold for pick-up at your library' - click OK - Check the item in again and set expiration date to expired again - On Holds awaiting pickup > Holds waiting past their expiration date use the button in the actions tab to 'Cancel hold and transfer to: [libraryname]' - Notice the alert says 'This item is on hold for pick-up at' with no library name -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 39597] New: When cancelling multiple holds on a bib record cancel_hold_alert has very low contrast
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39597 Bug ID: 39597 Summary: When cancelling multiple holds on a bib record cancel_hold_alert has very low contrast Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Created attachment 180747 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180747&action=e… screnshot To recreate: - Go to a bib record and place multiple holds on it - Select multiple holds and click 'Cancel selected (4)' - The Alert says 'This action will cancel 4 hold(s).' - Note that the contrast on the number of holds is very low -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 31487] New: Add emails to message queue by longoverdue script options
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31487 Bug ID: 31487 Summary: Add emails to message queue by longoverdue script options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some customers request the possibility of sending an additional reminder when processing longoverdues. I think this may be useful for some and given that it remains an option, it does not handicap those who do not want to use it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 18064] New: Long overdue cronjob does not follow the library' s calendar and skip closed days
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18064 Bug ID: 18064 Summary: Long overdue cronjob does not follow the library's calendar and skip closed days Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The cronjob that sets the Long overdue does not follow the library's calendar and skip closed days. However, the cronjob that sends the email (overdue notices) does follow the library's calendar. So as an example on a weekend where Monday is a holiday, the long over due may get set and chanrge the patrons account, but the email may be sent a day or 2 later. It would be good to allow the long overdue cron to follow the library calendar and skip closed days. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 85

[Bug 33501] New: Cashup amount should be configurable
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Bug ID: 33501 Summary: Cashup amount should be configurable 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems the Cashup summary only accounts for the cash payment type. We have a check payment type that should also be included. Am I missing a configuration somewhere, or do we need some way to define what should be included in the summary and intake balance? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 40294] New: Mandatory patron expiration notice is not sent if patron does not have a primary contact method defined
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40294 Bug ID: 40294 Summary: Mandatory patron expiration notice is not sent if patron does not have a primary contact method defined Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 30301 Bug 30301 added the option to force mandatory account expiration notices for a given patron category in the membership_expiry cron. In these cases, the primary contact method on the patron account is used to determine the transport type for the notice. However, primary contact method may not be a mandatory field depending on the system preference settings. If a patron doesn't have a primary contact method set for their account, this causes the notice not to get sent at all, even if the patron has one or more valid email addresses or SMS number on their account. We need a fallback to ensure the mandatory notice is sent in this case. I think it would make the most sense to specify transport type(s) in the patron category settings when making account expiration notices mandatory for that category. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30301 [Bug 30301] Add an option to specify the patron expiration notices as mandatory by patron category -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 84

[Bug 33557] New: Add a system preference to disable/enable thesaurus checking during authority linking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33557 Bug ID: 33557 Summary: Add a system preference to disable/enable thesaurus checking during authority linking Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 30280 added support for multiple thesauri, however, this is a major change in behavior. Prior to this patch, heading from different sources would all link to the same authority, and auto generated authorities would link to any source. After this patch, however, a library will need to reindex their authorities after upgrade or face linking issues. For libraries who auto create authorities, there is the potential for generating a new set of authorities for any record from a differing source. In order to minimize disruption, we should provide a system preference, disabled by default, to allow libraries to opt in to thesaurus checking -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 35902] New: Add English country and language codes as authorised values to be using in cataloguing MARC21 008 builder plugin
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35902 Bug ID: 35902 Summary: Add English country and language codes as authorised values to be using in cataloguing MARC21 008 builder plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing a biblio record, you can launch a builder plugin for 008. Positions 15 to 17 hold a two- or three-character alphabetic code that indicates the place of publication, production, or execution. There is a link to a MARC Code List for Countries Positions 35 to 37 hold a three-character alphabetic code for language. There is a link to a MARC Code List for Languages. It would be helpful if these codes were available as authorised value categories, to prevent user typing error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15