https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35104

--- Comment #195 from Martin Renvoize (ashimema) 
<[email protected]> ---
Test plan
=========
Prerequisites:
- Bug 42512 applied (needed to edit records whose metadata cannot be fully
decoded).
- A record with MARCXML containing invalid/non-recoverable content. Two useful
variants:
  a) Non-XML characters: a control character embedded in a field value (this is
the original,
     "characters invalid in XML" scenario the bug targets).
  b) A structurally invalid field: a <datafield> element with no <subfield>
children at all,
     e.g. `<datafield tag="500" ind1=" " ind2=" "></datafield>`.
MARC::File::XML refuses to parse
     this ("Field NNN must have at least one subfield").
Legacy/externally-sourced records can
     contain this even though Koha's own live code cannot produce it directly.
  You can inject either into an existing record's stored metadata via the DB to
set up test data:
     UPDATE biblio_metadata SET metadata = REPLACE(metadata, '</record>',
       '<datafield tag="500" ind1=" " ind2=" "></datafield></record>')
     WHERE biblionumber = <some biblionumber>;
1) Single record view/edit - non-XML characters (existing behaviour)
   - Save a record containing an invalid-for-XML character in a field.
   - Confirm the character is stripped automatically, an error is recorded and
shown on the
     detail/edit pages with a quick-link to the affected field, and a "Mark
resolved" button is
     available to dismiss it once corrected.
2) Single record view/edit - empty datafield (new recovery)
   - Corrupt biblio_metadata for an existing record with an empty <datafield>
as above.
   - View the record's detail page: a "Record was automatically modified"
warning is shown,
     listing the field that was removed (e.g. "500: field removed, it had no
subfields").
   - Edit the record (cataloguing/addbiblio.pl): the same warning appears in a
"Data quality
     warnings" banner. Unlike the non-XML-character case, there is no "Go to
field" link (the
     whole field was removed, so there's nothing left in the record to jump to)
- only the
     message and a "Mark resolved" button.
   - Confirm a record with BOTH an empty datafield and a non-XML character in
different fields
     shows both warnings together, and both can be independently marked
resolved.
3) Batch import of an unrecoverable record
   - Stage a MARCXML file containing one record with a non-recoverable metadata
problem, together
     with one or more normal, valid records in the same batch (Tools > Stage
MARC records for
     import).
   - Complete staging, then commit the batch (Tools > Manage staged MARC
records > Import this
     batch).
   - Confirm:
     - The background job finishes (does not silently fail with no detail).
     - The job's report shows a "Number of records with errors" count of 1,
alongside the normal
       added/updated/ignored counts.
     - The valid record(s) in the same batch are still imported successfully.
     - On "Manage staged MARC records", the bad record's row shows a red
"Error" status; hovering
       over it shows the decoding error message.
4) Reverting a batch with an unrecoverable record
   - Import a batch that overlays (replaces) an existing record, then corrupt
that record's
     matched biblio's metadata via the DB so a subsequent revert cannot decode
the pre-overlay
     copy stored in marcxml_old (or use a batch where the original record
already had this issue).
   - Revert the batch (Tools > Manage staged MARC records > Revert this batch).
   - Confirm the revert job finishes rather than failing outright, the affected
record is left
     with an "error" status, and other records in the batch are still reverted
normally.
5) CLI import (misc/commit_file.pl)
   - Stage the same batch as in (3), then run: misc/commit_file.pl
--batch-number <id>
   - Confirm the printed summary includes a "Number of records with errors"
line, and the command
     completes rather than dying.
6) Maintenance scripts
   - Run misc/maintenance/touch_all_biblios.pl and
misc/maintenance/sanitize_records.pl against a
     range of biblios that includes one with unrecoverable metadata.
   - Confirm each script reports the error for that one biblionumber and
continues processing the
     rest, rather than dying partway through.
7) Regression check
   - Repeat a normal batch import and a normal single-record edit (no encoding
problems) and
     confirm behaviour, counts, and displayed messages are unchanged from
before this patch.
Automated tests:
   - t/db_dependent/ImportBatch.t
   - t/db_dependent/Koha/BackgroundJob/MARCImportCommitBatch.t
   - t/db_dependent/Koha/BackgroundJob/MARCImportRevertBatch.t
   - t/db_dependent/Koha/Biblio/Metadata.t
   - t/db_dependent/Biblio.t
   - t/db_dependent/api/v1/biblios_metadata_errors.t

-- 
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/

Reply via email to