https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031
--- Comment #3 from Martin Renvoize (ashimema) <[email protected]> --- Thanks for the report and the patch, Nick - you're right that this is the same underlying issue as bug 22439 (PrepHostMarcField duplicating and lagging behind generate_marc_host_field, including using 260 instead of 264). I'd like to propose closing this one as a duplicate of 22439 rather than reviewing the two in parallel: - 22439 already removes PrepHostMarcField and routes addbiblio.pl and linkitem.pl through generate_marc_host_field, which fixes the 260/264 difference as a side effect of the same consolidation this patch does. - It also covers a related gap Arthur found while testing: the item-bundles REST endpoint (Koha::REST::V1::Items::add_to_bundle) was calling link_marc_host without ever passing the item, so bundled items got none of the EasyAnalyticalRecords subfields either. That's fixed there too. - One thing this patch does that 22439 doesn't: it unifies the "Create analytics" (hostbiblionumber) and "New child record" (parentbiblionumber) code paths in addbiblio.pl into one block. That's a nice simplification and I've folded an equivalent version into 22439 (keeping hostbiblionumber as a request-param alias for parentbiblionumber, so no template/URL changes are needed and old links/bookmarks keep working). One thing to flag on this patch as it stands: the new '0'/'9' subfields are pushed unconditionally at the top of generate_marc_host_field, before the marcflavour branch, with no EasyAnalyticalRecords check. That means: - Every "New child record" (the plain, non-analytics path, only shown in the toolbar when EasyAnalyticalRecords is *off*) now gets a non-standard $0 (host biblionumber) in its 773/461 - previously that flow never added it. - For UNIMARC specifically, $0 ends up being pushed twice on the same 461 field: once unconditionally with the host biblionumber, and again further down in the existing "Control number (001)" block. Since MARC::Field->subfield('0') only returns the first match, the control number branch becomes silently unreachable. 22439 gates these subfields on `$item && EasyAnalyticalRecords` inside generate_marc_host_field itself, so the plain child-record/non-analytics path is untouched and MARC21-standard-only libraries don't get non-standard subfields injected. Given the recent discussion on 22439 about UseControlNumber vs EasyAnalyticalRecords, I think that gating is worth preserving here regardless of which bug ends up being the canonical one. Marking as a duplicate of 22439 unless there's an objection - the patch there has full test coverage and has already been through a couple of rounds of QA/signoff feedback. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
