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

[Bug 41719] New: Add rendering test coverage for Labels and Patroncards
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41719 Bug ID: 41719 Summary: Add rendering test coverage for Labels and Patroncards Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org The label and patron card rendering code paths in C4::Labels::Label and C4::Patroncards::Patroncard lack test coverage for their core drawing methods. This patch adds: - t/db_dependent/Labels/t_Label.t - Extends existing tests with subtests for: - draw_label_text() - text positioning and formatting - draw_guide_box() - guide box rendering - barcode() - all supported barcode types (CODE39, COOP2OF5, INDUSTRIAL2OF5, EAN13) - create_label() - printing type orchestration (BIB, BAR, BIBBAR, BARBIB) - t/db_dependent/Patroncards/t_Patroncard.t - New test file covering: - draw_guide_box() and draw_guide_grid() - draw_text() with patron data substitution - draw_barcode() with multiple barcode types - draw_image() with generated test image - End-to-end PDF output validation Tests use t::lib::TestBuilder fixtures and transaction rollback for isolation. AI Disclosure: This contribution was developed with AI assistance (Claude Opus 4.5, Anthropic). See commit message for full disclosure per https://wiki.koha-community.org/wiki/Coding_Guidelines#.5BDRAFT.5D_AI_and_L…. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 38187] New: Add ability to delete patron attributes in batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38187 Bug ID: 38187 Summary: Add ability to delete patron attributes in batch patron modification 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: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com You can batch modify patron attribute in a batch, but you cannot completely delete the attribute on a patron's account. To test: - Add an attribute to a patron's account. - Perform batch patron modification. - Under Patron attribute you can either add a new attribute or update existing one. You can set the attribute to blank to clear the values, but the attribute will remain on the account as blank. It would be nice if there's a way to delete the patron attribute all together. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[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 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 43520] New: Replace PatronAutoComplete with PatronSelect in FormElement.vue
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Bug ID: 43520 Summary: Replace PatronAutoComplete with PatronSelect in FormElement.vue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 43518 Target Milestone: --- Bug 43518 added PatronSelect.vue, a modern Vue 3 / TypeScript patron picker built on vue-select, as a drop-in replacement candidate for the legacy PatronAutoComplete.vue (which wraps jQuery UI's autocomplete widget and the global window.patron_autocomplete()/patron_autocomplete_render_selection() functions). This bug tracks migrating PatronAutoComplete's remaining consumer -- FormElement.vue's generic "patronAutoComplete" driven-form field type -- onto PatronSelect, and closing the gaps that stand in the way: 1. v-model contract mismatch: FormElement.vue binds v-model="resource[attr.name]" as a bare patron ID. PatronSelect's modelValue is a full option object built by patronToOption() (vue/utils/patron-options.js, added in bug 43518). This needs an adapter at the FormElement.vue integration point, or a deliberate decision to change what that field type stores. 2. Initial-selection hydration: PatronAutoComplete fetches and renders the currently selected patron on mount when given an existing ID (used when editing a record that already has a patron attached). PatronSelect has no equivalent built in by design -- it stays side-effect-free -- but bug 43518 added resolvePatronOption() specifically for this: given a bare id it fetches and maps the patron, given an already-embedded patron record it maps only. FormElement.vue's integration needs to call this before/while mounting PatronSelect when editing an existing resource. 3. Confirm parity for anything else FormElement.vue's "patronAutoComplete" field type relies on from PatronAutoComplete (e.g. the patronAutoCompleteOptions "additional-filters" passthrough), and either port it to PatronSelect's query-building convention (reusing the existing buildPatronSearchQuery() global, as bug 41129's booking adapter already does) or document why it does not apply. Out of scope: request.tt calls window.patron_autocomplete() directly (not through the Vue wrapper), so it is unaffected by this migration. Test plan: 1. Apply on top of bug 43518. 2. Find a form rendered via FormElement.vue with a "patronAutoComplete" field (e.g. a plugin custom field, if applicable in your test data), for both create and edit. 3. Verify searching, selecting, and clearing a patron all work, and that an existing selection is shown correctly when editing. 4. Run the existing FormElement.vue Cypress component spec plus any new coverage added for this migration. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 [Bug 43518] Add a reusable PatronSelect Vue component with patron search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43355] New: Add a /search API endpoint for biblios
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43355 Bug ID: 43355 Summary: Add a /search API endpoint for biblios Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, dcook(a)prosentient.com.au, hammat.wele(a)inlibro.com, jonathan.druart(a)gmail.com, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, magnus(a)libriotech.no, mathsabypro(a)gmail.com, paul.derscheid(a)lmscloud.de, philippe.blouin(a)inlibro.com, tomascohen(a)gmail.com Depends on: 25870, 32734 Blocks: 27113, 27428 Target Milestone: --- +++ This bug was initially created as a clone of Bug #25870 +++ To try and get that bug moving again I thought I'd work from a blue sky proposal taking comments from the original bug into consideration and adding a dedicated /search endpoint. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 [Bug 25870] Add a q_ccl query parameter to /biblios (ie add search API endpoint) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 [Bug 27113] Elasticsearch: Autocomplete in search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27428 [Bug 27428] Show the number of records in the bibliographic record detail page with Elasticsearch https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32734 [Bug 32734] Add GET endpoint for listing Biblios -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[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 43151] New: ES should apply search filters on each item discretely
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43151 Bug ID: 43151 Summary: ES should apply search filters on each item discretely Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42835 Target Milestone: 26.11 When filtering search results using item record values, Koha checks for each of those values at the biblio level, rather than at the item level. This leads to undesirable search results. For example, assume you have a biblio with two items: - item 1 is itype BOOK and collection FICTION - item 2 is itype AUDIO and collection NONFICTION Currently, if a user performs a search limited to itype=BOOK and collection=NONFICTION, this biblio will be returned because it has at least one BOOK item and at least one NONFICTION item. But the user expectation is that the search will return biblios where at least one item that is both a BOOK and NONFICTION. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 [Bug 42835] ElasticSearch should have an items index -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19