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

[Bug 43946] New: Classes picked for translation in XSLT
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43946 Bug ID: 43946 Summary: Classes picked for translation in XSLT Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Templates Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- in koha-tmpl/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACDetail.xsl `<xsl:attribute name="class">subject</xsl:attribute>` "subject" is picked for translation. The class for the `a` element is then translated and OPACPopupAuthorsSearch is broken. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43949] New: Holds table: show the patron's library for patrons the user cannot see
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43949 Bug ID: 43949 Summary: Holds table: show the patron's library for patrons the user cannot see Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- On a record's holds list (reserve/request.pl, holds.js load_patron_holds_table) the patron column is built from the /api/v1/holds response with embed=patron. When the logged in staff user is not allowed to see the patron (IndependentBranches, or library groups with "Hide patron info" and no view_borrower_infos_from_any_libraries permission), Koha::Object->to_api redacts the embedded patron: every field is set to undef except those in Koha::Patron->unredact_list, which is only branchcode (exposed as library_id). The redacted patron is therefore a non-null object, so the fallback added in bug 42915 (row.patron == null, showing "A patron from library X") never runs. Instead $patron_to_html (patron-format.js) gets a patron with no name, and because patron.library is not embedded it can only ever print the generic "A patron from another library", even though patron-format.js already supports "A patron from <library name>" when patron.library is present. Proposed fix: - Allow patron.library in the x-koha-embed enum of GET /holds (api/v1/swagger/paths/holds.yaml) - Request the patron.library embed from the holds table in holds.js - $patron_to_html then shows "A patron from <patron's home library>" for patrons the user cannot see The library name is not sensitive: library_id is already exposed for redacted patrons, and the list of libraries is public. The existing row.patron == null fallback in holds.js shows the pickup library, which is not the patron's library, so it is left as a last resort only. Test plan: 1. Set up two libraries, A and B, and a staff user at library A without the view_borrower_infos_from_any_libraries permission (or enable IndependentBranches) 2. Place a hold for a patron whose home library is B on a record 3. As the staff user at A, open the record's holds page (reserve/request.pl) 4. Before the patch: the patron cell reads "A patron from another library" 5. After the patch: it reads "A patron from <name of library B>" 6. As a superlibrarian, confirm patrons are shown by name as before 7. prove t/db_dependent/api/v1/holds.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43953] New: Holds API PATCH ignores AllowHoldDateInFuture when changing hold_date
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43953 Bug ID: 43953 Summary: Holds API PATCH ignores AllowHoldDateInFuture when changing hold_date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Creating a hold through the REST API refuses a hold_date when the AllowHoldDateInFuture system preference is off (Koha::REST::V1::Holds::add returns 400 "Hold date in future not allowed"). Changing the hold date of an existing hold through PATCH /api/v1/holds/{hold_id} (Koha::REST::V1::Holds::edit) has no such check: hold_date is passed straight to C4::Reserves::ModReserve. Since Bug 23269 the staff holds table (reserve/request.pl) saves each field as soon as it is changed using this PATCH endpoint. The hold date input is only shown when AllowHoldDateInFuture is on, so the interface hides the field, but nothing stops the same request being made by a script or another API client when the preference is off. Expected: PATCH should apply the same rule as POST and reject a changed hold_date with a 400 when AllowHoldDateInFuture is off. A hold_date that is unchanged (the client sends back the existing value) should still be accepted. To test: 1. Set AllowHoldDateInFuture to "Don't allow". 2. Find an existing hold, then send PATCH /api/v1/holds/<id> with {"hold_date": "2030-01-01"} (a user with the place_holds permission). 3. Note the request succeeds and the hold's reservedate changes. 4. Compare with POST /api/v1/holds with a hold_date, which returns 400. Expected after the fix: step 3 returns 400 and the hold is unchanged. Related: Bug 23269. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3