Bug 39621 - invalid marcxml records with leading whitespaces can be staged, but can't be imported into a catalog
Summary: invalid marcxml records with leading whitespaces can be staged, but can't be ...
Status: RESOLVED DUPLICATE of bug 32638
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic record staging/import (show other bugs)
Version: 24.11
Hardware: All Linux
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-12 21:21 UTC by Jaden Furtado
Modified: 2025-04-14 01:15 UTC (History)
1 user (show)

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


Attachments
Invalid marcxml that can be staged for imports but which crashes when attempted to be imported into a catalog (2.24 KB, text/xml)
2025-04-12 21:21 UTC, Jaden Furtado
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaden Furtado 2025-04-12 21:21:48 UTC
Created attachment 180891 [details]
Invalid marcxml that can be staged for imports but which crashes when attempted to be imported into a catalog

Hello,
This is my first bug report for any OSS. Sorry for any mistakes that I might make given my inexperience :)

Issue:
The issue is that it is possible to import invalid marcxml files in Koha, which then causes an import of this staged record into the catalog to fail. I have attached an example marcxml record for reference, that can be staged in koha, but which is invlaid. Below is the snippet that causes the issue, i.e. notice the tags 001 and     <subfield code="p"> M18325</subfield>, have a space before the data M18325.

---------------------
<?xml version="1.0" ?>
<collection xmlns="http://www.loc.gov/MARC21/slim">

  <record>

    <leader>00000nam a2200000 a 4500</leader>
    <controlfield tag="001"> M18325</controlfield>
...
...
    <datafield tag="952" ind1=" " ind2=" ">
...
...
      <subfield code="p"> M18325</subfield>
...
...
    </datafield>
...
...
----------------------

Proposed fix:
When checking the validity of an imported XML file, a check needs to be added to ensure that this case of trailing and leading spaces in record data fields is handled at the time of staging XML records. I would also suggest that errors should be logged/shown on the frontend, when an import into catalog fails, since it took me a while to dig through a batch of over 5000 records before I could find the cause of the crash. I went through worker and koha error logs but found nothing. Not sure if I was looking in the wrong place.

P.S.: I see that there was a previous discussion: Bug 35104 - We should warn when attempting to save MARC records that contain characters invalid in XML  
However, I am not sure if this bug falls under that or not.

Thanks for the help.
Regards,
Jaden
Comment 1 David Cook 2025-04-13 23:52:35 UTC
Thanks for reporting this one, Jaden.
Comment 2 David Cook 2025-04-14 01:15:53 UTC
Thanks again for reporting this one, Jaden.

However, I think that you might be mistaken. The leading whitespace shouldn't be an issue.

Using the MARCXML you've provided, I can reproduce an import error on my local test system, because the branchcode in 952$a and 952$b don't match a branch in my system. I see that error in /var/log/koha/kohadev/worker-output.log. Once I update those to an existing branchcode, I can import the record and the item fine.

The item will cause some continued problems because the 952$y item type also doesn't exist in my system, but once I update that, things go well. 

That all said... as you point out, the UI doesn't give you any useful information why that failed, and that's definitely a problem. Marking this report as a duplicate of one I raised a couple of years ago on the same topic. 

I'm probably not going to work on it any time soon, as in practice when my own customers have issues I am able to read the logs and give them assistance. But it would be great for someone to fix this at some point to help the people who can't rely on a sysadmin with Koha knowledge.

*** This bug has been marked as a duplicate of bug 32638 ***