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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
