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

[Bug 41428] New: validate_isbn.pl value builder contains untranslatable strings
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41428 Bug ID: 41428 Summary: validate_isbn.pl value builder contains untranslatable strings Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Depends on: 29980 "Invalid ISBN" alert of is not translatable. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29980 [Bug 29980] Validate ISBN when cataloguing bibliographic records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 29980] New: Validate ISBN when cataloguing bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29980 Bug ID: 29980 Summary: Validate ISBN when cataloguing bibliographic records 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 https://metacpan.org/pod/Business::ISBN Business::ISBN has a valid_isbn_checksum method that implements an ISBN check digit algorithm for both 10-digit and 13-digit ISBNs. Koha could adopt this to validate ISBNs when cataloguing biblios. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 41524] New: Validate ISBN when cataloguing bibliographic records using advanced editor
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41524 Bug ID: 41524 Summary: Validate ISBN when cataloguing bibliographic records using advanced editor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 29980 added ISBN validation but only in the basic editor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18148] New: Chronological order for public lists in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18148 Bug ID: 18148 Summary: Chronological order for public lists in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Some librarians ask us to have public lists in chronological order rather than in alphabetical order because some schools will have to kept them there for a long time. This results in a big list with many pages on which is more difficult to find the good list. 1) Go in an OPAC interface 2) Go to "Lists" normally in top left corner 3) A small list appears from the top of the screen, observe that this list is by modification date (not alphabetical order) 4) Clic then on public lists 5) Observe that all lists created are in alphabetical order and their order cannot be changed We are wondering if it's possible to have some sorting options for the results list like in the staff client interface. There, you can change for chronological (modification or creation date) but also by owner order. Thanks for helping us, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 60

[Bug 32483] New: Show requested changes to personal details in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32483 Bug ID: 32483 Summary: Show requested changes to personal details in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment when a user makes a request for changing the address or similar, there is a note on submitting the form, that the request will be forwarded to the library for processing. After that, when the page is reloaded, the old information still shows and there is no hint on a pending change request. It would be nice if we could show that there was still a change request pendingon the page, so that people don't resend them unnecessarily. And it would be great if we could show which changes were requested. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41161] New: Show patron modification request diff in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41161 Bug ID: 41161 Summary: Show patron modification request diff in OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Bug 32483 adds pending patron modification request notification to OPAC. It would be also great if we could show which changes were requested. Add the diff in this Bug. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41287] New: Using locale sorting may have a negative impact on search speeds
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41287 Bug ID: 41287 Summary: Using locale sorting may have a negative impact on search speeds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 189898 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189898&action=e… Flame graph screenshot Doing some profiling, with high numbers of facets there is a significant amount time spent in sorting facets with Unicode Locale. This needs to be profiled against the previous sort, worth investigating -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 42734] New: autoMemberNumValue syspref has no UI â add it to patrons preferences with a caution note
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42734 Bug ID: 42734 Summary: autoMemberNumValue syspref has no UI â add it to patrons preferences with a caution note Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Bug 34000 introduced autoMemberNumValue as an internal monotonic counter to prevent cardnumber re-issuance. However there is currently no way for staff to view or correct this value if it becomes inflated â for example, if a book barcode is accidentally scanned when creating a patron and that patron is subsequently deleted or has their cardnumber corrected. This patch adds autoMemberNumValue to the Patrons system preferences page (near autoMemberNum) so that superlibrarians can correct a runaway counter without contacting vendor support. The entry includes a caution note explaining: - that the value is managed automatically and should not normally be changed - that Koha always generates from max(counter, live_db_max), so lowering the counter only has effect once the patron responsible for the inflated number has been deleted or had their cardnumber corrected - the risk of setting it too low (potential cardnumber re-issuance) Test plan: 1. Apply patch 2. Go to Administration > System preferences > Patrons 3. Confirm autoMemberNumValue is visible immediately below the autoMemberNum preference 4. Confirm the caution note is displayed 5. With autoMemberNum enabled, create a patron without specifying a cardnumber and confirm the generated number is consistent with the counter value 6. Adjust autoMemberNumValue to a lower number (after ensuring no active patron holds a cardnumber in that range), create another patron, and confirm the next auto-generated number reflects the corrected counter -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 42398] New: Form validation does not work when a dedicated validation handler is set and form has class validated
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42398 Bug ID: 42398 Summary: Form validation does not work when a dedicated validation handler is set and form has class validated Initiative type: --- Sponsorship --- status: 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: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When a form has a class="validated" and gets a dedicated validation handler like $("#add_additional_content").validate({ submitHandler: function(form){ ... } }); this dedicated handler gets overwritten by staff-global.js as there each form[class=validated] is called with $(this).validate(); So each form with a dedicated validation handler must not have a class "validated". So far this appears to: - koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt <form method="get" id="modal-item-group-create-form" class="validated"> - koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt <form method="get" id="modal-item-group-edit-form" class="validated"> - koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt <form method="get" id="modal-item-group-set-form" class="validated"> - koha-tmpl/intranet-tmpl/prog/en/modules/tools/additional-contents.tt <form id="add_additional_content" method="post" action="/cgi-bin/koha/tools/additional-contents.pl" class="validated"> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 41809] New: Waiting holds fulfilled by another copy should be marked for return to stacks
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Bug ID: 41809 Summary: Waiting holds fulfilled by another copy should be marked for return to stacks Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This may be related to bug 38650 The use case we have run into is: A patron has a hold waiting on the hold shelf. They check out a different copy on the same bib from the stacks and this copy fulfills the hold. The waiting hold does not appear on the holds with cancellations or holds waiting over X days reports. This causes confusion for our branch staff and items sitting on the hold shelf longer than they should be. Ideally these would move to the holds with cancellation requests report, but I'd be interested if others feel differently. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23