Bug 12071: improve generation of Z39.50 search links

This patch fixes two problems with the generation of
links to execute a Z39.50 search from the staff client
catalog and cataloguing search results page.

First, if using URI::Escape 3.30 or earlier, performing a simple search
with a double quote (e.g., "histoire algerie"), the Javascript is broken
in results page because of :

function GetZ3950Terms(){
  var strQuery="&frameworkcode=";
  strQuery += "&" + "title" + "=" + ""histoire%20algerie"";

Second, the encoding of non-ASCII characters in the search
term was broken.

This patch moves URI escaping from Perl to template with uri TT filter.

Test plan :
- To reproduce the issue with double quotes, the server
  must be running URI::Escape 3.30 or earlier; the current
  version of URI::Escape properly escapes double quote.
- In staff interface, perform a search with double quotes
  that will return no result, ie "aaa xxx"
=> Without patch, javascript is broken
=> With patch, javascript is not broken
- Click on Z3950 button on results page
=> Without patch, the Title input is empty
=> With patch, the Title input contains the search terms

Additional test:
Do a search with something like äöü and then click Z3950
button on results page.
Without patch, encoding is broken in Z3950 form
With patch, encoding is correct.

Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed a few tabs. Passes tests and QA script.
I can't reproduce the Javascript problem, but I can reproduce
the Z39.50 encoding problem and can detect no regression.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 064d5478d31b05442e19b7d57f0af94d3422731e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11947 - renumber reserves when hold is confirmed

Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.

This patch forces a renumbering so that all the priorities remain
copacetic.

Test plan:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

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

Test plan confirms that the problem exists and that the patch corrects
it.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/db_dependent/Reserves.t.
Improves priority calculation.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 95056d17b715b74e3f7149d60e12d5a365d70eeb)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 12079: ensure that CheckReserves() includes reserve_id in its response

This patch modifies _Findgroupreserve so that its one caller,
CheckReserves(), would include the reserve_id field in the
hold request it returns.

Failure to include reserve_id in every circumstance resulted
in bug 11947.  This patch is therefore a complementary fix for
that bug, but is not meant to preempt the direct fix for
that bug.

To test:

[1] Verify that t/db_dependent/Reserves.t passes.
[2] Verify that the following test plan taken from
    the patch for bug 11947 works for this patch
    *without* applying the patch for 11947:

* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.

Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".

With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Work as described. No koha-qa errors. Test pass

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 695fdebdee802387f45505a1350120727d3e2f7f)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11219: make CAS authentication work with URL parameters

Bug 10029 tries to fix the use of URL parameters in CAS authentication.
But is does not work.
The full URL must be used in all methods of C4::Auth_with_cas.
Also, in checkpw_cas(), the 'ticket' parameter must be removed to find
the original URL.

This patch removes the 'ticket' parameter from query before calling
checkpw_cas() since the ticket is passed as method arguemnt.
In C4::Auth_with_cas, many methods use the same code to get the CAS
handler and the service URI. This patch adds a private method
_get_cas_and_service() to do the job.

Test plan:
- Enable CAS
- Go to opac without been logged-in
- Try to place hold on a record
=> You get to /cgi-bin/koha/opac-reserve.pl?biblionumber=XXX showing
   authentication page
=> Check that CAS link contains query param "biblionumber"
- Click on CAS link and log in
=> Check you return well logged-in to reserve page with biblionumber
   param
- Check CAS loggout
- Check Proxy CAS auth

Signed-off-by: Koha team AMU <koha.aixmarseille@gmail.com>

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests in t, xt, and t/db_dependent/Auth.t.
Also passes QA script.

As I have no working CAS server, I focused on regression testing:
Activated Persona and casAuthentication.
- Verified normal login against database still works.
- Verified Persona login works.
  Note: With Persona you are always forwarded to the patron
  account - so you have to search for the record again before
  you can place a hold.
- Verified that the CAS URL contains the biblionumber when
  logging in while placing a hold.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Retested 2014-04-12

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit c8a18f5eefd81dc07512faa962064effdfb88de9)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11219: (follow-up) fetch only URL parameters

This followup corrects the fact that when using $query->url(), both
GET and POST params are get.
Using $query->url_param() will only get params directly in URL.

Test plan :
- Enable CAS
- Go to login page : cgi-bin/koha/opac-user.pl
- Try to connect with local login using random login and password
  (they will be transmitted by POST)
- You stay to login page
- Look at CAS login URL
=> Without this patch it will contain the random login and password
   as parameters of opac-user.pl
=> With this patch it does not contain any parameter

Signed-off-by: Matthias Meusburger <matthias.meusburger@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit b57d98517c5a9572a54412f7f4e5d872acfa85c3)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11711 - Use new DataTables include in circ templates

Bug 10649 introduced a new include file for adding DataTables-related
JavaScript assets. This patch adds use of this include file to all
circ-related pages which use DataTables.

Apply the patch and test the following pages to confirm that table
sorting works correctly:

- Circulation
  - The UseTablesortForCirc system preference must be enabled.
  - Check out to a patron with existing checkouts. Choose a patron who
    is a guarantor to another patron with checkouts in order to test the
    relatives' checkouts table.
  - The checkouts and relatives' checkouts tables have been modified to
    exclude articles when sorting of titles.

- Hold ratios - The title column has been configured to exclude articles
  from sorting

- Transfer to receive

- Holds queue
  - The title column has been configured to exclude articles when
    sorting
  - The date column has been modified to use the title-string filter for
    sorting. An unformatted date is now passed from C4::HoldsQueue.pm to
    the template, where the KohaDates filter is used for formatting.
    Sorting is based on the unformatted date.

- Holds awaiting pickup
  - The "available since" column has been configured for sorting on an
    unformatted date. waitingreserves.pl now passes the unformatted
    date to the template, and formatting is done using the KohaDates
    filter.
  - The title column has been configured to exclude articles when
    sorting.

Edit: Rebased on current master following commit of Bug 11605
Signed-off-by: A. Sassmannshausen <alex.sassmannshausen@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 612b33ae69adbed63e55c91f7314f6c2888f6d71)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11734 - Use new DataTables include in batch modification templates

Bug 10649 introduced a new include file for adding DataTables-related
JavaScript assets. This patch adds use of this include file to the
batch modification and batch deletion pages.

Minor text changes: Corrected capitalization.

Apply the patch and test the following:

- On batch modification and batch deletion, submit multiple barcodes or
  item numbers. On the results page the title column has been configured
  to use the "anti-the" filter to exclude articles from sorting. Sorting
  on all columns should work correctly.

Edit: Put back checkboxes plugin which was accidentally removed.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 7349f847fad28ada0eb98cd5ebb44d563d7ee0f7)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 9075: Rename "type" to "material type" on staff XSLT detail and results

The label Material type better describes what the icon presents.
It is based on leader values of the MARC record.

Revised Test Plan
-----------------
1) Set the Staff system preference XSLTDetailsDisplay to
   'default' and save.
2) Set the Staff system preference XSLTResultsDisplay to
   'default' and save.
3) Click 'Search the catalog' tab in the search area.
4) Search for something
5) Look for a biblio that has 942$c set to some type.
   -- It should display "Type:"
   Or take a result and modify it to have a 942$c.
6) Look at the biblio details
   -- It should also display "Type:"
7) Apply the patch
8) Search for the same biblio again.
   -- It should display "Material type:" this time.
9) Look at the biblio details
   -- It should display "Material type:" this time.
10) Run the koha qa test tool.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>

Note: This is a simple string substitution.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 4bdd8d9a69f72751f0429be5bc58afdd218a4bb0)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 9075: Rename "type" to "material type" on OPAC XSLT detail and results

The label Material type better describes what the icon presents.
It is based on leader values of the MARC record.

Revised Test Plan
-----------------
 1) In the staff client, set the OPAC system preference
     OPACXSLTDetailsDisplay to 'default' and save.
 2) In the staff client, set the OPAC system preference
     OPACXSLTResultsDisplay to 'default' and save.
 3) In the staff client, set the OPAC system preference
     opacthemes to 'bootstrap' and save.
 4) In the OPAC, search for biblio used in previous patch testing.
    -- It should display "Type:"
 6) Look at the biblio details
    -- It should also display "Type:"
 7) In the staff client, set the OPAC system preference
     opacthemes to 'prog' and save.
 8) In the OPAC, search for biblio used in previous patch testing.
    -- It should display "Type:"
 9) Look at the biblio details
    -- It should also display "Type:"
10) Apply the patch
11) In the staff client, set the OPAC system preference
     opacthemes to 'bootstrap' and save.
12) In the OPAC, search for biblio used in previous patch testing.
    -- It should display "Material type:" this time.
13) Look at the biblio details
    -- It should display "Material type:" this time.
14) In the staff client, set the OPAC system preference
     opacthemes to 'prog' and save.
15) In the OPAC, search for biblio used in previous patch testing.
    -- It should display "Material type:" this time.
16) Look at the biblio details
    -- It should display "Material type:" this time.
17) Run the koha qa test tool.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Note: Just a simple string change.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
String change, works as advertised in staff, prog and bootstrap
OPAC.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 007c94ff20a5c9d9c3121849b42f820a0da5b869)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 8044: new module for translating strings in Perl source files

You have to use the new module Koha::I18N

Code example:
  use Koha::I18N;
  use CGI;

  my $input = new CGI;
  my $lh = Koha::I18N->get_handle_from_context($input, 'intranet');

  print $lh->maketext("Localized string!");

PO files are in misc/translator/po/LANG-messages.po.
Creation of PO files are integrated to existing workflow, so to create
PO file for a language, just run in misc/translator:
  ./translate create LANG
To update:
  ./translate update LANG
You can then translate the PO with your favorite editor. Strings will be
localized at runtime.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Works as advertised. Some details needing further attention noted on bug
report.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 114f3dd49998be21643f83bec644f9837c6bdecc)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 8044: (follow-up) fix warning and error messages in translate.pl

CHARSET is now automatically replaced by UTF-8, and 'update' creates the
PO file if it does not exist.

Also do not try to create PO files if POT file creation failed (when
there is no messages to translate for example).

+ add some verbosity
+ add Locale::Maketext and Locale::Maketext::Lexicon to Koha
dependencies

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 75bd34df7acba7b20bc7981f2484e79e19032d4a)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>

Conflicts:
	C4/Installer/PerlDependencies.pm
Bug 8044: (follow-up) add copyright block and use Modern::Perl

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 061cff837d1667b0f714fbbfba59c2caed098d6b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 8044: (follow-up) ensure Modern::Perl is imported first

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit fe32727fc55823ab1a3edba70597b89856cd0ea3)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 9865: make SIP msg encoding configurable via SIPconfig.xml

The accounts->login tag in SIPconfig.xml can now accept a new
parameter, "encoding". It will be mostly used to encode to utf8.

For this, simply add the parameter: encoding="utf8"

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>

Works as advertised, does nothing if encoding is not set.
Blows up all the machines that can't handled utf8 if it is set :) But
that's not Koha's fault. :)

Patch rebased by Christophe Croullebois  <christophe.croullebois@biblibre.com>

Signed-off-by: Petter Goksoyr Asen <boutrosboutrosboutros@gmail.com>

But now I did it the right way! And I can confirm that this patch solves
all issues with mangled characters in SIP messages. Confirmed that it
looks good with Norwegian characters in patron name and in book titles.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 4a72f6b2375895c690dcaaaff26b07de53cfd518)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 9865 (follow-up) give better usage examples in example SIPconfig.xml

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 7b295e9dd7a1f2a9b1d1cf1882edbc2a0e70fe3a)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 12056: fix untranslatable strings in calendar

In the calendar there are some strings in a JavaScript function which
are not properly wrapped in a function for translation. This patch
corrects this.

This patch also corrects some minor validation issues and spelling and
grammar issues, including those covered by Bug 12055.

To test, apply the patch and view the calendar in Tools -> Calendar.
When you hover your mouse over a day in the calendar you should see a
title tooltip indicating what kind of day/holiday it is and showing the
title of the holiday, if any.

To test that the strings are now being picked up for translation,
run translate update on a po file and confirm that the affected strings
are now present: "Weekly holiday," "Yearly holiday," etc.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Works well. New strings on translation file. No koha-qa errors.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 0837954cdda85549f5552dacefd3a5bc3e58292e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 10865: Don't show list permissions when adding public lists/sharing lists is not allowed

If patron creation of public lists is disallowed by the
OpacAllowPublicListCreation system preference the "category" option
should be hidden altogether instead of showing a <select> with "private"
as the only option. This patch hides category and permissions controls
when OpacAllowPublicListCreation is set to "don't allow."

To test you must have the virtualshelves system preference enabled.
Apply the patch and log into the OPAC. Test:

- With OpacAllowPublicListCreation enabled, create a new list. You
  should see options for setting category and permissions. Saving the
  new list should complete correctly and save the right settings.
- With OpacAllowPublicListCreation enabled, edit an existing list. You
  should see the same options and saving your changes should work
  correctly.
- With OpacAllowPublicListCreation disabled, create a new list. You
  should only see fields for title and sort. Saving this list should
  complete correctly and save the right settings.
- With OpacAllowPublicListCreation disabled, edit an existing list. You
  should be able to edit only title and sort settings. Saving your
  changes should work correctly.

Repeat your tests for both prog and bootstrap themes.

Revision: Existing public lists can be edited and retain their public
status even if OpacAllowPublicListCreation has since been disabled. This
preserves the behavior previous to this patch.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
This patch fixes a big ergonomic issue.
Note: to me, the "New list" action should be outside the tabs.
It is confusing to have a "new list" into the public lists tab when it
is not possible to create new public lists.

Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 9bb5238bcf55c1dabb3c1e41eee582df888ea80b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 10865: (follow-up) Move a li tag to avoid overlapping tags

With this patch, a li tag is empty (only using the bootstrap theme) if
the pref is disabled.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>

Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit c8085cb9c38f60b1152f4cf86c7ffcc82d3e8106)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
bug 10865: (follow-up) allow patrons to make their public lists private when OpacAllowPublicListCreation is off

This patch ensures that patrons continue to have the ability to make
their public lists private for any public lists they control that were
created before the library turned the OpacAllowPublicListCreation
system preference off.

To test:

[1] Ensure OpacAllowPublicListCreation is on.
[2] As a patron, create a public list in the OPAC.  Also, create
    a private list.
[3] Turn OpacAllowPublicListCreation off.
[4] Back in the OPAC, verify that the public list can be edited
    and that there are drop-downs for category and permissions.
    Also verify that there is a warning that the patron cannot
    change it back if they convert a public list to private.
[5] Edit the private list created in step 2.  Verify that the
    category and permissions drop-downs are not displayed.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 7dd0e9a41fd639e86ed32d98d863d605a6ba63e8)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 10865: (Follow-up) Add CSS style for form hints

This patch adds a new "hint" class for displaying information relating
to a form field. On the list edit screen the hint also has an alert
class to highlight it.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script. Works as advertised.
Tested with Bootstrap and prog theme. Some notes:

- When OpacAllowPublicListCreation is turned off, the permissions
  don't show.
- When OpacAllowPublicListCreation is turned off, we could also hide
  the Category pull down in the [new list] pop up, as there is only
  Private left as an option.
- Maybe we should move the new list link outside of the tabs?
  When OpacAllowPublicListCreation is turned off, but public lists
  exist, the link 'new list' will still show on the public list tab,
  but a private list will be created.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 9094b4a1bbff95e0f8e5747a805dacede165bc9a)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>

Conflicts:
	koha-tmpl/opac-tmpl/bootstrap/css/opac.css