Bug 7372: (follow-up) does execute this DB entry twice

Since this enh has been backported on 3.14, this patch should be applied
on 3.16 and master branch in order to update the updatedb entry.
It should not be executed twice otherwise the process is stuck on this
entry.

http://irc.koha-community.org/koha/2014-09-11#i_1567078
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11633 : Block Issue if fines require staff override

If a patrons fines exceed noissuescharge and we allow
staff to allow issue at their discretion via an override
the SIP process allowed charges to go ahead.
This patch closes the loophole which allowed self issue
to subvert the usual library loan policy

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

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11633 Return Correct status if patron blocked by fines

If the patron has amassed charges that block borrowing, but we
allow staff override the information that the patron cannot
issue should be included the patron information response

This patch sets the appropriate status fields in the patron object

It restores the fee_limit member to the patron object
and calls a local subroutine to set it.

This could be done more elegantly but that would require more
major refactoring of the rather messy initializer code
in ILS::Patron

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

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11672: (regression test) get_report_areas gets tested

This patch introduces a unit test for the new get_report_areas functionality.

To try it, run
  $ prove t/db_dependent/Reports_Guided.t

It is expected to have 16 tests defined, and to fail the introduced one

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11672: Untranslatable dropdown on Guided Reports and dictionary

This patch removes hardcoded descriptions and sets them in the templates
using the variable content as id.

To test, create a new guided report and verify the 'module to report on' dropdown
shows as usual [1]. Functionality shouldn't get changed.

The patch also changes the dictionary pages where 'area' should be displayed/selectable
with the same strings as the guided reports. Try all the possible disctionary pages.

The last page when creating a dictionary now shows the 'area description' instead of the
code. The same happens to the dictionary list once you have dictionaries saved.

[1] The following texts get changed:
    Catalogue -> Catalog
    Acquisition -> Acquisitions

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11672: (followup) warnings tested

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12162 - Add class="branchcode" to body tag to make OPAC CSS-styleable per branch

This patch adds a branch sepecific class to all OPAC pages.

Example:
If not logged in, opac-main.pl displays:
<body ID="opac-main" class="branch-default" >
If logged in at branch FFL, it displays:
<body ID="opac-main" class="branch-FFL" >

If you log in, opac-user.pl should display
<body ID="opac-user" class="branch-FFL scrollto" >

To test:
1)
Apply patch.

2)
Add to syspref OPACUserCSS something highly visible, e.g. for branch FFL:
.branch-FFL {
background-color: yellow;
border: 10px solid red;
}

3)
Go to OPAC and login in with a user with home branch FFL

4)
Verify that colors change as appropriate.

5)
Log out. Verify that colors display as before or as defined in class branch-default in OPACUserCSS

6)
Display patch in patch diff view, verify that ids and classes in body tag are consistent with params bodyid and bodyclass in INCLUDE line

7)
Search for regressions

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12873 - Reserve can be cancelled by any logged in user

It is possible to cancel reservations through simply running opac-modreserve.pl with existing reserve_id number. This may provide remove even all reservations from system. The only limitation is that user have to be logged in. Simplest solution is to check whether reserve belongs to user or not.

Test plan:
1. Create reserves by 2 different users, and get their ID's
2. Before patch, hold may by cancelled by anyone who run site:
http://example.com/cgi-bin/koha/opac-modrequest.pl?reserve_id=XXX
3. After patch hold may by cancelled only by user whose reserve is.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12876 - Reserve in waiting/transfer status may be cancelled by user

User may cancel his own reservation at waiting or in transit status
through calling opac-modrequest.pl. Cancel button is disabled in
interface but possibility to cancel should be checked also in
opac-moderequest.pl, before calling CancelReserve().
Similar situation is with opac-modrequest-suspend.pl

This patch provides new soubroutine to chceck if user can cancel given
reserve. It's possible only when he's owner of hold and hold isn't in
transfer or waiting status.

Additionaly there are new test for this function in Reserves.t

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, QA script and new tests.
Works as described, tested with:
.../cgi-bin/koha/opac-modrequest.pl?reserve_id=XXX

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12876: Improve unit tests for CanReserveBeCanceledFromOpac

This patch fix the subroutine name and add a restriction on the
arguments: both argument are mandatory!

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12876: (followup) remove useless diags

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12937: Deleting suggestions should ask for a confirmation

On the suggestion management page, the librarian can choose to delete
suggestions but no confirmation is needed.
This could produce unexpected lost of data.

Test plan:
- go on the suggestion management page
- don't select any suggestion and try to delete (check the checkbox and submit the form).
  Verify that you get an alert.
- select 1 suggestion and delete it, verify you get a confirmation
  message
- select 1+ suggestions and delete it, verify you get a confirmation
  message

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 12937 [Follow-up] Deleting suggestions should ask for a confirmation

This minor follow-up revises the language a bit: Adding missing question
marks and using the more standard prompt "Please select at least one..."

To test, follow the previous test plan and confirm that the prompts are
improved:

- go on the suggestion management page
- don't select any suggestion and try to delete (check the checkbox and
  submit the form). Verify that you get an alert.
- select 1 suggestion and delete it, verify you get a confirmation
  message
- select 1+ suggestions and delete it, verify you get a confirmation
  message

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

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>