Bug 19096: Add update DB entry to sync kohafield in all frameworks

Bug 19096: Add update DB entry to sync kohafield in all frameworks

Squashed the last four follow-ups into one patch. Instead of adding
two routines to Koha::MarcSubfieldStructures, and instead of moving
them to Koha::Util::Dbrev, we finally ended up with converting the
code to raw SQL queries (thx Jonathan). No need to 'pollute' the git
history with all this moving around.

As Jonathan pointed out, there is a risk in using DBIx calls (with Koha
objects) while running database revisions. See also bug 17292 and
bug 19789.

I tested the resulting db revision by adding a few fields to the Default
framework and adding deviating kohafields in other frameworks. And confirm
that it works as expected.

Please read the remainder of this commit message in the light of the above:

===

The dbrev will use two new routines in MarcSubfieldStructures:
[1] get_kohafield_exceptions is used to report deviating kohafields in
    the additional frameworks,
[2] sync_kohafield is used to reset kohafield in the other frameworks to
    the mapping in Default.

Test plan:

Unit test and database revision:
[1] Run t/db_dependent/Koha/MarcSubfieldStructures.t
[2] Verify that your Default 100a is mapped to biblio.author. Go to another
    framework and clear the mapping via mysql command line:
    UPDATE marc_subfield_structure SET kohafield=NULL WHERE frameworkcode=[your_framework] AND tagfield='100' AND tagsubfield='a';
[3] Run the db revision. It should report that 100a was adjusted.
[4] Check in admin/marc_subfield_structure that your 100a is mapped to
    biblio.author again in that framework.

Additional interface testing (ensuring that the changes on this report do
not interfere with multiple mappings):
[5] Make two mappings for copyrightdate: 260c and 264a. And make two
    mappings for biblioitems.pages: 300a and say 300g. Toggle with some
    field values in those fields in the cataloging editor and verify the
    contents of biblio.copyrightdate and biblioitems.pages. The former
    should contain one year (due to additional logic) and the latter should
    contain A | B if both fields are filled.
    Remove the mapping for 300g.
[6] Set AcqCreateItem to ordering or placing. Verify that you can still
    add or receive an order as usual.
[7] Add a mapping for itemcallnumber to 952f (this should remove the one
    for coded_location_qualifier). This is very unusual but serves well in
    testing multiple mappings for items.
    Add or receive an order (fill 952f and 952o) with same and/or different
    values. Verify the contents of items.callnumber. (Check with regular
    item editor; see note.)
    Do a similar edit in the regular item editor.
    Note: You should expect to see A | B in both 952f and 925o if both
    fields are filled with a different value.
    Set items.coded_location_qualifier back to 952f in koha2marclinks.

    Note: When AcqCreateItem==ordering, you will not see A|B in the callno
    field when adding an item on neworderempty.pl. But when you submit
    the main form, addorder.pl is called. At that time an item is created
    and you will see that A|B is in both fields (952f and 952o).

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 19096: (QA follow-up) Move two routines out of Koha::MSS

As requested by RM, this patch moves sync_kohafield and
get_kohafield_exceptions from Koha/MarcSubfieldStructures.pm.

At this moment they are only used in a database revision; it is not clear
if they may be of use later on.

In order to keep them in a module and not remove the unit tests, this
patch adds a Koha::Util module Dbrev.pm. It is now required in the atomic
update, but could be added in a use statement in updatedatabase.pl.

Test plan:
[1] Run updatedatabase.pl
[2] Run t/db_dependent/Koha/MarcSubfieldStructures.t

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 19096: Use raw SQL queries instead for the update DB entry

I strongly thing we must not use C4 or Koha subroutine in the update DB
process, only sql queries.
Especially not DBIC Schema files as they will change.
For instance the update DB 17.12.00.00X is using a specific Koha::Schema::RS::MSS
representing the current schema, but in X months/years, this schema will change
and the ->search we used may failed.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 19096: Move the sql queries to the update DB entry

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: Print "Field 700$a" instead of "Field 700.a" in the dbrev.

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>