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@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@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.