Created attachment 157680 [details] Example records to use with the CSV2MARC plugin This is perhaps a unique set of circumstances, discovered while utilizing the CSV2MARC plugin. I have not tried to replicate this outside of the plugin. To recreate: 1. Create a framework called CSV2MARC by duplicating the Default framework but remove 000, 001, 003, 005, and 008 tags. 2. Create the CSV file. 3. Configure the plugin, matching the columns in the CSV file. 4. Stage and import the file selecting CSV as the format and CSV2MARC as the Framework. 5. Look at the detail view of the imported record and see that it has imported correctly. 6. Edit the record (do a minor edit like adding punctuation to a field) and save. 7. Look at the detail view of the imported record again and see that there is data loss. Now import the same record via z39.50. See that it imports correctly. Edit and save the record and see that all of the data for the record is retained. The z39.50 import uses the Default framework with the tags referenced above. The workaround was to correct the CSV2MARC framework and add back the 000, 001, 003, 005, and 008 tags, but mark the tag and subfields as not required. The CSV2MARC configuration and import works better by not trying to bring in the leaders (iow, its easier not to). If the ability exists to delete the tags in the framework and import a record with that framework, then there should not be data loss when editing and saving. Since these leader tags are important, at least as a space holder, then the ability to delete them in the framework should be disabled or a warning provided.
Created attachment 157682 [details] Plugin configuration
*** This bug has been marked as a duplicate of bug 27730 ***