Bug 8769: Allow SIP2 return backdating

Currently Koha's SIP server ignores the return date part of an 09 ( aka
CHECKIN ) message. Koha should backdate a return, and remove
fines accordingly.

Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>

Works as notified, second date field in SIP checkin (return date) is
used as return date. Return shows up in history with correct date.

Comments:
 - patron is fined if return date is before issue date, but that
   is largely irrelevant anyway.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 8769: (follow-up) remove unnecessary module import

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 8769: (follow-up) undo change to value of $today

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11209: Don't sent the same SMS message for the same user the same day

For PREDUE messages, one message is sent to the message_queue table for
each items in advance, meaning that the patron could receive duplicate
notices.

The SMS part for DUE and PREDUE often do not contain dynamic parts, only
a standard message.

Note that this patch *only* affects the SMS transport.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11209: (follow-up) check if a notice has been already sent today

The previous patch checks if a notice has already been sent when the
current notices has been sent in queue. Which is wrong!
We have to check if a similar notice has been sent today.

This patch has been created after an observation on a production server:
If a user place on holds several items, he will receive 1 SMS per hold.
Here we only want 1 SMS for all holds.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11209: (follow-up) message content must also match for new message to be considered a duplicate

If the template contains dynamic parts, the message won't be
considerated as duplicated.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Duplicate messages will be queued, but when sending the queued messages
duplicates are found and are marked as failed.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10195: hide bib details page for OPAC-suppressed bibs

Records hidden with OpacSuppression are filtered from the search
results, but the opac-detail page is still visible if you know the
biblio number. This patch hides the detail page for suppressed biblios
by redirecting (controlled by the syspref OpacSuppressionRedirect)
either to opac-blocked (default), explaining that the record is blocked
(including optional explanatory text from the syspref
OpacSuppressionMessage) or to Koha's 404 page, giving no hint that a
biblio with that number exists in the system.

Test plan:

Make sure you have at least one record with 942$n == 1.
Set OpacSuppression to "Don't hide".

Do an OPAC search that should bring up your hidden record and other
records.
  Observe that your record is found.
Open the detail page for the record.
  Observe that it is accessible. Copy the URL for later(!).

Set OpacSuppression to "Hide".
Leave OpacSuppressionByIPRange blank.
Set OpacSuppressionRedirect to "an explanatory page ('This record is
blocked')."
Leave OpacSuppressionMessage blank for now.
Disable queryparser(!) (because of bug 10542).

Do a full zebra reindex.

Do an OPAC search that should bring up your hidden record and other
records.
  Observe that your record is not found.
Open the opac-detail URL of the record (the one you copied before).
  Observe that you are redirected to opac-blocked and it displays a
short standard message.

Edit OpacSuppressionMessage and input some text.
Open the opac-detail URL of the record again (the one you copied
before).
  Observe that the text you entered in OpacSuppressionMessage is
displayed under the standard text you have seen before.

Set OpacSuppressionRedirect to "the 404 error page ('Not found')."
Open the opac-detail URL of the record again (the one you copied before).
  Observe that you are redirected to Koha's 404 error page.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10195: DBRev 3.15.00.048

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10195: (follow-up) update license; use Modern::Perl

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10195: (follow-up) add blocked record template for Bootstrap

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10195: (follow-up) tidying up code and eliminate warning if record does not have 942$n

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10003: bash-completion for koha-list and other scripts

This patch implements bash-completion for the following commands:

 - koha-list
 - koha-enable
 - koha-disable
 - koha-email-enable
 - koha-email-disable
 - koha-enable-sip
 - koha-start-sip
 - koha-restart-sip
 - koha-stop-sip
 - koha-start-zebra
 - koha-stop-zebra
 - koha-restart-zebra

It is implemented in a way that it removes already used or mutually
exclusive parameters (instance names, option switches).
I already have written completion for other (more complex) commands,
but I belive a simpler patch is better to start with.

IMPORTANT: this patch relies on having the koha-list command available
in the path.

To test:
 - Make sure you have bash-completion installed and enabled (IRC might
   help us if you encounter problems).
 - Apply the patch.
Option 1:
 - Pick the debian/koha-common.bash-completion file and do
   $ cp debian/koha-common.bash-completion /etc/bash_completion.d/koha-common
 - Open a new bash shell (I do it opening a new terminal on my Ubuntu box).
 - Type one of the listed commands...
  And repeatedly press <TAB>.
 - Enjoy, and signoff if you belive it is usable. Otherwise report back.
Option 2:
 - run:
   $ . debian/koha-common.bash-completion
 - Type one of the listed commands...
  And repeatedly press <TAB>.
 - Enjoy, and signoff if you belive it is usable. Otherwise report back.

Tests:
- Some koha-list option switches are mutually exclusive, -h should be
  available in any context
- koha-enable should only autocomplete disabled instances
- koha-disable should only autocomplete enabled instances
- koha-email-enable should only autocomplete email-disabled instances
- koha-email-disable should only autocomplete email-enabled instances
- koha-*-zebra scripts should only autocomplete enabled instances.
- koha-*-sip scripts should only autocomplete sip-enabled instances.

Regards
To+

Note: writing bash-completion routines is a bit hacky, I tried to make
it the simplest way I could. Your comments are welcome.

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 6739: (follow-up) handle case where patron has no expiration date set

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11262: (follow-up) base generation of day name on a week starting with Sunday, not Monday

This fixes test failures reported by
t/db_dependent/Serials/GetNextSeq.t.

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

To test:

[1] Run prove -v t/db_dependent/Holds.t.  The last test
    should fail.
[2] Apply the main patch.
[3] Run step 1 again.  This time the tests should all pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9532: fix reservability check when bib-level item types are in use

When itemtype is defined on biblio (item-level_itypes syspref), the
method C4::Reserves::CanItemBeReserved uses item->{itemtype}. But
ithe item comes from C4::Items::GetItem and it does not have an
'itemtype' key; in this method the item type value is always in
'itype' key.

This patch corrects it.

Test plan:

You should have itemtype on biblio and 'item-level_itypes' syspref
set to biblio.

This test plan is with ReservesControlBranch on ItemHomeLibrary.
- Choose a branch, a borrower category and an item type, for example
  'NYC', 'CHILD' and 'DVD'
- Set an issuing rule for 'NYC', CHILD' and 'DVD' with 'Holds allowed'
  set to 10
- Set an issuing rule for 'NYC', CHILD' and all item types with
  'Holds allowed' set to 0
- Choose an item of a biblio with itemtype 'DVD', that can be reserved,
  with 'NYC' as homebranch
- Choose a borrower with category 'CHILD'
- Try to request the item for the borrower
=> without the patch, you can
=> with the patch, you can't
You may check reserve is allowed with 'Holds allowed' > 0 on issuing
rule for 'DVD'.

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Great test plan - thanks!

Confirmed the bug, and the fix. Looks good to me.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11741: Correct display of < > in XSLT result lists

< and > are incorrectly transformed into HTML entities on the
XSLT result list when using the GRS-1 indexing mode.

Example:
Record: <TEST>
Result list: &lt;TEST&gt
HTML source: &amp;lt;TEST&amp;gt

To test:
- catalog a record that contains > and <
- Reindex, without using the -x option
- Confirm the display is correct
- Reindex again, using the -x option
- Confirm the display is now broken
- Apply patch
- Reindex again with and without -x
- Verify that now the display is always correct

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Note: the problem is only visible in GRS-1 setup. It works as expected.
No behaviour change in DOM.
I believe we shouldn't be (de)escaping data ad-hoc, but it seems that GRS-1
needs it because it doesn't handle HTML entities properly. This fix is OK for
GRS-1, unneeded for DOM and probably any other modern search engine.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 5377: widen columns to better accommodate multiple ISBN and ISSN

Test Plan:
1) Apply this patch
2) Create a record with 5 ISBNs and 5 ISSNs
3) Create a new report from the following SQL, or execute it from the
   mysql console:
   SELECT isbn, issn FROM biblioitems ORDER BY biblionumber DESC LIMIT 1
4) Note that all your ISBNs and ISSNs are listed, separated by the pipe
   character ( | )

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

This might be slow to run on big databases, because of the 2 index
rebuilds, however it changes no functionality just increases the field
size which is safe enough (we store multiple now already)

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 5377: (follow-up) alter deletedbiblioitems to match biblioitems

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 5377: (follow-up) there is no index on deletedbiblioitems.issn

This patch removes a trailing space and remove the issn index deletion
(it does not exist on deletedbiblioitems).

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>