Bug 11947 - renumber reserves when hold is confirmed

Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.

This patch forces a renumbering so that all the priorities remain
copacetic.

Test plan:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Test plan confirms that the problem exists and that the patch corrects
it.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/db_dependent/Reserves.t.
Improves priority calculation.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 5052: make it possible to pick a language if all choices are sublanguage

This was tricky to catch. In current implementation, Bug 6755
introduced in C4/Templates.pm as condition to send the array of
hashrefs of languages that (@$languages_loop<2), but with one
language group that condition is false, there is only one
element in that array.

This patch changes that condition to have more than one language
selected, grouped or not.

Also send $bidi value always, that was only sent if there is
more than one group language.

To test:
1. Translate to en-GB and en-NZ, or simply do mkdirs
on intranet-tmpl/prog and opac-tmpl/bootstrap

2. Go to Administration > System preferences > I18N
enable those languages on staff/opac

3. Check that language chooser is nowhere to be found

4. Apply the patch

5. Reload staff/opac, now you can see language chooser

NOTE: I made little changes on staff, but can't replicate
bootstrap colors for selected/unselected language. Someone
need to touch css files to make it happen. But that is
current behavior.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Good catch!

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11797: add regression test

This patch adds unit tests for C4::AuthoritiesMarc::BuildSummary
for both UNIMARC and MARC21 and a regression test for the "Odd
number of elements in anonymous hash" warning.

To test:

[1] Run prove -v t/db_dependent/AuthoritiesMarc.t.  It should
    report one failure.
[2] Apply the main patch.
[3] Run t/db_dependent/AuthoritiesMarc.t again; it should pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11797: fix odd number of elements in hash warning (MARC21)

This was discovered when someone triggered an authority search
on an authority record that was missing what is assumed the
default subfield for a given field.

It, however, also can be triggered in an OPAC authority search
by looking at the record that lacks the default subfield for a
given field.

TEST PLAN
---------
1) Create an authority record with 180$x and NOT 180$v.
   See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop
   for known tags and default values. The default subfields are
   the first letter of the $subfields_to_report string.
2) Trigger the bug:
   Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=#
             Where # is the authority id of your tweaked record.
             The error occurs in Normal view.
   Method 2: Home -> Cataloging -> + New record
                  -> Click the 'Tag Editor' on 100$a
                  Editing of $a to $b and back may be required.
3) Notice there is an error log entry.
4) Apply the patch
5) Attempt to trigger the bug again
6) That specific error log entry is not generated.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Could generate the warning with a missing 151$a with both methods.
No warning anymore after applying this patch.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11797: fix odd number of elements in hash (UNIMARC)

I got the same warning for my UNIMARC DB.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11797: (follow-up) fix MARC21 branch of bug more idiomatically

This patch puts the MARC21 variant of the bugfix in alignment
with the UNIMARC variant, removing the use of unnecessary
temporary variables.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10825: don't display enum/chron twice for items received via the serials module

TEST PLAN
---------
1) In the staff interface, display a bib that has one or more items
   that were received in the serials module.  The following query
   can identify them:
   -- in MySQL:
      SELECT items.biblionumber,items.enumchron,serial.serialseq
      FROM items,serial,serialitems
      WHERE items.itemnumber=serialitems.itemnumber
        AND serialitems.serialid=serial.serialid;
2) Note that in the holdings tab, the serial enumeration/chronology
   is displayed twice.
3) Apply the patch
4) Refresh the screen
4) Now, the enum/chron should be displayed only once per item.

Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Template change only.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>