https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41931 Depends on| |39545 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39545 [Bug 39545] Construct more complete 773 content when creating a child record https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41931 [Bug 41931] While creating EasyAnalytics empty subfields are created -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |RESOLVED Resolution|--- |DUPLICATE CC| |martin.renvoize@openfifth.c | |o.uk --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- 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. *** This bug has been marked as a duplicate of bug 22439 *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43031 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- 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.