This enhances it's for introduce new fields into the biblio and biblioitems tables for the new field 264 and the respective subfields. This imply to add, first, three new fields like 260$c biblio.copyright, 260$a biblioitems.place, and 260$b biblioitems.publishercode. Second mapping with the respective field 264 in all MARC frameworks. Important. According to the online help, you can not map more than one MARC field to a Koha field. http://manual.koha-community.org/3.16/en/catadmin.html#kohamarcmapping This will enable to use in all modules that are needed for display, for example, acquisition, serial, cataloging module, etc. Since new RDA MARC fields have been added to the database will not be necessary to do so. Likewise, XSLT for display in Intranet and OPAC Bootstrap has been corrected and signed off in the following bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12724 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12725 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12726 Next to this there will be a hard work to research all the modules where the field 264 can be displayed.
Hmm, I think this bug is applicable for 'master' Koha too, not just 3.16.x I will update bug...
I think this is kind of a duplicate to bug 10306 - which I found after my comment on the other bug. I am not sure new fields are the best solution here. It means that you will have to change lots of places in Koha - because the same information is stored in 2 different places - we already have this problem with copyrightdate and publicationyear, where one is used for MARC21 and the other in UNIMARC. Why not store it in the same place and allow multiple mappings with kind of a sequence? If 264 is not there, try 260. This would make things much easier, also for reporting.
Hm, there is also the other way around - if we make Koha-to-MARC-Mappings 1:n, we also need to change the procedures that are used for creating a record from a non-marc format, for example in acquisitions.
Moving discussion to the older bug. *** This bug has been marked as a duplicate of bug 10306 ***