Bug 38406 - Item fields should not be stored in the MARCXML in biblio_metadata
Summary: Item fields should not be stored in the MARCXML in biblio_metadata
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 31224 29697
Blocks:
  Show dependency tree / graph
 
Reported: 2024-11-07 23:55 UTC by Tomás Cohen Arazi (tcohen)
Modified: 2024-11-08 08:04 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tomás Cohen Arazi (tcohen) 2024-11-07 23:55:44 UTC 
After the inclusion of bug 31224, it become clear that Koha is allowing the storage of MARC field 952 in the `biblio_metadatas.metadata` column. I didn't spot it when reviewing bug 29697.

To check this, look at Koha::Biblio::Metadata:226~230. In that place, code was added for removing it when retrieving from the DB, so legacy code could be easily ported into using this new code in the Koha::* namespace.

Now that we implemented a -somehow- more clear approach, it got highlighted that we should deal with that.

In my opinion, we should enforce either rejection, or removal+alert in AddBiblio and ModBiblio instead of the current approach of silently removing them after we allowed to store them. Or maybe we should do both.
Comment 1 David Cook 2024-11-08 00:24:07 UTC 
Surely the inclusion of 952 in biblio_metadata.metadata is an accident? I reckon silent removal is all right.

I suppose you never know when someone has sideloaded MARCXML into biblio_metadata.metadata. Surely that would be the most likely scenario of someone adding 952 in the metadata?