Bug 11869: Add more informations to the patron account printing page

This patch adds additional informations to the "Print summary"
and the "Print receipt" templates.

Additional information in "Print summary":
* Registration date
* Expiration date
* Library
* Category
* Fines and payments

TEST PLAN
---------
1) Go to a patron.
2) Make sure they have something checked out.
3) Manually add a fine.
4) Under the 'Print' button click 'Print summary'
   -- the resulting preview should:
   a) have the first for things listed above, and
   b) have a new fines and payments section.

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

NOTE: The due date of the check out is not part of this patch,
      and so I signed off. Similarly, anything required for
      slips is configurable elsewhere now and thus comment 1
      does not accurately reflect the intent of this patch.

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

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11869: (follow-up) only display active fines

This patch modifies the patron summary printout so that
only fines with an outstanding balance (either positive
or negative) are displayed.  Also, the entire fines section
is displayed only if there is a non-zero balance.

This is consistent with the logic for displaying the loans
and hold requests tables, and avoids cluttering the summary
with historical fines.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11258: fix another case where holds queue made transfer requests that contradict the library holds policy

This patch fixes a problem where the holds queue generator
was making requests where the pickup library is the
same as the item's library but not the patron's branch,
even if there is a "Default holds policy by item type" rule that states
this item can only fill holds for patrons of the same library as the
item.

Test Plan:
1) Create a test record with 2 items with different itemtypes
2) Set the Default holds policy by item type for the first
   item to "From any library"
3) Set the Default holds policy by item type for the second
   item to "From home library"
4) Place a record level hold for a patron from another library,
   but for pickup at the same library as the item is from
5) Rebuild the holds queue
6) View the holds queue, note the item is listed, though this
   patron cannot place a hold on this item
7) Apply this patch
8) Repeat step 5, note the hold is no longer in the queue

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
automated tests pass, functional tests pass. Bug replicated, eradicated by patch.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I finally managed to reproduce this, patch works as described.
Passes tests and QA script, provided tests fail without patch, but
succeed with the patch.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
Bug 11955: Remove spaces in empty indicators when linking an authority to a biblio record.

This patch removes spaces in indicators which are imported when we link an
authority to a biblio record. The spaces made the indicators harder to edit
after the linking, because we had to delete the superfluous space character
before a new value could be entered.

To test:
1. Open some authority on editor, save with empty indicators.
   They are saved as ind1=" " ind2=" " on auth_header tables, with spaces
2. Edit some record, link some tag with previous auth,
   indicators now have a space on it (or ind1 at last)
3. Apply the patch
4. repeat 2, space is gone

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10533: move JavaScript functions for basket groups to a separate file

This patch moves JavaScript functions used for managing basket groups
to a file.  This has the effect of putting the last (active) use of
the YUI JavaScript library by the staff interface in one file:

  koha-tmpl/intranet-tmpl/prog/en/js/basketgroup.js

Test plan:
- Try all actions for basketgroup ( drag/drop, add, delete, close, print,
reopen, edit, export as csv).
- Check that there is no regression on others acquisition pages:
  * acqui/neworderempty.tt
  * acqui/uncertainprice.tt
  * acqui/addorderiso2709.tt
  * acqui/basketheader.tt
  * admin/aqbudgets.tt
  * admin/aqcontract.tt
  * admin/aqbudgetperiods.tt
  * admin/aqplan.tt
  * suggestion/suggestion.tt

Signed-off-by: Galen Charlton <gmc@esilibrary.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>
Bug 12048: add regression test

This patch adds a regression test for verifying that superlibrarians
can see all subscription when IndependentBranches is on.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12048: restore ability of superlibrarian to see other libraries' subscriptions

This patch fixes a regression in master and 3.14. When a user has
superlibrian permissions, a search on serials subscriptions should
display other libraries' subscriptions even when IndependentBranches
syspref is enabled.

To reproduce/test the bug/patch:

1. Enable IndependentBranches (i.e. 'Prevent' staff...)
2. Login as a user not having superlibrarian permission
3. Search for a serial subscription on:
   /cgi-bin/koha/serials/serials-search.pl
4. Search a title which has at least 2 subscriptions: one in the user
   branch, and one in another branch
5. On the result page, just 1 subscription is displayed: the one
   attached to the userbranch
   => this is normal
6. Login as a user having superlibrarian permission
7. Repeat step 3-5.
8. You get the same result as 5. You should have seen all subscriptions.
   That's what you get after applying this patch.

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

NOTE: I tested a variation. My superlibrarian was a branch that
      was not the same as the non-superlibrarian. The serial was
      the same branch as the non-superlibrarian. Without the
      patch, the superlibrarian saw nothing, with the patch it
      saw the serial as expected.
      Also, remember the superserials permission can affect the
      results. I successfully changed the branch of the
      subscription, and then it ceased to show up with
      superserials not granted to the non-superlibrarian.
      I corrected the system preference name in the text here.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Superlibrarian permission now allows to see all subscriptions
independent from the branch.
Passes all tests and QA script.

But the superserials permission appears broken to me before
and after this patch. If I have superserials - the search
doesn't show all subscriptions. If I don't have superserials
I can still edit any subscription accessing the subscription
detail page through the serial collection page or accessing
the detail page directly by manipulating the URL.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12080: restore effect of superserials permission

The superserials permission is meant to allow an operator
to see all subscriptions regardless of branch when IndependentBranches
is on without having to have full superlibrarian permissions.  This
patch restores this behavior.

TEST PLAN
---------
1) Apply the patch for bug 12048 (as needed -- it may be pushed)
2) Ensure you have two users: superlibrarian, non-superlibrarian
   with all access to the staff client except superserials.
3) Ensure you have serials belonging to a different branch than
   the non-superlibrarian.
3) Log into staff client as superlibrarian
4) Click 'Serials'
5) Click the 'Submit' button in the search area.
   -- note the number of results.
6) Log into staff client as non-superlibrarian
7) Click 'Serials'
8) Click the 'Submit' button in the search area.
   -- note the number should be less, note the number.
9) Give the non-superlibrarian superserials access.
10) Home -> Serials
11) Click the 'Submit' button in the search area.
   -- the number will still be the same at the one in step #8.
12) Apply the patch
13) Refresh the page
   -- the number should now match the one in step #5.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12080: (follow-up) fix test failure and warnings in Bookseller.t

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixes the tests as promised.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12098: Fix C4::Serials::can_edit_subscription

This patch fixes a problem whereby staff users could
edit subscriptions they are not permitted to by going directly
to the subscription details page.

It also adds some unit tests for the can_edit_subscription routine
and add a new can_show_subscription routines.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Notes on second patch.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12098: Refactor can_*_subscription in C4::Serials

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested on top of patches for 12048 and 12080.

Subscription search
- superlibrarian, IndyBranches on/off - always sees all subscriptions
- superserials, IndyBranches on/off - always sees all subscriptions
- no superserials, IndyBranches on - only sees own subscriptions
Note: Subscriptions without branches will only show, when all subscriptions
      are visible. In a future enh it might be good to enforce setting a
      branch, when IndyBranches is used.
- no superserials, IndyBranches off - always sees all subscriptions

Subscription editing
- superlibrarian, IndyBranches on/off - can edit all subscriptions
- superserials, IndyBranches on/off - can edit all subscriptions
- no superserials, IndyBranches on - can only edit own subscriptons and
  subscriptions without branch
  NOTE: it would make sense to also allow Edit > Edit as new (duplicate)
  here, so one can copy the subscription from another branch to modify
  it for the own branch.

Passes tests in t, xt and QA script, also newly provided unit tests.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12098: (follow-up) deal with FIXMEs in t/db_dependent/Serials_2.t

This patch nails down the number of tests to be run.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12098: (follow-up) put can_show_subscription() into use

This patch puts C4::Serials::can_show_subscription() into use.

Note that there is user-visible change: if a subscription has a
blank library, all users with serials permissions will be able
to view and/or edit it.  It remains to be determined whether
we *want* such subscriptions to exist, or if they should only
be tied to specific libraries.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12003: Do not calculate next pubdate for irregular subscriptions

Show 'Unknown' when planneddate and publisheddate cannot be calculated

Also fixes SQL query in misc/cronjobs/serialsUpdate.pl that was still
using "periodicity != 32" to exclude irregular subscriptions from
results

Test plan:

1) Create a subscription in the serials module. Make sure to choose:
   Frequency = Irregular
2) Test the prediction pattern, first publication date is set to
   "First issue publication date" field, others will show as
   'unknown'
3) Save the subscription
4) Check the created issue - it will show a published date and a
   planned date (same as "First issue publication date" field)
5) Receive the issue and check the next generated issue, planned
   date and published date should show as 'Unknown'
6) Generate a next issue, planned date and published date should
   also show as 'Unknown'

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

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also tested:
- multi receiving generates mulitple issues without dates - 'unknown'
- staff detail page shows the dates empty, which is fine
- OPAC detail page shows the dates empty, which is fine
- serial collection page shows 'unknown' and those issues appear
  on the 'manage' tab, as they did in the past
- Editing the issue from the serial collection page leaves the
  date fields empty.
- Receving the issue, setting the status to 'Arrived' the Expected on
  date is set to 'today' automatically. Date published has to be
  entered manually (maybe something we could improve later
- subscription detail > issues tab shows Uknown.
- t/db_dependent/Serials/GetNextDate.t pass.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11689: Take new serial missing statuses into account in more places

Bug 10851 introduced new missing status (codes 41,42,43,44), but in
GetSerials and _update_missinglist, they are not taken into account.

This patch corrects the issue.

To reproduce:
1/ Create a serial with 10 issues.
2/ Set different statuses on each one, with at least 6 missing statuses
(not only "Missing").
3/ Go on the subscription detail page, tab "Summary", the issues with a
new missing status are not listed in the missing issues list.
4/ On the "Issues" tab, all missing are listed (normally only 5 should
be listed.
5/ Apply the patch.
6/ Edit serial (to rewrite the missing list).
6/ Verify that steps 3 and 4 have now correct behavior.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes QA script and tests.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11689: Add unit tests for serials statuses

prove t/db_dependent/Serials.t

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11689: (follow-up) fix warnings generated when running Serials.t

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11689: (follow-up) fix another warning when running Serials.t

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11752: display the correct frequency for serial subscriptions in OPAC details

This fixes bootstrap and prog by modifying the description displayed
in the OPAC's detail of serials.

RM NOTE: this patch does not cover the case where custom serial
frequencies have been defined.

TESTING to reproduce
- create/find a serial with a 1/week periodicity (4 in the database)
- Find it in the opac-detail.pl, click "more details" at the bottom
- validate the string.  Before the patch, it will say:
"The current subscription began on 2013-12-06 and is issued every 3
 weeks for 26 issues"

The "every 3 weeks" is clearly wrong.
In fact any periodicity chosen would display a wrong description, not
matching the staff interface.

After the patch, the display is corrected.

As a bonus, the "every 2 years" now has a description, where it had
none before.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>