The thread under http://lists.katipo.co.nz/pipermail/koha/2010-December/026566.html suggests a desire for making MARC framework import/export easier. http://wiki.koha-community.org/wiki/Mysqldump_Library#A_specific_MARC_framework describes the process idea.
Created attachment 3261 [details] [review] Importing/Exporting the marc structure of a specific framework to a spreadsheet Hi, In the attached patch I've added the possibility of importing/exporting the marc structure of a specific framework to a spreadsheet to be shared with other users, to be modified from the spreadsheet or in order to have a backup. The mysql tables exported are marc_tag_structure and marc_subfield_structure. The exporting spreadsheet formats available are XML and ODS (OpenDocument Spreadsheet). The XML format has an Excel 2003 spreadsheet structure, this format can also be opened with OpenOffice/LibreOffice. The first row of the spreadsheet contains the name of the columns of the mysql table, the next rows contain the data. The null values are exported as a # char and imported as a null string. The ODS format can be opened with OpenOffice/LibreOffice and with Excel if you have a plugin to read OpenDocument formats, see http://en.sourceforge.jp/projects/sfnet_odf-converter/. The structure of the rows is analogue to the Excel 2003 xml format. If you modify the spreadsheet and want to import to a framework you must save the spreadsheet as one of the format specified before. When you import the spreadsheet, all the new marc data structure will be inserted, the overlapped one will be updated and the remaining marc structure will be deleted. It uses perl module Archive::Zip or zip/unzip system command to process ODS files. This functionality is implemented in the intranet -> Administration -> MARC Frameworks. The files affected are: new file: C4/ImportExportFramework.pm new file: admin/import_export_framework.pl modified: koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css modified: koha-tmpl/intranet-tmpl/prog/en/modules/admin/biblio_framework.tmpl Let me know if you find it useful and possible modifications. Regards Salva
Okay, initial testing shows: #1 - the bullets shouldn't display, they clutter the interface #2 - exporting to ODS creates a corrupt file that I can't open in OpenOffice #3 - exporting to Excel works! #4 - the close bullet doesn't do anything ... #5 - why is there an import next to each framework? shouldn't you be importing a new framework? what happens if I import over an existing framework? #6 - I think there should be an export to MySQL I didn't test importing yet because of #5 above.
(In reply to comment #2) > Okay, initial testing shows: > > > #1 - the bullets shouldn't display, they clutter the interface If the bullets are the input radio from the form they are needed to choose between the two possible formats. If they are the symbols of the rows list (<li>) they shouldn't be on display. Let me know what OS and browser you're testing with, or send me an screenshot to see what's your view. > #2 - exporting to ODS creates a corrupt file that I can't open in OpenOffice Have you installed the perl module Archive::Zip or zip/unzip system command?, to create a valid ODS file it has to ZIP compress a directory full of xml files. I don't know how to make a patch to install a missing perl module. > #3 - exporting to Excel works! I'm happy to hear about it. :) > #4 - the close bullet doesn't do anything ... Again, let me know what OS and browser you're testing with because I've tested it with Firefox/Chrome/Safari/Opera/IE8/KMeleon under Windows 7 Professional and it closes the layer opened. > #5 - why is there an import next to each framework? shouldn't you be importing > a new framework? what happens if I import over an existing framework? To import to a new framework you have to create it first and afterwards import the structure from the spreadsheet. The spreadsheet only affects to the fields and subfields (marc_tag_structure and marc_subfield_structure MySQL tables). If you import over an existing framework and you haven't modified the spreadsheet the framework should remain unaltered. If you have modified the spreadsheet (adding a field, adding subfield, deleting a field, ...) importing it should make the same operations on the framework (MySQL tables). > #6 - I think there should be an export to MySQL No problem, can make it too. > > > I didn't test importing yet because of #5 above. Thanks fot the rapid response and testing.
Created attachment 3262 [details] bullet images I mean the bullet that comes from the <li>. I'm on FF on Mac OS X
(In reply to comment #3) > > #2 - exporting to ODS creates a corrupt file that I can't open in OpenOffice > Have you installed the perl module Archive::Zip or zip/unzip system command?, > to create a valid ODS file it has to ZIP compress a directory full of xml > files. > I don't know how to make a patch to install a missing perl module. This I did not do, I will try that now. > > #4 - the close bullet doesn't do anything ... > Again, let me know what OS and browser you're testing with because I've tested > it with Firefox/Chrome/Safari/Opera/IE8/KMeleon under Windows 7 Professional > and it closes the layer opened. I'm on FF on Mac OS X. > > #5 - why is there an import next to each framework? shouldn't you be importing > > a new framework? what happens if I import over an existing framework? > To import to a new framework you have to create it first and afterwards import > the structure from the spreadsheet. The spreadsheet only affects to the fields > and subfields (marc_tag_structure and marc_subfield_structure MySQL tables). > If you import over an existing framework and you haven't modified the > spreadsheet the framework should remain unaltered. If you have modified the > spreadsheet (adding a field, adding subfield, deleting a field, ...) importing > it should make the same operations on the framework (MySQL tables). Thanks! I'll test.
Created attachment 3263 [details] bullet in chrome This is what it looks like in Chrome on Mac OS X - which I think is what you were going for ... so I'm not sure what the deal is with Firefox on Mac.
I did a shift refresh in FF and now the export pop up looks right! So, nothing to fix there :)
I installed Archive::Zip but I still can't open the ods file.
Wouldn't exporting as CSV and as SQL make the most sense? Then the CSV can be opened in any spreadsheet application and SQL can be imported into a new DB.
Sure thing, just wanted to offer more of xml spreadsheet formats. I'll include CSV as the default format, SQL format too and test ODS on a MAC OS X. Thanks again for the invaluable testing and suggestions.
Created attachment 3415 [details] [review] New proposed patch for export/import fields and subfields of a framework New proposed patch with CSV and SQL formats added, CSV being now the default. Fixed the bug on the creation of the ODS file. Tested with servers: Linux Debian Lenny, FreeBSD 8.2, OpenBSD 4.8 Clients: Windows 7, Mac OS X, Linux Debian, PCBSD and a great variety of browsers. Hope it helps and you find it useful or not ;) Regards Salva
Okay we're almost there. I tested the export and it works in all formats and opens in those apps. The import however is confusing. First I created a new framework, then i clicked import next to it. The box asks for a speadsheet file so I tried the *.ods and that didn't import, just threw and error. So I tried to import the csv and that worked - sort of - it took me to the page that asks me what framework to base my new one off of - so I chose one and then I had to do the import again for it to take. We should be clear what files can be imported back into Koha and if you create a new framework, the import option shouldn't be there until you pick a framework to base it off of - if that's necessary.
Created attachment 3495 [details] [review] Corrected patch for export/import fields and subfields of a framework The error in the ods importing was a bug in the uncompressing method, I've changed it to work fine now. I've modified the importing to allow the use of exported files from a framework to a different one. The problem was that it was importing ok, but to the original framework it was exported from, so you ended up with the page asking you to choose the framework to base the new one on.
Woo hoo!! This last patch works beautifully, I have submitted it with my sign off.
Pushed please test