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

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source 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: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 39314] New: RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39314 Bug ID: 39314 Summary: RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Reported to Debian as it affects their next release which will do a jump from 3.10 to 4.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#10 Which can't work: https://www.rabbitmq.com/docs/upgrade «You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.» «stable feature flags have to be enabled before the upgrade. The upgrade will fail if you miss this step.» See there more more details. ----- For us: is there still data in RabbitMQ when stopping a Koha instance and upgrading it? I recall reading that the DB was basically mirroring the message queue data during a discussion about the actual need for a dedicated message queue. Does it mean the koha-common package can wipe the RabbitMQ data which will allow it to start without issue? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 37645] New: Add ability to batch waive fines
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37645 Bug ID: 37645 Summary: Add ability to batch waive fines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if there's an ability in Koha to waive fines/fees in a batch. This is part of a regular workflow for libraries, especially those who regularly purge patron accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 31391] New: Staff-side recalls
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31391 Bug ID: 31391 Summary: Staff-side 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 Add functionality for recalls to be placed via the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 330

[Bug 40594] New: Allow batch record modification to create multiple items on existing bibs
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40594 Bug ID: 40594 Summary: Allow batch record modification to create multiple items on existing bibs 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: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 185115 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=185115&action=e… MMT sample multiple mapped items Bug 26869 only considered one item to be added per library modification execution, if more than one item is mapped, it fails with an FK constraint. I don't know the reason behind it, but the original test plan stated: test with more than one occurrence of 952$a -> confirm 'FK constraint' error is shown, no modification made I don't think there's any reason why this restriction should exist. The attached Marc Modification Template sample should work perfectly fine and add new - multiple - items to biblio records, as mapped. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 39890] New: Accessibility: Add more Bypass blocks to the OPAC.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39890 Bug ID: 39890 Summary: Accessibility: Add more Bypass blocks to the OPAC. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: nina.martinez(a)biblibre.com 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 To improve the Opac accessibility, we can add more bypass blocks to facilitate keyboard navigation (WCAG 2.4.1). Currently, we have one bypass for 'skip to the main content.' We could also add a bypass to skip to the footer, to skip to the search and to skip to the menu for pages that have one. https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks.html -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 39420] New: Item edit breadcrumbs wrong
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39420 Bug ID: 39420 Summary: Item edit breadcrumbs wrong Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When you open a record detail view, this is the breadcrumb: ``` Home / Catalog / The title / Details ``` If you choose to edit its items, the breadcrumb becomes: ``` Home / Cataloging / Edit The title (Record # NN) / Items ``` So you cannot actually use the breadcrumb to go back to the detail page for the record, but instead you go to the MARC editor. I believe it should be like this instead: ``` Home / Catalog / The title / Edit items ``` If we wanted to have a shortcut for editing the MARC record, I would add a link in the breadcrumb like this: ``` Home / Catalog / The title ([edit](/the/url))/ Edit items ``` But, right now, it is super weird. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 35052] New: OpacHiddenItemsHidesRecord system preference should be considered on index time instead
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35052 Bug ID: 35052 Summary: OpacHiddenItemsHidesRecord system preference should be considered on index time instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: alexander.blanchard(a)ptfs-europe.com, dcook(a)prosentient.com.au, jacob.omara(a)ptfs-europe.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com Currently, results are being skipped after the search has been processed in C4/Search.pm. This may cause several unintended scenarios: 1) The first page has all the results skipped, even thought there are more results in 2nd page and so on, this will will result in a "No search results" page 2) The total search results number still shows 80 (for example), even if it has skipped 70 and is only showing 10. To reproduce we need to use both OpacHiddenItems and OpacHiddenItemsHidesRecord Use OpacHiddenItems and put some rules that hide some items Use OpacHiddenItemsHidesRecord = 'hide' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 41995] New: Autocomplete for syspref search
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41995 Bug ID: 41995 Summary: Autocomplete for syspref search 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 Depends on: 41994 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41994 [Bug 41994] REST API route to list system preferences -- You are receiving this mail because: You are watching all bug changes.

1 68

[Bug 38638] New: Offer the option to set non-priority option when placing multiple holds
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38638 Bug ID: 38638 Summary: Offer the option to set non-priority option when placing multiple holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 22789 When placing multiple holds in the staff interface there isn't an option to set the holds as non-priority. As far as I know there's not a technical reason not to include the option? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 [Bug 22789] Establish non-priority holds -- You are receiving this mail because: You are watching all bug changes.

1 14