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

[Bug 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 --- Comment #88 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Moving those to their own bug as we're past release now. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 --- Comment #87 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 199759 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199759&action=e… Bug 34000: (follow-up) Clarify that autoMemberNumValue only takes effect once the inflating patron is gone The caution note now explains that Koha always generates from max(counter, live_db_max), so lowering the counter has no effect while a patron with the inflated cardnumber is still active. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 --- Comment #86 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 199758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199758&action=e… Bug 34000: (follow-up) Expose autoMemberNumValue in the patrons sysprefs UI Adds a patrons.pref entry so superlibrarians can view and correct the autoMemberNumValue counter through the standard System Preferences admin interface, without needing vendor support. The entry sits immediately after autoMemberNum and carries a strong caution note explaining the risk of setting the counter too low. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 Kathleen L. <klehman(a)faylib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |klehman(a)faylib.org --- Comment #85 from Kathleen L. <klehman(a)faylib.org> --- (In reply to Katrin Fischer from comment #84) > Just noting this creates an issue for libraries that expect numbers of a > certain length and form to be generated. If there has ever been a deleted > borrower with a long number, for example for testing, it will now be used as > the base for creating new numbers with no way for the library to fix these. > > I think something like adding a pre-fix might have been less disruptive. We experienced this issue this morning. By Water support was very responsive and got our base number reset but I would prefer a way to fix this issue myself in system preferences in the future. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42729] New: "Remove from bundle" is shown even when the bundle is checked-out
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42729 Bug ID: 42729 Summary: "Remove from bundle" is shown even when the bundle is checked-out Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Create a bundle and attach some items to it. 1) Don't check it out. Check in one of the items - you get this message "Item belongs in bundle This item belongs to a bundle: Title- 2776532149618" and a button "Remove from bundle" Click on the button and the item is removed from the bundle 2) Check out the bundle Check in one of the items - you get this message "Item belongs in bundle This item belongs to a bundle: Title- 2776532149618" and a button "Remove from bundle" Click on the button and nothing happens I can see two possible solutions for this a) make the button work even when the bundle is checked out b) don't show the button when the bundle is checked out I think the last option is best in line with that fact that you can't add/delete items in a bundle when it's checked out -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42728] New: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42728 Bug ID: 42728 Summary: Cronjob cleanup_database.pl is broken with ChildNeedsGuarantor Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Steps to reproduce. 1 - Go to /cgi-bin/koha/members/moremember.pl?borrowernumber=37 and make sure it is a Kid without guarantor. 2 - Enable ChildNeedsGuarantor 3 - Run ./misc/cronjobs/cleanup_database.pl -v --confirm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 38630] New: Make the REST API respect KohaOpacLanguage cookie
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38630 Bug ID: 38630 Summary: Make the REST API respect KohaOpacLanguage cookie Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 32551 Continuation of bug 32551 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32551 [Bug 32551] API requests don't carry language related information -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 39851] New: Languages for REST API is returned in random order
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39851 Bug ID: 39851 Summary: Languages for REST API is returned in random order Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com At least for the tests: Run t/db_dependent/api/v1/ill_requests.t several times. If you have several languages installed it will fail randomly: # $got->[0]{_strings}{status}{str} = 'Solicitado' # $expected->[0]{_strings}{status}{str} = 'Requested' or # $got->[0]{_strings}{status}{str} = 'Angefordert' # $expected->[0]{_strings}{status}{str} = 'Requested' This is because getlanguage hit the else: if ( $interface eq 'opac' || $interface eq 'intranet' ) { [...] } else { @languages = map { $_->{rfc4646_subtag} } @{ getTranslatedLanguages( $interface, $theme ) }; $language = Koha::Language->get_requested_language(); } and getTranslatedLanguages returns the languages in a random order. So there might be several problems highlighted here. You can easily recreate the problem with: use C4::Languages; use C4::Context; C4::Context->interface('api'); say C4::Languages::getlanguage(); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 39001] New: Language list is displayed in wrong order (getLanguages doesn't sort it, the order is UB)
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39001 Bug ID: 39001 Summary: Language list is displayed in wrong order (getLanguages doesn't sort it, the order is UB) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org Caught by unit tests added in Bug 38646, but it's not a regression of that bug. It seems that the list of languages from getLanguages is not ordered in any way, instead it relies on the implementation detail of the database server in terms of the order it returns things in. Indeed even before that bug was merged, in Koha 24.11 and 24.05, one can observe in OPAC -> Advanced search -> Language, that the order of languages is indeed a bit wrong (for example: amh, grc, ara -- Old Greek (grk) has nothing starting with "a", so it has no business being this high in the list). The solution in principle is simple, just order the returned language list (TBD what to order it by: by language code, by English name, by effective final display name????). It's also TBD whether getLanguages should sort it itself, or whether places that display languages, such as `/cgi-bin/koha/opac-search.pl`, should actually be doing the ordering in preferred fashion. In any case, the tests at t/db_dependent/Languages.t fail due to wrong order after some MariaDB update, so current order is undefined behavior. Also if we select to change the behavior of getLanguages, then it'll be trickier to backport it, since dependent Bug 38646 is enhancement due to slight change of behavior. But the backporter could easily adjust the SQL query there to make the lines "THEN CONCAT(" be selected with removing the conditional, so that the language list is always appended in parentheses (old behavior). -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 10198] Add the ability to import and export authorized values
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '26

01 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10198 Laurence Rault <laurence.rault(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |laurence.rault(a)biblibre.com --- Comment #8 from Laurence Rault <laurence.rault(a)biblibre.com> --- Specification proposal : Export authorised values - From the admin/authorized_values.pl page, there is already an export button, which only exports categories. - In the categories table: * Have an Export button that would allow exporting all values from all lists. * Have in the last column an Action button with an Export action to export only the values for the corresponding category (Similar to what is done for exporting/importing cataloguing frameworks.) Import authorised values : >From this same page, have a global import button to be able to import values from a file containing data for several lists. * If the file contains an existing category code, import OK. * If the file contains an undefined category code, display an alert. For each category, in the Action button, add an Import action. If the file's category code doesn't match, display an alert. Import action: it should be possible to choose : * Replace list: delete all existing values for the list and replace them with those from the file. * Complete list: Adds missing values only (authorised_value field comparison). Display the number of imported values for each category. Export and import actions for a given list will also be accessible on the list detail page: XXX admin/authorised_values.pl?searchfield=XXX -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0