Bug 12396 - MTT FIX: Due notices (DUEDGST) are multiplicated and all of them are sent to everybody who is about to receive ODUEDGST.

So the first patron receives correct letters, but the followings received
all the previous ones AND his letters.
Eventually you end up with !n letters in message_queue where n = amount of patrons
receiving due messages as digest and having something due.

Eventually we got 4 000 000 ODUEDGST-letters of which 1 100 000 were sent to our patrons :)
This is madness!

Test plan:
0/ Delete the content of the message_queue table.
1/ Pick 3 patrons and set them to receive due messages as digest.
2/ Check 1 item out for 3 separate patrons and specify a due date today.
3/ Launch the advance_notices.pl script.
4/ Before this patch, you got 6 notices (1+2+3 [!n]). Now, you get 3 notices, 1 for each patron.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Problem exis.
Patch work as described following test plan.
No koha-qa errors

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12343 - TransformKohaToMarc() is adding MARC subfields in random order

TransformKohaToMarc() function in C4/Biblio.pm iterates through it's
argument - which is a hashref - using 'each'. Perl is not guaranteed
to return hash keys in any particular order (not to mention that
in more recent perl versions, explicit hash key order randomization
is to be expected).

As a consequence:
1) For biblio records added via acquisition (order from a new/empty
record, order from a suggestion), freshly created MARC biblio records
doesn't always have 260 $b and 260 $c stored in the proper order
2) Holdings data exported for zebra indexing as 952 fields may have
subfields generated in more-or-less random order. While it probably (?)
does not affect zebra indexing/searching in any significant way,
end result is prone to be somehow ugly (which can be a potential
issue e.g. for people running Z39.50 server) and is not guaranteed
to be consistent; different records - or even different items in the
same record, can have 952 subfields generated in indiscriminate order.

This patch fixes abovementioned issues via introducting explicit
sorting (by subfiled code/letter) for subfield pairs before they
are added to the MARC record.

To test:
1/ Try to confirm and reproduce both issues (use perl 5.18.1 if possible
for more randomly ordered results).
2/ Apply patch.
3/ Redo the tests; ensure that both issues are now fixed and that there
are no apparent regressions of any kind (especially regarding to 952 fields
generated for zebra [re]indexing).

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12343: Add regression test for TransformKohaToMarc

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12343: QA follow-up

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12338: Remove smartmatch operator from C4/Serials.pm

This patch removes the use of the 'when' smartmatch operator from
Serials.pm

Regards
To+

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11958: Fix typo in classification source help

The Classification Sources help file said the source was in the 942$2 but it's in the 952$2 and 94$2 so this patch fixes that.

To test:
* Go to Admin > Classification Sources
* Click Help
* Confirm the Help file is right now

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
String change, no errors.

Note: Perhaps change "Authorized Values ..." for "Authorized values ..."

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12380 - can't tab to save buttons on add item

Many form elements on the add item page are giving a tabindex of "1" by
the script. This seems to make it impossible to tab through the add item
form fields onto the save buttons. I don't see a reason to set an
explicit tabindex of "1," so this patch removes it.

To test, apply the patch and open an item for editing. Try tabbing
through the add item form fields. It should be possible to tab through
the fields and onto the submit buttons at the bottom. Test again when
adding a new item.

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12439 - check that CGI is enabled when doing koha-create

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as expected.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12406: adding the column maxsuspensiondays in the tests

The column maxsuspensiondays was added in the datatable but not in the tests, which caused the failure of the tests

test plan: execute prove t/db_dependent/Circulation_Issuingrule.t
The command has to print:
t/db_dependent/Circulation_Issuingrule.t .. ok
All tests successful.
Files=1, Tests=9,  2 wallclock secs ( 0.03 usr  0.01 sys +  1.35 cusr  0.08 csys =  1.47 CPU)
Result: PASS

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Failure on test before patch, success after
No koha-qa errors

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11801: In transit hold items incorrectly labels as "Waiting to be pulled" on request.pl

If an item needs to be transferred to fill a hold, the hold will be
listed as 'Waiting to be pulled" while it is in transit.

Test Plan:
1) Place a hold for pickup at another library
2) Check in the item, confirm the hold transfer
3) View the holds for that record ( request.pl )
4) Note the priority is "In transit" and the status is 'Waiting to be
   pulled".
5) Apply this patch
6) Reload the holds page
7) Note the status is now "Item being transferred to $branch"

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>