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

[Bug 33254] New: 2FA - Trust Current Device
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33254 Bug ID: 33254 Summary: 2FA - Trust Current Device Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.sam(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 20476 I've been testing the 2FA Koha module, I noticed there's currently no option to "trust current device" something that most MFA modules include, so a user can mark a local device to be excluded from the MFA check for an amount of time (typically a month or so). Not very essential, but would be a nice quality of life feature for users with dedicated machines. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20476 [Bug 20476] Two factor authentication for the staff client - omnibus -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42248] New: Confusing JS code when testing length
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42248 Bug ID: 42248 Summary: Confusing JS code when testing length Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org if (!my_string.length > 0) is confusing and could be better written: if (my_string.length === 0) Found 4 occurrences: koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc: if (!row.cover_image_ids.length > 0) { koha-tmpl/intranet-tmpl/prog/en/modules/serials/routing.tt: if(!borrowernumbers.length > 0) { koha-tmpl/intranet-tmpl/prog/en/modules/tools/additional-contents.tt: if ( ! $("#title_default").val().length > 0 ) { koha-tmpl/intranet-tmpl/prog/en/modules/tools/additional-contents.tt: if ( ! content.length > 0 ) { ``` let content = "" undefined content.length 0 !content.length true !content.length>0 true 7m ago content = "foo" "foo" content.length 3 !content.length false !content.length>0 false ``` so... it works, but I am pretty sure it is not interpreted like how the author thought it would be (and I might be the author). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28680] New: Staff without edit_borrower permission still see patron information
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28680 Bug ID: 28680 Summary: Staff without edit_borrower permission still see patron information Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The permission edit_borrowers specifies: Add, modify and view patron information. However, when that permission is not enabled, staff can view patron information in a number of places, including holds queue, circulation.pl, waitingreserves.pl, and pendingreserves.pl. In the Holds Queue staff can see patron name and other info for patrons at their library, but patrons from other libraries show "patron from central branch" etc. When looking at a bib record, if an item is checked out, only the borrower number is displayed. This should be consistent, where staff without that permission only see a borrower number and nothing else. To replicate, create a staff member with only permissions catalogue ( to log in) and circulate_remaining_permissions. Check out to a patron, see the holds queue, etc and see that the patron information is displayed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 37144] New: Add a subpermission for hiding patron contact information
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37144 Bug ID: 37144 Summary: Add a subpermission for hiding patron contact information Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, Koha lacks a subpermission feature that allows libraries, especially those in correctional facilities utilizing inmate volunteers, to hide patron contact information (e.g., addresses) from certain users like volunteers. This privacy gap poses a significant risk, potentially exposing sensitive inmate data to unauthorized personnel. Implementing a subpermission feature would ensure that only authorized staff can access such sensitive information, addressing critical privacy concerns within these specialized library environments. -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 42270] New: Log the date a framework changed
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42270 Bug ID: 42270 Summary: Log the date a framework changed Initiative type: --- Sponsorship --- status: 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: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We would like to be able to find out when a record was changed from FA to Default. In our workflow, we overlay brief records with full ones and change the framework during import. This overlay gets logged as action "Modify" but there's no indication of a framework change, so we can't differentiate an overlay modification from any other type of modification that might happen. Ideally, we would be able to find the timestamp of when the framework was changed and by which user, but having something in the Info that indicates what the frameworkcode is/was would be useful. A solution for bug 24843 might be related. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35645] New: Modification Log only show changed values
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35645 Bug ID: 35645 Summary: Modification Log only show changed values Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: angela.berrett(a)familysearch.org QA Contact: testopia(a)bugs.koha-community.org CC: angela.berrett(a)familysearch.org, gmcharlt(a)gmail.com Created attachment 160266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160266&action=e… OLIB cataloging system item modification log The modification logs for a bib record puts all bibliographic and item information in a single text box when an edit occurs. For easier reading it would be nice to only show the fields/information that were modified. A previous catalog our library used would show a single line per change when an item was modified. It would show the date | person who made the change | old value | new value. This kept an accurate history and made reviewing the changes easy to read. As there is a single modification page for all items on a bib record the object column identifying which item was changed would need to be included. A similar table could be created for bib record modifications identifying the MARC field that was changed either in the Object column or in its own column, along with the old and new values. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42259] New: Accessing deleted ILL is 500 error & not 404
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42259 Bug ID: 42259 Summary: Accessing deleted ILL is 500 error & not 404 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com I noticed this because I saw a "request to delete ILL request" email and clicked the link to view the request, but another staff member had already deleted it. You receive a 500 server error due to a missing template: Template process failed: file error - : not found at /kohadevbox/koha/C4/Templates.pm line 146 in C4::Templates::output at /kohadevbox/koha/C4/Templates.pm line 146 in C4::Output::output_and_exit at /kohadevbox/koha/C4/Output.pm line 384 in (eval) at /kohadevbox/koha/ill/ill-requests.pl line 127 ... This is the `output_and_exit()` call passing an 'unknown_ill_request' error after checking that the request doesn't exist. I see a `[% CASE 'unknown_ill_request' %]` line in koha-tmpl/intranet-tmpl/prog/en/includes/blocking_errors.inc so it seems like Koha should be set up to handle this error gracefully. Perhaps an issue with the ill-requests.tt template. Ideally, the response would both say "ILL request not found" and be a 404. I looked at how other templates handle this but couldn't quite figure it out. I see that some missing objects (biblio, patron) return HTTP 200 which seems semantically incorrect. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41200] New: Refocus certain elements on hide or remove
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41200 Bug ID: 41200 Summary: Refocus certain elements on hide or remove 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: jake.deery(a)openfifth.co.uk 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 On the OPAC, there are a few instances of the browser's focus caret disappearing when an element is removed. This causes problems for people with screen readers, as their reader doesn't know what element should come next in the page's flow any more. I shall propose a set of patches to resolve this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 39328] New: Buttons should maintain focus after toggling
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39328 Bug ID: 39328 Summary: Buttons should maintain focus after toggling Change sponsored?: --- Product: Koha Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, oleonard(a)myacpl.org A customer's accessibility report has highlighted to us a malfunction on some of our button focus behaviours. To paraphrase the auditor: "When it is activated on highlight / unhighlight, the focus moves to a random location on the page, such as to the "1" pagination button. That is, as opposed to staying on the activated link. Witnessed on iOS. Also witnessed on OPAC details, via iOS, with the "Add to cart" link. When activated, the focus moves to a random location on the page, such as to the decorative folder icon preceding the link's label. That is, as opposed to staying on the activated link, which now has an updated label of "In your cart". Again on iOS, with the "highlight/unhighlight" links on OPAC details. When activated, the focus moves to a random location on the page, such as to the "Print" link. That is, as opposed to staying on the activated button. Additionally, with the sortable header column buttons, on search history, on iOS. When activated, the focus moves to a random location on the page, such as to the "Enter search here" input field. That is, as opposed to staying on the activated button. Lastly, on iOS, on the OPAC details page, with the "+/-" buttons in the holdings table. When activated, the focus moves to a random location on the page, such as to the first table header. That is, as opposed to staying on the activated button." I'm not sure how much of these issues can be attributed to us, versus iOS/Safari just being... iOS/Safari. I thought I would log here, anyway. :-) Jake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42268] New: Add ability to update preferred name conditionally.
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42268 Bug ID: 42268 Summary: Add ability to update preferred name conditionally. Initiative type: --- Sponsorship --- status: 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: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, when a patron is created, if the first name field is filled in and the preferred name is left blank, the preferred name field populates with the first name. Let's say the library makes a change to the first name field. If the preferred name field is filled in, changing the first name will not change the preferred name. Normally, this is ideal. You wouldn't want the preferred name field to update every time the first name field is altered BUT in some cases libraries want to make changes to the first name field AND have that change also update the preferred name field IF the preferred name field has never been manually updated/if it has only ever been automatically populated because it was left blank. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2