I can't respond to the librarian part of this, but I strongly agree as a developer. To make things worse, I believe there are _tiny parts_ of Koha that respect the per-framework mappings, leading a librarian into a false sense of hope.
+1 to removing per-framework mappings in the UI and code. 2017-08-07 7:12 GMT-06:00 Marcel de Rooy <m.de.r...@rijksmuseum.nl>: > Hi developers or librarians, > > > > If you are interested in say sorting search results or lists by > publication date based on 260 and RDA 264, please read further. > > OR If you use varying kohafield mappings across your MARC frameworks. Say > you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in > framework B. > > > > Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306) > is aimed to resolve the issue of having the copyrightdate in two MARC > fields. > > It allows you to have multiple mappings per kohafield. So you can connect > 260c and 264c to copyrightdate. Current Koha allowed you to add the second > mapping already in the frameworks, but it silently ignores one of the two. > > > > In finishing this development however, I got stuck at the following > question: Should Koha really allow varying kohafield mappings per > framework? In the above example the multiple mappings feature should > resolve the need of having a different assignment for copyrightdate between > framework A and B. Both could simply have two mappings for copyrightdate. > > Although Koha more or less allows you to add kohafield assignments per > framework via the MARC frameworks, it does not really support kohafields > per framework. (The Koha to MARC mappings tool in Administration does > change the mappings in Default and copies them to other frameworks.) We > have GetMarcFromKohaField calls in the codebase that do not pass a > framework code. And when we process search results or import records, we do > not have a framework code either. So in those cases Koha just uses the > kohafield mappings from the Default framework, although you might have > specified another mapping in the associated framework of a search result. > > > > I would propose now to make the decision that we only use one set of > kohafield mappings (those from Default), and that we do no longer allow > changes to kohafield mappings in the other frameworks. > > The possibility of adding multiple mappings per kohafield hopefully > removes most objections to that approach as illustrated in the frameworks A > and B example. > > > > I submitted my changes so far on the Bugzilla report. If we agree on > Default as the authoritative framework for these mappings, I will still add > code to change GetMarcFromKohaField calls etc. > > > > If you have stringent reasons for maintaining varying kohafield mappings > per framework and your need for them cannot be resolved with multiple > mappings, please respond and provide information about the fields you are > mapping differently across your frameworks. > > > > Any other feedback is welcome too. > > > > Thanks, > > > > Marcel > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Jesse Weaver
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
