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

[Bug 39868] New: koha-common fails to install on trixie
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '25

15 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39868 Bug ID: 39868 Summary: koha-common fails to install on trixie Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com The reason for this, is an issue with `rabbitmq-server`. The shipped configuration lacks some entries pointing to the plugin install dir, or the install dir doesn't exist. To reproduce: ```shell $ docker run -ti debian:trixie bash $ apt update ; apt install -y rabbitmq-server $ rabbitmq-plugins enable rabbitmq_stomp ``` The last command is what `koha-common.postinst` runs then the `koha-common` package is installed/upgraded. Hence the failure This is a `trixie` bug to keep an eye on. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 30030] New: Test t/db_dependent/Koha/Patrons.t is_going_to_expire fails randomly
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '25

14 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30030 Bug ID: 30030 Summary: Test t/db_dependent/Koha/Patrons.t is_going_to_expire fails randomly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://jenkins.koha-community.org/view/master/job/Koha_Master_U18/lastComp… not ok 9 - On invalid "is going to expire" date, the method should not crash with "Invalid local time for date in time zone" -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 39807] New: Problems with search bar on intranet mainpage for users with limited permissions
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '25

13 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39807 Bug ID: 39807 Summary: Problems with search bar on intranet mainpage for users with limited permissions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Make or find a staff member with staff access and list_borrowers permission. 2. Visit the intranet mainpage and notice the 'Search catalog' label but there is no search box. 3. Click 'Search catalog', the search bar now appears 4. Add the 'edit_borrowers' permission 5. Revisit the intranet mainpage and notice both 'Search patrons' and 'Search catalog' links 6. Click on 'Search catalog', now you see both search bars stacked up. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31113] New: Permission change to so user can use marc modification template only when adding or editing single record
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31113 Bug ID: 31113 Summary: Permission change to so user can use marc modification template only when adding or editing single record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aspencatteam(a)clicweb.org QA Contact: testopia(a)bugs.koha-community.org Would like to see a permission to allow the application of marc modification template to single record, without having the permission to do batch record modification. This would allow admin to create marc modification template that a novice cataloger could use to supply certain fields they probably would not know to change. (Like in leader, 008, 007). We would not want them to be able to do batch record modification - just use template on single record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 31323] New: Edit item highlighting problem
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31323 Bug ID: 31323 Summary: Edit item highlighting problem 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To reproduce: 1 search the catalog 2 find a record with 1 item 3 click the edit button in the item table (to the right of Spine Label) 4 when I click "save changes" the item is still highlighted yellow It appears like the '.active' class is lingering. I think this might be caused by Bug 27526? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39287] New: Improve "Show volume" search with a more specialized search index
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39287 Bug ID: 39287 Summary: Improve "Show volume" search with a more specialized search index Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, michaela.sieber(a)kit.edu Currently the rcn index used to search for volumes contains all $w subfields from 7xx and 8xx linking fields. In some cases this is too broad, even tho we are additionally limiting to monographs. Example: Search volumes will also find - records with a 775$w - other edition - records with a matching 780/785$w - preceeding or succeeding ... A specific index for searching volumes (rcn-volumes) should contain: - 773$w (we still need to limit to monographic, because these could also be analytcal links) - 800$w - 810$w - 811$w - 830$w Once the index is defined we can update the XSLT and the method for determining if the "Show volumes" link should be shown to use it and have a correct result list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 36808] New: Slips should be a message transport type
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36808 Bug ID: 36808 Summary: Slips should be a message transport type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently we create entirely new notices for SLIP type notices when really they're just a different medium and thus should be a message transport type. I propose adding a SLIP message transport type and where appropriate merging the current SLIP notices into their corresponding non-slip counterparts. A 'slip' is just a small form printer and likely to have similar summary detail as an SMS for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 36809] New: DRY out notice and slip printing
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36809 Bug ID: 36809 Summary: DRY out notice and slip printing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a plethora of slip and notice printing controllers and templates. This makes it difficult to improve the notices tools and not miss area's.. we should really move to one or two definitive scripts and templates for printing slips and notices and remove all the duplicate unmaintained code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 30343] New: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30343 Bug ID: 30343 Summary: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Previously we had only used the e-mail delivery method in overduerules.pl. This worked great. When a patron didn't have an e-mail address, a printed notice was added to the attachment.txt file for printed notices. Now we have phone and sms added as delivery methods. However, if ANY of these fail (no SMS number or no primary phone, or in the case of Twilio, if the same notice is sent via e-mail or sms, the phone status shows as deleted to prevent duplication) a printed notice is added to the attachment.txt file for printed notices. There should be option to determine if a printed notice is generated if ANY of the other methods fail, or if ALL of the methods fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38615] New: Cancelling a waiting hold via SIP should include an option to move it to holds with cancellation requests
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '25

10 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38615 Bug ID: 38615 Summary: Cancelling a waiting hold via SIP should include an option to move it to holds with cancellation requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org You can cancel a hold via SIP, the hold is immediately canceled. There should be an option ( system preference ) to allow cancelled waiting holds from SIP to move to 'Holds with cancellation requests'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35