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

[Bug 39623] New: "make install" re-runs "make" process unnecessarily
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39623 Bug ID: 39623 Summary: "make install" re-runs "make" process unnecessarily 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Have you ever noticed that "make install" seems to do all the same things as "make" plus install? This became even more obvious after bug 32609. And it got me thinking... surely there has to be a better way and it looks like there is. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 39570] New: Add item form includes itemnumber while adding a new item
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39570 Bug ID: 39570 Summary: Add item form includes itemnumber while adding a new item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 36192 Luckily, submitting an itemnumber that's either empty or bogus while adding a new item doesn't actually do anything since the code for op == 'cud-additem' doesn't ever look at itemnumber, but it's confusing and scary looking in the case where you add an item after editing an existing item. The template looks at [% IF op != 'add_item' %] to decide to add the <input type="hidden" name="itemnumber" value="[% itemnumber | html %]" />. Prior to the bug 36192 CSRF protection, that worked, but now the op for adding an item is cud-additem, so it's always true and we always submit an itemnumber. And without bug 27625 it would have been less scary looking, since before then while processing the editing of an item we cleared $itemnumber after we were done using it, so it at least would have been value="". Now, if you edit an existing item and then add another, the form you submit to add an item includes the itemnumber of the item you previously edited. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39663] New: Patrons entry in additional fields has wrong header
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39663 Bug ID: 39663 Summary: Patrons entry in additional fields has wrong header Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com Depends on: 38662 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38662 [Bug 38662] Additional fields admin page hard to read -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 39029] New: When a basket contains an order transferred from another basket some info is incorrect
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39029 Bug ID: 39029 Summary: When a basket contains an order transferred from another basket some info is incorrect Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a basket has orders transferred from another basket we do this: [% IF (books_loo.transferred_from) %] [% basket = books_loo.transferred_from.basket %] [% bookseller = books_loo.transferred_from.bookseller %] [% timestamp = books_loo.transferred_from.timestamp %] But later when building the 'Add to basket' modal - we have this: <div id="addtoBasket" class="modal" tabindex="-1" role="dialog" aria-labelledby="addtoBasketLabel" aria-hidden="true" data-basketno="[% basket.basketname | html %]"> We are using the wrong basket now to pull info -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39020] New: Search filters can't parse query in some instances
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39020 Bug ID: 39020 Summary: Search filters can't parse query in some instances Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: Turn on the SavedSearchFilters system preference Go to advanced search, select a number of item types and search Save the search Enter a search term (such as power) select the filter. Observe the following message: Error: Unable to understand your search query, please rephrase and try again. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 25015] New: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25015 Bug ID: 25015 Summary: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If a staff has the permission has only the permission in Cataloging to "Edit Items" currently, they can't edit items attached to a Fast Add bib. What should the change be? Does a staff member need to have Fast Cataloging and Edit Items to be able to Edit Items attached to a Fast Added Bib? And if that is the case, the bug lies with the fact the staff member doesn't know that this bib is a Fast Add bib- the Edit option should not be visible to staff that only have "edit items" and not "Fast Cataloging" Or Is it a library's understanding that the permission "Edit Items" allows All Items can be edited even the items attached to Fast Add Biblios? And if that is the case, then the change lies with how the permissions are coded in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 39597] New: When cancelling multiple holds on a bib record cancel_hold_alert has very low contrast
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39597 Bug ID: 39597 Summary: When cancelling multiple holds on a bib record cancel_hold_alert has very low contrast Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org 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 Created attachment 180747 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180747&action=e… screnshot To recreate: - Go to a bib record and place multiple holds on it - Select multiple holds and click 'Cancel selected (4)' - The Alert says 'This action will cancel 4 hold(s).' - Note that the contrast on the number of holds is very low -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 25947] New: Improve locked account message
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25947 Bug ID: 25947 Summary: Improve locked account message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 106643 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106643&action=e… Warning messages in the patron details When using FailedLoginAttempts, a patron's account is blocked after X many failed login attempts on the OPAC. When that happens, a message 'Account has been locked.' appears on the patron account details page. This message does not indicate why or how it was blocked. I suggest we change it to 'Account has been locked due to too many failed login attempts'. Furthermore, the font is dark red whereas the font for other warnings (such as wrong category or unpaid fines) is bright red and bold. To test: 1. Change FailedLoginAttempts to a small number, like 2 2. Go to a patron's account and copy their username (while you're there, change the password and add some fines, too) 3. In the OPAC, try to log in with the username and a wrong password several times 4. Go back to the patron's account in the staff interface 5. Note that there is no indication as to why the patron's account is locked and that the font color and weight does not match the other warnings. Also, there is no button to change the password next to the warning. When a patron has unpaid fines or is in the wrong category, there is a button to either pay/writeoff the fines or change the category next to the warning. I would add a button that says 'Change password' next to the locked account warning. This might be outside the scope of this bug, but I think it would improve usability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 39754] New: Cannot scroll EANs when clicking 'Create EDIFACT order' in a basket
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39754 Bug ID: 39754 Summary: Cannot scroll EANs when clicking 'Create EDIFACT order' in a basket Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Enable EDI: http://localhost:8081/cgi-bin/koha/admin/preferences.pl?tab=acquisitions#ac… 2 - Add an edi account: http://localhost:8081/cgi-bin/koha/admin/edi_accounts.pl 3 - Add a large number (30-50) of EAN accounts: http://localhost:8081/cgi-bin/koha/admin/edi_ean_accounts.pl I did this by spamming SQL: INSERT INTO edifact_ean (description,ean) VALUES (CONCAT("Test ",rand(400)),rand(1000)); 4 - Find a basket for the vendor you attached the EDI account to 5 - Add an order 6 - Click 'Create EDIFACT order' in the basket 7 - You get a dropdown that cannot be scrolled -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 35885] New: ERM vendor sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35885 Bug ID: 35885 Summary: ERM vendor sort order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: Laura.escamilla(a)bywatersolutions.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Currently the vendor drop-down list shows the vendors in the order that they were added to the Acquisitions module. It would be ideal if the vendors were sorted in alphabetical order so that libraries could easily locate their selection. -- You are receiving this mail because: You are watching all bug changes.

1 19