Bug 11192: Fix lf and ff07-02 definition in ccl.properties

ff7-02 1=87020 (position 2 of field 007 in MARC21) should be
ff7-02 1=8702

lf 1=8833
lf fiction
fic fiction

should be

lf 1=8833
fiction lf
fic lf

To test :
1. apply the patch
2. copy the modified ccl.properties into your active Zebra config
   directory
3. reindex zebra (rebuild_zebra.pl -b -x -r -v)
4. make some searches using the fixed indexes

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11192: (follow-up) fix a little typo

Test plan the same as the original patch

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested according to test plan. Searches tested were:
fic=e
fiction=e

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11066: make RIS and Bibtex exports RDA compatible

RIS and Bibtex exports from staff side and OPAC edited to
allow for additional publisher RDA tag (264).  Script will
look first for 264 then fall back to 260 when pulling publisher
data from MARC21 records.

Test Plan:
1. Create RDA and non RDA record
2. In OPAC, export both as RIS and Bibtex - verify publisher information
   is exported
3. On staff side, export records as RIS and Bibtex, verify publisher
   information is exported.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed some tabs pointed out by the QA script.
Works nicely in my tests, no regressions found.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11066: (follow-up) add regression test

This patch adds a regression test for using the MARC21
264 field in the Bibtex export.

To test:

[1] Verify that prove -v t/db_dependent/Record.t passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: update hold queue priorities correctly when deleting holds

In various places, deleting a hold request did not trigger recalculating
the priority of the other holds on the bib:

To reproduce the bug:
- select or create 2 users U1 and U2
- select or create an holdable item
- place on hold for both U1 and U2. U1 has priority 1 and U2 has
  priority 2.
- delete the hold for U1
- go on circ/circulation.pl?borrowernumber=XXXX for U2 (or in the DB
  directly) and verify the priority has not been set to 1

The issue is repeatable (at least) on these 2 pages:
 * circ/circulation.pl?borrowernumber=XXXX (tab 'Holds', select "yes"
  in the dropdown list and submit the form)
 * reserve/request.pl?biblionumber=XXXX (click on the red cross)

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reran my tests:

Preparations:
- Create holds for different patrons on a record:
  * 1st - title level hold
  * 2nd - item level hold
  * 3rd - title level hold
  * 4th - title level hold
- AllowOnShelfHolds = On/Allow (items were not checked out)

Tests:
Deleted holds from various pages, confirming bugs first,
then testing with applied patches. Reloading database
after each test.

1) Cancel holds from OPAC patron account
  /cgi-bin/koha/opac-user.pl#opac-user-holds
- Cancel 4th - ok, before and after applying the patch
- Cancel 2nd - ok, after applying the patch

2) Cancel hold from holds tab on staff detail page
  /cgi-bin/koha/reserve/request.pl?biblionumber=7

  a) Setting priority to 'del', submitting with 'Update holds'
  - Cancel first (1st) - ok, before and after
  - Cancel hold in the middle (was 3rd) - ok, before and after
  - Cancel last (was 4th) -ok, before and after

  b) Using red X
  - Repeating tests from a) - before the patch is applied holds
    get totally 'out of order' - after applying the patch, it works
    correctly

Additional tests done on this page:
- Change priority using up, down, to top, to bottom icons
- Change priority with 'toggle to lowest'

3) Cancel hold from the patron's account

  a) Check out tab - Delete? Yes, 'Cancel marked holds'
    /cgi-bin/koha/circ/circulation.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  b) Details tab - Delete? yes, 'Cancel marked holds'
    /cgi-bin/koha/members/moremember.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  Without the patch, holds priorities get out of order.

Additional tests done:
- Check in one item to trigger first hold
- Check in one item to trigger second hold
- Check out first item
Priorities are kept while the item is waiting, when it's
checked out, priorities of remaining holds get reset correctly.

Conclusion:
Big improvement, no regressions found.

Passes all tests in t, xt and QA script.
Also: t/db_dependent/Holds.t
      t/db_dependent/HoldsQueue.t
      t/db_dependent/Reserves.t

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) fixing capitalization in templates

Fixes capitalization on the holds and check in page.

Changes are easy to spot using:
git diff HEAD^ --color-words=.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) correct change to POD for GetReserve()

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11336: (follow-up) improve POD for _FixPriority()

This patch improves the POD for C4::Reserves::_FixPriority()
to (hopefully) describe its function thoroughly.  It also
adjusts the call of _FixPriority() by CancelReserve() to
omit passing reserve_id, since by that point no row in
the reserves table for that request still exists.

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