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

[Bug 42275] New: Cannot add tags via OPAC
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42275 Bug ID: 42275 Summary: Cannot add tags via OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org It looks like bug 41582 broke adding tags via OPAC but it's an easy fix. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42276] New: CookieConsentedJS is loaded using unsafe method incompatible with CSP
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42276 Bug ID: 42276 Summary: CookieConsentedJS is loaded using unsafe method incompatible with CSP 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In cookieconsent.js the Javascript from CookieConsentedJS is loaded and run using the following lines: const code = atob($(this).data("consent-code")); const func = Function(code); func(); While Function isn't as bad as eval(), for Content-Security-Policy it blocks it in the same way. That is, it requires unsafe-eval to be set in order to use it. Obviously, we want to avoid that when using CSP (bug 38365). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39121 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38969] Reflected XSS vulnerability in tags
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38969 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42254 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42274] New: opac-tags.pl should return JSON instead of JS script
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42274 Bug ID: 42274 Summary: opac-tags.pl should return JSON instead of JS script Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org koha-tmpl/opac-tmpl/bootstrap/js/tags.js makes AJAX calls to ./opac/opac-tags.pl which returns Javascript scripts rather than JSON. The crazy part is that it's mostly just returning a JSON object anyway. There are some gotchas where it returns a JS object with embedded KOHA.Tags.tag_message() functions, but I'm sure we can fix that. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42274 -- You are receiving this mail because: You are watching all bug changes.

1 0

[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