Bug 3144 - anti-spam for opac-suggestions

this patch adds a negative-captcha feature to the purchase suggestions form

some info for the curious...
 http://nedbatchelder.com/text/stopbots.html
 https://github.com/subwindow/negative-captcha
 http://www.rubydoc.info/github/subwindow/negative-captcha/frames

to test this patch...

1/ apply patch

2/ enable 'suggestion' and 'AnonSuggestions' sysprefs

3/ attempt to add a 'purchase suggestion' in OPAC
   adding the suggestion should succeed

4/ edit the koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-suggestions.tt file,
    to reveal the hidden 'negcap' field

   replace line 87 opac-suggestions.tt, from...
     <li id="negcap" style="position: absolute; left: -2000px;">
   to ...
     <li id="negcap">

5/ attempt to add another suggestion, and populate the 'negcap' field
   adding the suggestion should fail

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: Remove the bug report number in the comment since git log
cans provide the same result.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Bug 11169: Display acquisition details in the OPAC

This patch adds a new system preference 'OPACAcquisitionDetail'.
If it is enabled, information about items on order will be displayed on
the OPAC detail page.

Test plan:
- switch on the OPACAcquisitionDetails pref.
- set the AcqCreateItems pref to 'receiving'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the "Holdings" tab contains the
  line "X item are on order." (at the bottom of the table containing the
  item list).
- receive the items.
- verify the number of items has decreased.
- set the AcqCreateItems pref to 'ordering'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the item list contains the items
  with the "on order" status.
- receive the items.
- verify the received items no longer have the the "on order" status.

To test completely this feature, you should verify there is no
regression on the pref OpacMaxItemsToDisplay, OpacSeparateHoldings and
OpacSeparateHoldingsBranch.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>

Also removed some blank lines from the original patch and bumped up
the DBRev.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11169: (follow-up) add more unit tests

This patch adds direct unit tests of the new biblionumber filter
for SearchOrders.  It also moves the ordernumber filter test
to the rest of the SearchOrders tests.

To test:

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

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11169: (follow-up) only count orders that have been placed

This patch ensures that only orders that have been placed (i.e.,
orders whose basket is closed) are counted in the OPACAcquisitionsDetails
display.

To test:

[1] Turn on OPACAcquisitionsDetails and set AcqCreateItem to 'ordering'.
[2] Create an order for a record, but do not close the basket.
[3] View the record in the OPAC.  It should not display any order count.
[4] Close the bakset.
[5] View the record in the OPAC again.  This time, it should display
    the count of items on order.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
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>
Bug 11169: DBRev 3.17.00.008

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.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>
Bug 12343: Add regression test for TransformKohaToMarc

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.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>
Bug 11958: Fix typon 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>
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>
Bug 12293: Correct display for patron messaging preferences on OPAC - bootstrap

This patch is a follow-up for bug 11125, it fixes the bootstrap theme.

Test plan:
1) Remove 'sms' from message_transport_types table.
2) Go on OPAC "My messaging" tab => table columns are out of alignment with table heading.
3) Apply patch => table is correctly displayed.

Signed-off-by: Axelle Clarisse <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
With and without 'sms' existing the display of the table is now correct.
Template only change.

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bug 12439 - check that CGI is enabled when doing koha-create

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as expected.
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>
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>
Bug 11891: set up tests to require that Koha::Database uses same DB handle as C4::Context

This patch removes changes in two cases to work around the fact that
Koha::Database and C4::Context were not using the same DBI database
handle.

To test:

[1] Run prove -v t/db_dependent/ILSDI_Services.t and
    prove -v t/db_dependent/Items.t.  Both tests
    should fail.
[2] Apply the main patches and run step 1 again.  This
    time, both tests should pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11891 - Make Koha::Schema use C4::Context->dbh

Right now there is no connection between the database handles used by
C4::Context::dbh and Koha::Datbase/Schema. This makes it impossible to
use transactions in unit tests to temporarily modify the database to
test subroutines that take advantage of Koha::Database. This patch fixes
that issue.

Test Plan:
1) Apply this patch
2) prove -v t/db_dependent/ILSDI_Services.t and
   prove -v t/db_dependent/Items.t and
   prove -v t/db_dependent/Circulation_issue.t should
   all start passing

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11891: (follow-up) remove custom storage class

For now, just rely on the normal DBIx::Class cleanup handler;
otherwise, the following warning is displayed in logs:

  (in cleanup) Can't locate object method "_preserve_foreign_dbh" via package "Koha::Storage" at .../Koha/Storage.pm

Using the default DBIC storage class also means that we
don't have to manually do things like set the SQL limit dialect;
meaning that we don't get the following warning message:

  DBIx::Class::ResultSet::find(): Your storage class (Koha::Storage) does
  not set sql_limit_dialect and you have not supplied an explicit
  limit_dialect in your connection_info. DBIC will attempt to use the
  GenericSubQ dialect, which works on most databases but can be (and
  often is) painfully slow. Please file an RT ticket against
  'Koha::Storage' . at /home/gmc/koha/C4/Members.pm line 840

Test plan: same as main patch

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11891: (follow-up) set DBIC storage flags correctly

Since we're passing an existing DBI database handle to
DBIC, and that handle doesn't have RaiseError set to true
by default, don't let DBIC override that -- for now.

Test plan: verify that the DB-dependent test suite passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>