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

[Bug 24403] New: [OMNIBUS] OpacHiddenItems should hide items everywhere in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24403 Bug ID: 24403 Summary: [OMNIBUS] OpacHiddenItems should hide items everywhere in the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 50

[Bug 14007] Values listed in OpacHiddenItems should not appear in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 Aude Charillon <aude.charillon(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aude.charillon(a)openfifth.co | |.uk --- Comment #41 from Aude Charillon <aude.charillon(a)openfifth.co.uk> --- (In reply to Caroline Cyr La Rose from comment #39) > I've had a client on 25.05 report that they're seeing the facet values (authors, collections, languages, etc.) for withdrawn items which are hidden through OpacHiddenItems. This is using ES. I am seeing the same. I have logged bug 43341. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43217] New: Allow MARC mod templates to edit existing items in batch record modification
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43217 Bug ID: 43217 Summary: Allow MARC mod templates to edit existing items in batch record modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- See also bug 43216, which documents the current limitation this bug proposes to actually fix: batch record modification with a MARC modification template can only ever create brand new items on the target biblios (bug 26869), never edit fields on items that already exist, even though the template engine already has the primitives needed to do so. Background C4::MarcModificationTemplates already supports applying an action (add_field, update_field, copy_field, move_field, delete_field) to a single matching field occurrence or to every occurrence of a repeatable field (the field_number = 0 "all" mode, resolved in ModifyRecordWithTemplate and carried out in Koha::SimpleMARC). For update_field specifically, Koha::SimpleMARC::_update_subfield already does exactly what bulk item editing needs: for each matching field occurrence it sets the subfield if present or adds it if absent, per field, driven by the same conditional matching (field/subfield/value/regex) already available to any template rule. That primitive is inert for items today for two reasons: - Koha::BackgroundJob::BatchUpdateBiblio fetches the record with Koha::Biblio::Metadata->record and no embed_items, so a biblio's existing 952/995 fields are never present in the record the template runs against. There is nothing there for update_field's "all occurrences" mode to match. - Even if the fields were present, the only post-template handling of 952/995 data is can_add_item_from_marc_record + C4::Items::AddItemFromMarc, i.e. "treat this as a new item and validate mandatory subfields." There is no path that recognizes a field as belonging to an already-existing item and updates just the touched Koha::Item column(s) instead. Koha already has the reconciliation half of this elsewhere: C4::Items::ModItemFromMarc (used by cataloguing/additem.pl when the full-record item edit form is submitted) updates an existing item from a MARC field carrying its items.itemnumber subfield (per the framework's items.itemnumber mapping, GetMarcFromKohaField), as opposed to C4::Items::AddItemFromMarc for a field with no itemnumber. Batch record modification does not currently use this function at all. Proposed design 1. When a template applied by batch record modification contains a 952/995 action, fetch the biblio record with embed_items so existing items are represented as real 952/995 fields (each carrying the framework's items.itemnumber subfield). Keep the current bare-record fetch for templates that do not touch the item tag, to avoid the extra overhead of embedding items on every run. 2. After the template runs, split the resulting 952/995 fields by whether they carry an itemnumber: - Fields with an itemnumber are existing items. Route them through C4::Items::ModItemFromMarc, updating only the columns the template actually touched. No mandatory-subfield validation is needed since the item already exists and was validated at creation time. - Fields with no itemnumber are new items, unchanged from today: C4::Items::AddItemFromMarc, with the existing can_add_item_from_marc_record mandatory-field check (homebranch, holdingbranch, itemtype). 3. Report per-item results (updated / created / rejected for missing mandatory fields) alongside the existing per-biblio success/error messages, so a biblio can partially succeed (record modified, most items updated, one new item rejected). Open questions to resolve during implementation, not before filing - What should a delete_field action targeting an existing item's 952 mean. Recommend it never deletes the Koha::Item row itself (batch item deletion already exists for that); either restrict delete_field's effect on item-tagged fields to individual subfields, or explicitly disallow/ignore whole-field deletes on fields carrying an itemnumber. - Confirming which fields count as "new" vs "existing" must rely solely on presence of the itemnumber subfield after the template runs, not on which action produced the field, since add_field, copy_field and move_field can all interact with the item tag. - Permission parity: batch record modification currently gates on catalogue edit permissions; bulk-editing arbitrary item columns should probably also require the item-edit subpermission that manual item editing requires. - Preview (svc/records/preview) should be updated in step with this so it reflects the same embed_items + split logic, otherwise the preview/execution mismatch described in bug 43216 will simply move to a new form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 carthur(a)slolibrary.org <carthur(a)slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur(a)slolibrary.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|koha-bugs(a)lists.koha-commun |testopia(a)bugs.koha-communit |ity.org |y.org -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 37974] New: Notices should list the available objects
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37974 Bug ID: 37974 Summary: Notices should list the available objects Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When editing a notice in the staff interface there is no way to know which objects are available to the template without reading the code. We should list the available objects to make writing notices easier -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 6892] If a URL has been entered without http://, it isn't correctly linked
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|koha-bugs(a)lists.koha-commun |paul.derscheid(a)lmscloud.de |ity.org | CC| |lisette(a)bywatersolutions.co | |m -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 43334] New: Implement OIDC Third-Party Initiated Login endpoint
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43334 Bug ID: 43334 Summary: Implement OIDC Third-Party Initiated Login endpoint Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Depends on: 42719 Target Milestone: --- Bug 42719 fixes the immediate 500 crash when an IdP initiates login without an existing session. However, the current approach silently creates a session and proceeds, which is susceptible to login CSRF (an attacker could craft a link that initiates login on behalf of the user). The OIDC spec defines a proper Third-Party Initiated Login flow: https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLo… Proposed implementation: 1. New endpoint: GET /api/v1/public/oauth/initiate-login Parameters (per spec): - iss (required): issuer identifier, must match a configured provider - login_hint (optional): hint about which user to authenticate - target_link_uri (optional): where to redirect after login 2. The endpoint: - Validates iss against configured OAuth providers in koha-conf.xml - Returns 400 if iss does not match any known provider - Renders a confirmation page: 'Provider X is requesting login. Proceed?' - On confirmation, redirects to the existing /api/v1/public/oauth/login/{provider}/{interface} flow 3. This defeats login CSRF because: - User interaction is required before the OAuth dance begins - The session and CSRF state are only created after user consent The existing Mojolicious::Plugin::OAuth2 flow remains unchanged. This endpoint sits in front of it, resolving iss to a provider name and gating on user confirmation. The session-creation logic from bug 42719 remains useful: after user confirms, the login endpoint may still need to create a session if none exists. Libraries using Okta (or similar IdPs) would configure the initiate_login_uri in their IdP app settings to point to this endpoint. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42719 [Bug 42719] OAuth/OIDC login crashes with 500 when no CGISESSID cookie exists (IdP-initiated flow) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39884] New: NOTIFY_MANAGER notice only sends when editing manager from an individual suggestion
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39884 Bug ID: 39884 Summary: NOTIFY_MANAGER notice only sends when editing manager from an individual suggestion Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org You can notify a manager with the NOTIFY_MANAGER, when they become the manager of a given suggestion. This only works when editing an individual suggestion where you can check the 'Notify manager' checkbox. Staff can also update the suggestion manager from the main suggestions page, but when you do so there is no option to notify the manager. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31011] New: Make hold reminders respect patron's language
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31011 Bug ID: 31011 Summary: Make hold reminders respect patron's language Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When running misc/cronjobs/holds/holds_reminder.pl it looks like borrowers.lang is not respected. The only code I can see that relates to language is this: # FIXME What if we don't want to default if the translated template does not exist? my $template_exists = Koha::Notice::Templates->find_effective_template( { module => 'reserves', code => $lettercode, branchcode => $branchcode, lang => 'default', } ); As far as I can see, the "default" template is always used? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4