https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43025 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Hi Nick, Thanks for digging into this and leaving a patch — genuinely useful QA, and I agree with the underlying idea (using repair_marcxml() for a proper per-fault breakdown instead of the older record_strip_nonxml + raw exception dump on load). I didn't apply it as-is though, for a few reasons: - There's a typo in the template: nonxml_stripped.char_od should be char_ord — that's the actual key _find_nonxml_chars() returns, so that field would have rendered blank. - repair_marcxml() returns an empty list when it can't identify a known-recoverable fault (i.e. the record is broken in some way other than stray non-XML characters or empty datafields). In that case the patch left $record undef with nothing downstream to catch it. I kept the original record_strip_nonxml fallback for that case, so a genuinely unrecoverable record still degrades gracefully instead of crashing the page. - The patch touched both cataloguing/addbiblio.pl (this bug) and catalogue/detail.pl (bug 43026's territory), so I split it across the two bugs it actually belongs to. I've reworked and applied both halves with those fixes, and credited your patch in the commit messages (Based-on-patch-by:). On your broader point — moving the error-recording itself into a shared routine so a plain load/view also persists to biblio_metadata_errors, not just a save — I agree that's worth doing, but think it deserves its own bug: it means a GET request writing to the DB (locking/concurrency implications on a hot page) and touching Koha::Biblio::Metadata itself rather than any of these follow-up bugs. Happy to file that separately, or if you'd rather pick it up yourself, go for it. Will get updated patches up on this bug and 43026 shortly for another look whenever you have time. Thanks again, -- You are receiving this mail because: You are watching all bug changes.