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

[Bug 41647] New: Make self-checkin use responsive CSS
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41647 Bug ID: 41647 Summary: Make self-checkin use responsive CSS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As per bug 41645, the self-checkin has access to responsive CSS, but can't use it because it's missing 1 line of HTML: <meta name="viewport" content="width=device-width, initial-scale=1"> Once that line is added, the CSS media queries start to work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 40568] New: Various corrections to recalls templates
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40568 Bug ID: 40568 Summary: Various corrections to recalls templates Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 40560, 40566 I've got a few random corrections to make to a couple of recalls templates. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40560 [Bug 40560] Incorrect breadcrumb on recall history https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40566 [Bug 40566] "Home library" empty on "Recalls history" -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 41043] New: Use op 'add_form' and 'edit_form' instead of 'add' and 'edit'
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41043 Bug ID: 41043 Summary: Use op 'add_form' and 'edit_form' instead of 'add' and 'edit' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since CSRF protection, 'op' arg for creating/editing an object uses add_form and edit_form. This is missing only in admin/oai_servers.pl and admin/z3950servers.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 43094] New: Add ability to specify which lost statuses debit patron accounts
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43094 Bug ID: 43094 Summary: Add ability to specify which lost statuses debit patron accounts Initiative type: --- Sponsorship --- status: 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: holly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When WhenLostChargeReplacementFee is set to "Charge" any lost status update on a checked out item adds a debit to the patron account. There should be a way to control whether all or selected lost values add the debit. Something like this has been done for Claim Returned, using ClaimReturnedChargeFee. A checkbox or setting in the LOST authorized values would be user friendly. Something like this could give libraries back more control of when patrons are billed, while maintaining the consistency of what each lost status means. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39437] New: Patron notes and item notes populating Notes column of checkedin table
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39437 Bug ID: 39437 Summary: Patron notes and item notes populating Notes column of checkedin table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, in Circulation > Check in the Notes column of the table of check-ins is populating with the item notes AND notes on patron accounts, which can lead to vast expansion of this table when a patron has a lot of notes on their account. It would be useful if there were a way for libraries to hide either the item notes or the patron notes from this column of this table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 42504] New: Remove totalissues from stored MARC, embed at index time
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42504 Bug ID: 42504 Summary: Remove totalissues from stored MARC, embed at index time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org ## Problem update_totalissues.pl can run for 4+ hours on large installations. The root cause is that totalissues is stored in the MARC record (942$0), requiring the full ModBiblio pipeline per biblio: MARC XML deserialization, field update, serialization, TransformMarcToKoha, DB updates, search engine reindexing, cataloguing log entries, plugin hooks, OAI sets updates. The existing UpdateTotalIssuesOnCirc syspref provides real-time updates on checkout but is disabled by default because it triggers this same expensive ModBiblio pipeline on every checkout. Bug 36474 improved things by skipping unchanged records, but every changed record still pays the full cost. ## Proposal Stop storing totalissues in the MARC record. Instead: 1. UpdateTotalIssues becomes a lightweight DB-only operation: just UPDATE biblioitems SET totalissues = ? WHERE biblionumber = ? plus queue a search index update. No MARC parsing, no ModBiblio. 2. Inject 942$0 at index time via Koha::Biblio::metadata_record: Add an embed_total_issues parameter (following the existing embed_items pattern). Both search engine indexers call metadata_record to get the MARC before indexing. The value gets injected from biblioitems.totalissues on the fly, just like items are embedded today. The stored MARC in biblio_metadata stays clean. Both the ES indexer (_get_record) and Zebra's rebuild_zebra.pl -d (which already pre-processes records before sending to Zebra) would pass this flag. 3. UpdateTotalIssuesOnCirc becomes cheap enough to enable by default: A DB column update plus a reindex queue entry per checkout is trivial. The Elasticsearch indexer already batches indexing tasks efficiently. 4. update_totalissues.pl is simplified: It recalculates biblioitems.totalissues from statistics/items data and triggers batch reindexing. It no longer touches MARC records at all. It should also gain a --commit option to control batch sizes for the reindex step. ## Expected impact - Real-time totalissues updates on checkout with negligible performance cost - update_totalissues.pl runtime reduced from hours to minutes (DB updates + batch reindex vs per-record ModBiblio) - No more MARC record churn for a derived counter value - Reduced action_logs noise (no cataloguing log entries for counter updates) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 41128] New: ratings.js creating "undefined" text for screen readers
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41128 Bug ID: 41128 Summary: ratings.js creating "undefined" text for screen readers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you try to print the user summary table, you'll likely see a bunch of "undefined" text in the table. It looks like ./koha-tmpl/opac-tmpl/bootstrap/js/ratings.js iterates through some of the HTML and tries to create spans with text from the data-rating-value attribute, but that attribute doesn't exist, so it uses the text "undefined" instead: <div class="br-widget br-readonly"> <a href="#">undefined</a> <a href="#">undefined</a> <a href="#">undefined</a> <a href="#">undefined</a> <a href="#">undefined</a> </div> -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 39706] New: Accessibility: Missing text alternative for the star rating.
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39706 Bug ID: 39706 Summary: Accessibility: Missing text alternative for the star rating. 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 After trying to navigate in Koha with a screen reader, I noticed that the star rating of the record was difficult to understand without sight. The stars don’t have text alternatives, and the links are empty. It would be great to improve this! If you want to test this issue, you can use screen readers like Orca. There are some pages with star ratings: Enable the following system preference: OpacStarRatings (results, details, and patron). -The results page (make a search). -The OPAC details page (choose a record). -Your summary "checked out" page (You have to make a checkout before for your patron account. Go to the staff interface, enter the card number or your patron name in the search bar, and make a checkout). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 42165] New: OPAC main search should include role="search"
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42165 Bug ID: 42165 Summary: OPAC main search should include role="search" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.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 https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/R…: "Landmark roles are intended to be used sparingly, to identify larger overall sections of the document. Using too many landmark roles can create "noise" in screen readers, making it difficult to understand the overall layout of the page." The search bar is a primary function of the catalog and should include the role="search" attribute. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 39998] New: Missing presentation role on layout tables.
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39998 Bug ID: 39998 Summary: Missing presentation role on layout tables. 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 When tables are used for layout purposes, we should add the WAI-ARIA presentation role attributes. Misinterpreting layout tables as data tables can confuse users who rely on assistive technologies. For example, a screen reader will interpret the element as a data table and announce the number of rows and columns and the content inside. By adding role=”presentation”, the screen reader will just read the elements making the content more accessible and easier to understand, without unnecessary information. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21