Bug 12851: order tags should be removed from the claiming letter

If you use a claimissue notice to claim serials, the generated letter
will be

<order>Title1, Author1</order>
<order>Title2, Author2</order>
...
<order>TitleN, AuthorN</order>

This patch geds rid of these tags.

Test plan:
1/ Create a claimissue notice with something like:
  <<LibrarianFirstname>>
  <<LibrarianSurname>>
  The following issues are in late:
  <order><<biblio.title>>, <<biblio.author>> (<<biblio.serial>>)</order>

2/ Generated late serial issues.
3/ Send notifications to vendor.
4/ The order tags should not exist anymore in the sent email.

You can see bug 5342 for a more detailled test plan.

Note for QA: This should have been done in GetPreparedLetter, but I did
not find a better way to do.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described. Tested having the <order> tags on one line
and also for a multi-line layout.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12851: (QA followup) tests should not expect the <order> tag

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12536 - Incorrect number of irregularity issues

Modified:

serials/subscription-detail.pl  - fix split command

Testing:

I Apply the patch

0) Select a serial subscription;
1) Click Edit -> Edit subscription;
2) Click Next;
3) Click Test prediction pattern;
4) Select 3 Vols;
5) Save subscription;
6) Select Planing tab;
7) Valide "Irregularity: 3 issues".

Signed-off-by: Aleisha <aleishaamohia@hotmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Note: You have to select more than 1 issue as not to
      be published to see the problem.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 10956 - Series of OPAC searches can cause a browser crash

This patch fixes the issue for bootstrap. It was earlier fixed for the prog theme.

Solution: Prevent  jQuery.fn.highlight = function(pat) to be called with empty pat
by skipping empty values in highlight loop.

To test:
Without patch, do a search as in comment #1 odr #3
Result: Endless loop (Script not responding)

Appply patch:
No endless loop, page displays OK

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
To reproduce you need to search a string with 2 spaces.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I didn't manage to reproduce the problem, but I couldn't find
any regression either trying multiple searches.
Trusting Marc's and Jonathan's testing.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12865 - 'Pay amount toward all fines' does not record payment note

Without patch:
-------------
Make payment for patron who has fines
Select the Pay Amount button and add a note in the note box.
Select confirm
Result: The note does not display in list

With patch:
----------
Result: The note displays in list
Bonus testing: The note is included in system logs as well (Home:Tools:Logs)

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

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12298: The "feed" MTT does not seem to be used and can be removed

The feed message transport type exists but nobody knows how it can be
used. This patch assumes nobody uses it and removes it.

Before removing the entry in the DB, the updatedb entry will check if no
foreign key exists in order to avoid a delete in cascade.

This path does *not* deletes the occurrences in the templates.

Test plan:
Apply this patch, execute the updatedb script and verify the
message_transport_types table does not contain the 'feed' entry if it was not
in use.

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch will remove the confusing option to configure message texts for feeds.
Checked on a database with an existing feed type notice (not deleted) and
on one without any references to the feed message transport type (deleted!)

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12298: DBRev 3.17.00.060

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13152 - Duplicate phone hold notices when using Talking Tech

If a library is using Talking Tech for phone notices, any waiting hold
phone notice will show up twice!

This is because Koha generates on at the time the hold is set to
waiting, and then the cronjob TalkingTech_itiva_outbound.pl generates
it's own notice as well.

The former notice will always have a status of 'pending', as the
TalkingTech_itiva_inbound.pl script will update the notice the outbound
script created.

The solution is to prevent Koha from creating a phone notice for waiting
holds if TT is enabled, and let the cron script do it.

Test Plan:
1) Enable Talking Tech from the system preferences
2) Set a hold waiting phone notice in the notices and slips editor
3) Choose a patron, enable hold phone notices for that patron
4) Place a hold for a patron, and check it in so it's marked as waiting
5) Note the phone notice generated for the patron
6) Apply this patch
7) Repeat step 4
8) Note that this time, a phone hold waiting notice is not generated

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Amends condition with an additional or statement. Shoudn't affect
anything but phone notices. Change appears logical.

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