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
Thanks for reporting this one, Jaden.
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 ***