Commit graph

280 commits

Author SHA1 Message Date
a197a09feb Bug 28229: Count only if needed
We don't need to count the number of clubs if we selected a patron or
club already

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-05-10 15:46:54 +02:00
b8a664fe7d Bug 28229: Only show clubs on request.tt if clubs exist
1. Have no existing clubs
2. Apply patch
3. Go to request.tt and you will not see the club tab or any mention of clubs
4. Create at least 1 club
5. Go back to request.tt and now see the tab for clubs
6. Make sure you can place holds as an individual with and without clubs.
7. Make sure you can place holds for clubs.
8. rejoice and sign-off

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

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-05-10 11:59:14 +02:00
750a7646b8 Bug 16787: (follow-up) Fix check to ensure reasons are passed to template
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-22 14:50:11 +02:00
0f23622041 Bug 16787: 'Too many holds' message appears inappropriately and is missing data
This patch alters C4/Reserves.pm to pass back 'noReservesAllowed' when
allowedreserves=0. This allows passing to the user an appropriate
message about the availability of items for holds

This patch also fixes a FIXME about using effective_itemtype to fetch item rules

To test:
1 - Set one itemtype to allow no holds
2 - Set 'Holds per record' to 0 for another itemtype/patron combination
3 - Create or find 2 records, each with items only of the itemtypes above
3 - Attempt to place a hold for a patron on each record above
4 - The message will be 'Too many holds'
5 - Apply patch and repeat
6 - Message should be "Cannot place hold: no item are available to be placed on hold"
7 - Try placing a multihold with either record above and a holdable record,
  message should end "Cannot place hold on some items'
8 - prove -v t/db_dependent/Holds.t

Rebase - Fix test expectation

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-22 14:37:14 +02:00
a7529e1fd9 Bug 28118: Default to current branch when placing hold
During bug 27071 development, this line got inadvertedly changed. This
patch restores the original behaviour.

To test:
1. Search for a title
2. Go try place a hold
=> FAIL: Look at the HTML, there's no pickup location with
selected="selected"
3. Switch branch and repeat 2
=> FAIL: Still the same
4. Apply this patch
5. Repeat 2 and 3
=> SUCCESS: Branch is selected, chosen current branch is picked
6. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-16 12:28:17 +02:00
0fd2be61e8 Bug 26999: (follow-up) Simplify code
Doing
$ git grep pickup_locations_code

shows there's some calculated data that is not actually used anywhere.
We can get rid of it.

This patch also reuses $item_object (which is in the same loop scope) to
avoid an extra DB call.

To test:
1. Run:
   $ git grep pickup_locations_code
=> FAIL: It is only used/set as a comma separated string, inside
request.pl
2. Apply this patch
3. Repeat 1
=> SUCCESS: The unused stuff is not there anymore
4. Open the page for placing some holds
=> SUCCESS: It doesn't explode
5. Sign off :-D

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-01 18:51:37 +02:00
13bb39f4c6 Bug 26999: Make 'Any library' translatable when placing a hold
This patch makes the 'Any library' string translatable, by converting it
into a flag and using it accordingly on the request.tt template.

To test:
1. Have the 'Hold pickup library match' set to 'any library' on the
   circultation rules.
2. Open the page to place a hold on a biblio with some items
=> SUCCESS: The item says 'Any library' on the 'Allowed pickup
locations' column.
3. Apply this patch
4. Repeat 2
=> SUCCESS: No behavior change
=> SUCCESS: The string is on the template
5. Sign off :-D

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-04-01 18:51:37 +02:00
099e2fe2b7 Bug 7806: Fix remaining occurrences of 0000-00-00
We should remove all SQL queries that contain 0000-00-00 and finally
assume we do not longer have such value in our DB (for date type)

We already dealt with such values in previous update DB entries.
The 2 added by this one haven't been replaced already.

The code will now assume that either a valid date exist, or NULL/undef.

Test plan:
QA review is needed and test of the different places where code is
modified.

Not sure about the change from reports/issues_avg_stats.pl

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

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-03-01 11:16:42 +01:00
aa221e0c8b Bug 27071: Use GetReservesControlBranch to pick the branch
Pretty much like the opac-reserve.pl does, this patch makes the staff
request.pl script get the branch from the specialized routine from
C4::Reserves instead of falling back to userenv.

To test:
1. Follow the original test plan:
- Create two local hold groups containing distinct lists of libraries.
- In default rules for all libraries, set Hold Policy = "From local hold group" and Hold pickup library match to "Patron's hold group"
- Make sure AllowHoldPolicyOverride is set to Don't Allow

- Make sure you're logged in at a library in Group 1
- Find a bib with only 1 item from Group 1. Confirm you can place a hold on this title for a patron in Group 1 (correct), but not for a patron in Group 2 (correct).
- Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), BUT you also cannot place a hold for a patron from Group 2 (incorrect) -- Koha gives the erroneous message "pickupNotInHoldGroup"

- Change your library to a something in Group 2
- Find a bib with only 1 item from Group 1. Confirm you cannot place a hold on this title for a patron in Group 1 (incorrect), and not for a patron in Group 2 (correct).
- Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), but you can place a hold for a patron from Group 2 (correct)
=> FAIL: Things expected to fail on the plan, fail.
2. Apply this patches
3. Repeat 1
=> SUCCESS: It now works!

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-03-01 09:56:19 +01:00
7a42c85889 Bug 26963: (QA follow-up) Fix cases where we expected a list
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-13 14:20:11 +01:00
fbd0bbf98f Bug 26990: (bug 22284 follow-up) Prevent hold to be placed if cannot be transferred
There is a missing parameter to CanItemBeReserved, we need to know if
the hold can be placed at a given pickup library.

Test plan:
1 - Set preferences:
     UseBranchTransferLimits: enforce
     BranchTransferLimitsType: itype
     AllowHoldPolicyOverride: Don't allow
2 - Set Centerville 'Book' items to not be allowed to transfer to any other library
3 - Make sure Hold policy is set to 'any library'
4 - Find a record with a Centerville item and other items
5 - Attempt to place an item level hold on the Centerville item (with a
pickup library different than Centerville)
=> Without this patch you are taken to the holds list, but your hold is not placed
Nothing indicates why hold has failed
=> With this patch you cannot select the item from Centerville
"Cannot be transferred to pickup library"

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-12 17:09:49 +01:00
Nicolas Legrand
3de906ac13 Bug 24412: (follow-up) prevent request.pl from failing
When no desk is defined request.pl returns an internal server
error. Check a desk is defined before asking for reservation deskname.

Plan test:

1. log in with a library with no desk
2. check in a reserved book so it'll be switch to “waiting reserve”
3. go to the book notice and click the Holds tab (request.pl page)
4. boum
5. apply patch, restart plack
6. refresh page
7. now loading properly

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-06 15:55:17 +01:00
Nicolas Legrand
47b32572d4 Bug 24412: Attach waiting reserve to desk
When an item is checked in and marked 'Waiting' or already 'Waiting'
and there is a desk attached to the session, the item is marked
waiting at the current desk of the current library.

The information is displayed on the OPAC and on the intranet. The
patron can then know at which desk he can retrieve his document.

Desk Management (Bug 13881) is now useful.

Test plan :

1. apply Bug 24201
2. $KOHA_PATH/installer/data/mysql/updatedatabase.pl
3. Check out some document to someone
4. make another one reserve this document
5. check in the document
6. you can see the document is attach to the current library
7. create some desks and attach one to your session (see Bug 13881 and
Bug 24201)
8. cancel the preceding reserve and redo steps 3 to 5
9. you should see the document is waiting at the current library and
current desk on:
  a. the intranet document request page
  b. the intranet borrower holds tab
  c. the item list where the document is listed on the bibliographic
    details
  d. the borrower's OPAC holds tab.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Bug 24412: (follow-up) QA

Following Josef Moravec QA comments :

- rewrite Koha::Hold->desk according to Object Oriented Koha
Guidelines and use it to fetch desk name in various templates
- remove unused Desks.GetName
- Check for columns existence in db update

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Bug 24412: (follow-up) QA: useless change

Maybe it was a relic of something usefull... anyway
not anymore.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Bug 24412: (follow-up) Fix POD

Koha::Desk and not Koha::Library...

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-06 15:55:17 +01:00
e1a5fc85a6 Bug 22806: (QA follow-up)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-11-02 11:03:08 +01:00
Julian Maurice
96cc447045 Bug 25898: Prohibit indirect object notation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-15 12:56:30 +02:00
Joonas Kylmälä
0e1d291b14 Bug 12556: Add new "in processing" state to holds
This adds new syspref, HoldsNeedProcessingSIP, which controls whether
a hold that is related to item will be filled automatically or not. If
the user has enabled the syspref then instead of fulfilling the hold
automatically the hold will go to "in processing" state.

To test:
 1. Checkout a book to patron A
 2. Place a bib level hold to the book for B
 3. Patron A returns the book via SIP, to simulate this use:
        ./misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --item <ItemBarcode> -m checkin
 4. Notice that no notification is generated for Patron B about hold
    and that the hold status in intranet and opac is "In Processing".
 5. Notice that patron A (or other patrons) cannot checkout a book
    that is in processing, because it is considered to be attached to
    the holdee (similarly to the waiting state):
        ./misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --patron <PatronABarcode> --item <ItemBarcode> -m checkout

Signed-off-by: Timothy Alexis Vass <timothy_alexis.vass@ub.lu.se>
Rebased-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-14 14:50:07 +02:00
Joonas Kylmälä
88f7d9f89c Bug 12556: reserves/request.pl: Reuse code from Koha::Hold
Signed-off-by: Timothy Alexis Vass <timothy_alexis.vass@ub.lu.se>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-10-14 14:50:07 +02:00
638786e719 Bug 24663: Remove authnotrequired if set to 0
It defaults to 0 in get_template_and_user

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-03 10:40:35 +02:00
Agustin Moyano
4b43c886a0 Bug 22789: (follow-up) Fix atomic update, GUI and more than one hold
This patch
* sets one check for reserves and another for old_reserves in
atomic update
* Adds a message below the checkbox and adds detail when a hold is non
  priority
* Fixes issue when there are more than one hold, but the first is non
  priority
* Adds test case for this last scenario

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-31 16:10:25 +02:00
Agustin Moyano
d390b2f7cf Bug 22789: Add non priority feature to C4 classes and staff interface
This patch implements necesary code to implement non priority feature

To test:
1) Apply all patches.
2) Run updatedatabase.
3) Checkout a specific item for patron1.
4) Place a hold on the same item for patron2 (do not check non priority
   hold checkbox).
5) Try to renew the item for patron1.
CHECK => in checkouts table, there is a message that the item could not
be renewed because there was a hold.
6) Cleanup all checkouts and holds.
7) repeat steps 3 to 5, but this time check the non priority checkbox.
SUCCESS => item was renewed
8) prove t/db_dependent/Holds.t

Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-31 16:10:25 +02:00
27c80187ba Bug 25534: Use the cancelation reasion for the 'X' hold cancelation links
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Rebecca Coert <rcoert@arlingtonva.us>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-25 15:07:27 +02:00
af0d71b747 Bug 25534: Add ability to send an email specifying a reason when canceling a hold
Some libraries would like to be able to cancel a hold with the option to
specify a reason. Providing a reason would generate an email to that
patron.

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Create new AV category "HOLD_CANCELLATION", add some cancelation reasons
5) Add new Holds module notice "HOLD_CANCELLATION", add an email version.
   A quick test version would be "Reason: <<reserves.cancellation_reason>>"
--
[% USE AuthorisedValues %]
Reason: [% AuthorisedValues.GetByCode( 'CANCELLATION_REASON', hold.cancellation_reason, 'IS_OPAC' ) %]

[% IF hold.cancellation_reason == "MY_AV_VALUE" %]
IF perhaps you'd like to have a much longer explanation than just the
one sentence in the AV description, you can use IF blocks using Template
Toolkit markup!
[% END %]
--
6) Place a hold for a patron
7) On request.pl, select the 'del' option for the hold
8) Select a cancellation reason and choose "Update hold(s)"
9) Note a new message has been queue for the patron with the cancelation reason
11) Test again from circulation.pl
12) Test again from moremember.pl
10) Cancel a hold with no reason, note no email is generated
11) Delete your authorised values, not the feature is disabled
12) Reinstate the authorised values, but delete the notice,
    you should now be able to cancel a hold with a reason,
    but no email will be generated

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Rebecca Coert <rcoert@arlingtonva.us>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-25 15:07:27 +02:00
Andrew Nugged
618cf80df9 Bug 24683: Subroutine name changed (fix), no code logic changed This is the intermediate refactor: renamed subroutine only.
Naming mistake came because this sub is used to detect if anything
available for hold, but it used in "if ANY UNAVAILABLE rule", so actually
results of this sub negated (see below "return" in the code).

In details:

when previous refactor was done, name for subroutine was chosen
wrongly in "opposite" direction from what it actually does:

it was named "ItemsAnyAvailableForHold", but this subroutine gave
truth (1) if at least one of the items available on shelf, not lost,
not on loan, not held, and not restricted by smart rules and damaged
status. So, if this sub says that item is still "available", this
actually PREVENTS item from hold in parent sub (see negated return):

    sub IsAvailableForItemLevelRequest {
        ...
        my $any_available = ItemsAnyAvailableAndNotRestricted...
        return $any_available ? 0 : 1;
             # ^^^ if any available and not restricted - we don't allow
             #     on-shelf holds
        ...

I.e. like it named now: "ItemsAnyAvailableAndNotRestricted".

Small aside fix: white space for '&&' inside brackets added to join
operation by priority visually.

Testing plan not needed: all places where sub used it just renamed.
More: all this places/code was introduced in one older commit so there
is also no overlaps or other calls/uses for this subroutine.

Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-08-24 10:12:45 +02:00
Petro Vashchuk
8efa607ae5
Bug 25516: Fix for "Can't call method unblessed on unblessed reference"
Software error:
    Can't call method "unblessed" on unblessed reference at ../reserve/request.pl line 581.
was caused by recent commit with `wantarray` removal in sub pickup_locations in ‘Item.pm’
and visible on fresher Perls (where experimental feature "autoderef" removed https://www.effectiveperlprogramming.com/2010/11/use-array-references-with-the-array-operators/ )

To test:
    1) Get a clean dev environment after "reset_all"
    2) Add an empty record for “Default checkout, hold and return policy” on /cgi-bin/koha/admin/smart-rules.pl.
    3) Open item record, like /cgi-bin/koha/reserve/request.pl?biblionumber=1&borrowernumber=1
    4) Observe the error (Can't call method "unblessed" on unblessed reference at ../reserve/request.pl line 581.)
    5) Apply patch.
    6) Repeat steps 2 and 3.
    7) Observe that the error is gone.

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-05-19 08:29:34 +01:00
04ce87c4c0
Bug 16547: Remove more multi_holds inconsistencies
There was a bug, on the biblio's hold list view, if the pickup library
was changed, the next screen was "place a hold for no title"

http://pro.kohadev.org/cgi-bin/koha/reserve/request.pl?multi_hold=1&biblionumbers=

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-05-11 14:00:32 +01:00
93244efa3c
Bug 16547: Do not display "multi holds" view if only one is selected
If a hold is selected from the result list, we should let the ability to
select an item-level hold.

Test plan:
I. Detail page
1/ Go to a bibliographic record detail page
2/ Click "Place hold"
3/ Select a patron
=> No change expected, you can select an item

II. Search result, multiple holds
1/ Search for an item with more than one search result
2/ Select several items, click 'Place hold'
3/ Enter a patron card number
=> No change expected, item level holds are not available.

III. Search result, single hold
1/ Search for an item with more than one search result
2/ Select only one item, click 'Place hold'
3/ Enter a patron card number
=> With this patch applied, item level hold is available. The screen is the same
as when you place a hold from the bibliographic record detail page
=> Without this patch you cannot place an item-level hold

QA notes: We could go a bit further and remove the 2 biblionumbers and
biblionumber from hold script, as well as remove the checkMultiHold in
request.tt. We should not have a biblionumbers param that contain a list
of biblionumber separated by '/' but several biblionumber parameters
instead.

QA notes 2: About placerequest.pl, see bug 19618 comment 27.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-04-06 10:41:02 +01:00
Andrew Nugged
18ad5f5eea
Bug 24185: Make holds page fast when 'on shelf holds' set to 'If all unavailable'
When "reserve/request.pl -> C4/Reserves.pm::IsAvailableForItemLevelRequest" called many times with hundred of items and "on shelf holds" parameter set to "If all unavailable" for these items + patron, it goes slow.

It happens because in subloop it is checking if all items available so it is O(n^2) and it re-checks each time the same info for each item with repeating DB/data requests.

Fix:
The inner loop 1:1 picked out into separate subroutine and called outside of the loop, saving data in 'items_any_available' variable once, this variable passed to IsAvailableForItemLevelRequest to be used inside as the precalculated result.

This made algorithm O(n) instead of O(n^2) so there is noticeable speed increase.

How to reproduce:

1) on freshly installed kohadevbox create/import one book,
remember that biblionumber for later use it in down below,

2) add 100 items for that book for some library,

3) find some patron, that patron's card number we will
use as a borrower down below to open holds page,

4) check for the rule or set up a single circulation rule
in admin "/cgi-bin/koha/admin/smart-rules.pl",
that rule should match above book items/library/patron,
check that rule to have a non-zero number of holds (total, daily, count) allowed,
and, IMPORTANT: set up "On shelf holds allowed" to "If all unavailable",
("item level holds" doesn't matter).

5) open "Home > Catalog > THAT_BOOK > Place a hold on THAT_BOOK" page
("holds" tab), and enter patron code in the search field,
or you can create a direct link by yourself, for example, in my case it was:
/cgi-bin/koha/reserve/request.pl?biblionumber=4&findborrower=23529000686353

6) it should be pretty long page generation time on old code, densely increasing for every hundred items added. In the case of this solution, it's fast, and time increases a little only, linear.

I tested on my computer in VirtualBox for page generation times,
did 3-5 runs for same case to check if results are stable, and got such values:

(old code):
  100 items:    50 seconds
  200 items:   3.2 minutes
  300 items:   7.3 minutes

(version with fix):
  100 items:   4.4 seconds
  200 items:   7.5 seconds
  300 items:  10.4 seconds

Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-25 09:40:58 +00:00
Andrew Nugged
7ecd21a1e4
Bug 24185: Make holds page faster - Improved "if"
`$can_item_be_reserved eq 'OK'` moved in `&&` before `IsAvailableForItemLevelRequest`
to cut away with static known values before calling to more resource consuming subroutine.

Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-25 09:39:59 +00:00
c2f1106f2e
Bug 24802: Updating holds can cause suspensions to apply to wrong hold
On request.pl, the table of holds shows a suspend_until date picker for each hold, *unless* that hold is waiting or in transit. The script reserve/modrequest.pl assumes that there will be a suspend_until input for each hold, but that is incorrect. Assume there are 20 holds on a record, and 10 of them are waiting or in transit. If you were to then set the suspend until date on the 10 open holds, and use the "Update hold(s)" button, those 10 suspensions would apply to the 10 found holds and not the holds they should apply to!

Test Plan:
1) Place two holds on a record
2) Check in an item and trap it for the first hold
3) Now that one hold is waiting and the other is not, attempt to set
   a suspension date using the "Update hold(s)" button
4) Note your hold does not get suspended!
5) Apply this patch
6) Restart all the things!
7) Repeat steps 1-3
8) Your hold should now be suspended!

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-03-06 09:56:40 +00:00
11b44869d9
Bug 14711: Change prototype for AddReserve - pass a hashref
The number of parameters of AddReserve makes it hard to read and
maintain.
This patch replace it with a hashref, which will make the calls more
readable.

Moreover the bibitems has been removed as it was not used by the
subroutine.

Test plan:
- Make sure the tests pass
- Read the diff and search for typos
- Place a hold on few items

Note for QA: reservation_date and expiration_date do not match the DB column's names,
should we?

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-11 14:32:47 +00:00
1e2617342a
Bug 24485: Allow hold when some can be overridden
The check to see if we can place a hold counts the number that we can override vs the number of items on the record.

We cannot override if we already have a hold on an item, however, we don't count these to see if they plus
the number of overrides equal the items on the record.

To test:
1 - Set max reserves to 2, allow 2 holds per recrod
2 - Place 2 holds for a patron on some records
3 - Find another record with 2 items
4 - Place a hold on the first item, you will be notified about the limit but you can override
5 - Attempt to place hold on second item, cannot be done, button disabled
6 - Apply patch
7 - Repeat
8 - You can place the second hold

Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-05 12:32:31 +00:00
Jesse Weaver
1c43a26525
Bug 18936: (follow-up) Fix tests, replace old get_onshelfholds_policy method
Signed-off-by: Minna Kivinen <minna.kivinen@hamk.fi>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-04 09:56:25 +00:00
23bddb729d
Bug 22284: (QA follow-up) Make pickup locations be Koha::Library objects
This patch makes the following methods return array references of
Koha::Library objects instead or unblessed objects;

- Koha::Item->pickup_locations
- Koha::Biblio->pickup_locations
- Koha::Libraries->pickup_locations

Bonus:

- The template plugin is adjusted to unbless things to keep behavior
- Tests are moved to the right .t file.
- Tests for the new behavior are added.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-03 12:58:06 +00:00
Agustin Moyano
01cf725b99
Bug 22284: (follow-up) Squash multiple follow-ups
* Bug 22284: (follow-up) Use GetReserveControlBranch in Koha::Item->pickup_locations
  * Bug 22284: (follow-up) Fix tests
  * Bug 22284: (follow-up) Fix typo in request.tt
  * Bug 22284: (follow-up) Filter pickup on specific item click
  * Bug 22284: (follow-up) Fix typos transfered -> transferred

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-03 12:58:06 +00:00
Agustin Moyano
3b25ea7c94
Bug 22284: Add "patron's hold group" as new hold_fulfillment_policy option
This patch adds "patron's hold group" as a new option to Hold pickup library match

To test:
1. Set ReservesControlBranch preference to item.
2. Create a hold group
3. Go to circulation and fines rules
SUCCESS => in 'Hold pickup library match' there is a new option called "patron's hold group"
4. In a library not in hold group set 'Hold policy' to "any" and 'Hold pickup library match' to "patron's hold group"
5. Search for a user in the hold group
6. 'Search to hold' for items of the library of step 4
7. Select an item and 'Place hold for [user]'
SUCCESS => in 'Pickup at' you should see patron's hold group as options
8. In OPAC sign in as the same user of step 5
9. Search for the item in step 7
SUCCESS => in 'Pick up locations' you should see patron's hold group as options
10. Sign off

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-03 12:58:05 +00:00
Agustin Moyano
546a3b6d4d
Bug 22284: New message, new column and filter pickup locations in reserve/request.tt
This patch adds a new message to 'Hold' column in 'Place a hold on a specific item' table.

The message is "Cannot place hold from patrons's library". It appears when patron's homebranch is not in item's hold group, and hold_fulfillment_policy is set to 'holdgroup'.

This patch also adds a new column "Allowed pickup locations" that lists allowed pickup locations per item.

Finally, the select that displays pickup locations is filtered by allowed pickup locations, when multi_hold is not enabled

To test:
1) Apply this patch
2) In library groups add a root group and check it as hold group.
3) Add two libraries to the group
4) In circulation and fines rules, in 'Default checkout, hold and return policy', in Hold policy change the value to 'From local hold group'
5) Search a patron from a different library than step 3, select one and click 'search to hold'
6) Search by location for items in any library of step 3
7) On any item, clic on 'Place hold for ...'
SUCCESS => when the page is loaded, in the 'Place a hold on a specific item', you should see the message "Cannot place hold from patrons's library" in 'Hold' column
	=> You should see a new column called "Allowed pickup locations" and the message is "Any library"
8) In circulation and fines rules, in 'Default checkout, hold and return policy', in 'Hold policy' change the value again to 'From any library' and change 'Hold pickup library match' to "Item's hold group"
8) Repeat steps 5 to 7
SUCCESS => when the page is loaded, you should see the "Pickup at" select filtered by libraries in hold group
	=> You should see in "Allowed pickup locations" a coma separated list of the libraries in item's hold group
	=> If biblio has an item whose control branch is not in a hold group, you should see the control branch name in "Allowed pickup locations"
9) Sign off

Sponsored-by: VOKAL
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-01-03 12:58:05 +00:00
ad3e5bae0c
Bug 24168: (bug 23116 follow-up) AllowHoldPolicyOverride allows a librarian to almost place a hold on an item already on hold
This patch actually fixes the issue described on bug 23116.

Test plan:
See bug 23116 and comment 5. Important to note that the later comparison with
itemAlreadyOnHold assumes that the variable is a string.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-12-09 14:23:37 +00:00
Julian Maurice
08e7273c0f
Bug 22922: Use jQuery datepicker instead of <input type="date">
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-21 10:01:01 +01:00
Julian Maurice
95174eb36a
Bug 22922: Allow reservedate changes only if AllowHoldDateInFuture is on
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-21 10:00:49 +01:00
Julian Maurice
8d047f2a33
Bug 22922: Allow to modify hold dates on reserve/request.pl
Test plan:
1. Place some holds
2. Go to the 'Holds' tab of the biblio record
3. Modify dates in the table and click on 'Update holds' button
4. Verify that dates have been correctly updated

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-21 10:00:36 +01:00
Agustin Moyano
7aeec1bfef
Bug 19618: Add ability to place holds for members of a club in intranet
This patch adds the ability to place a hold for each member of a club in random order.

To test:
1) apply this patch
2) create 2 clubs, (club names should have some part in common, and some part different for each other)
3) in one of them add at least 6 members
4) enter patron clubs management and click on "Actions" button
SUCCESS.1 => club with members has a new action called "search to hold"
5) click on search to hold
SUCCESS.2 => in the list of bilios there appears an action called "Place hold for <club name>"
6) click on "Place hold for <club name>"
SUCCESS.3 => a new window appears where you can select pickup location (defaults to club's library, if any), and the list of members.
7) go back to the list of bilios in the catalog and click on "Forget <club name>"
8) click on "Holds" action of any biblio
SUCCESS.4 => a search box appears with two tabs: Patrons and Clubs
9) click on Clubs tab and search by the common part of clubs names
SUCCESS.5 => a list of clubs that matches the search appears. If you click on any of them, the same page as SUCCESS.3 appears.
10) go back to the search box in SUCCESS.4 and search by the different part of the name.
SUCCESS.6 => because there is only one club that matches search criteria, the same page as SUCCESS.3 appears;
11) Sign off

Sponsored-by: Southeast Kansas Library - SEKLS
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-10-01 08:05:57 +01:00
Ere Maijala
a1a05db1b6
Bug 11529: Add templates for biblio title display. Unify display.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-05 15:03:19 +01:00
Ere Maijala
ee44dce285
Bug 11529: Clean up subtitle usage
Unify and clean up subtitle usage so that it's always used as a simple array and not the old hash structure.

Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-08-05 15:03:18 +01:00
Katrin Fischer
d7e6ae38e4
Bug 22021: Improve item status display when placing holds in staff
This patch is a bit of a clean-up to bring the item status display
more in line with the display on the detail page:

- show descrpition of authorised value for not for loan instead of hardcoded text
- Show description of authorised value for lost instead of hardcoded text
  This is also a translatability fix, as the text came from the .pl
- Show description of authorised value damaged instead of hardcoded text
- Make sequence of status match display on details page:
  lost - damaged - not for loan

To test:
- On a record with multiple items
  - Add different status to the items
    damaged, lost, not for loan
  - Make sure you have items with one status and multiple status at the same time
- Look at how the status display on the detail page
- Place a hold, compare display
- Apply patch
- Repeat

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-07-19 13:55:53 +01:00
2c5e9bed7d
Bug 23116: AllowHoldPolicyOverride allows a librarian to almost place a hold on an item already on hold
A library appears to be able to place a second item level hold on an item a patron already has on hold if
A) AllowHoldPolicyOverride is enabled
and
B) the circ rule allow for multple item level holds.

Once the patron submits the hold requests though, the hold does not get stored in the database.

Because allowing two item level holds for the same item makes no sense, we should not allow
this attempt to take place, even if AllowHoldPolicyOverride is enabled.

Test Plan:
 1) Enable AllowHoldPolicyOverride
 2) Set up circ rules to allow for multiple item level holds on one record
 3) Place an item level hold on a record
 4) Note you can force placing a second item hold on that reocrd
 5) Attempt to do so, it will not actually work
 6) Apply this patch
 7) Note you can no longer place another item level hold for the same item
   you just placed an item-level hold on
 8) Note you can still force holds that contravene the circ rules for
   any and all other reasons
 9) Test with record level holds
10) Test by placing multiple holds from search results

Signed-off-by: Martha Fuerst <mfurest@hmcpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Simple fix for a regression. Works as expected.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2019-06-25 16:48:20 +01:00
917a506ffc Bug 19302: Send koha::objects to C4::Reserves::IsAvailableForItemLevelRequest
Almost everywhere we call IsAvailableForItemLevelRequest we already have
a Koha::Patron and Koha::Item object. It makes sense to use them to
avoid a refetch

Test plan:
It would be good to test this patch on top of 19300 and 19301 and make
sure everything works as expected

Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-05-10 18:57:20 +00:00
4560d96236 Bug 21036: Fix uninitialized value within @itemnumber in string ne
Line from 16.11 log:
Use of uninitialized value within @itemnumber in string ne at /usr/share/koha/prodclone/reserve/modrequest.pl line 70.

Test plan:
Read the change. Not 100% identical (numeric zero) but should be enough.
This line is probably not needed at all.

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-05-07 11:39:24 +00:00
aa75553c3a Bug 20421: Inform staff that patron does have the title checked out during placing hold
Test plan:
1) Enable the CheckPrevCheckout and DisplayMultiPlaceHold system preferences
2) Have a patron with some checkouts history
3) Try to place hold on one of titles from history for this patron
4) You should see an information at the top of confirm request page, but
you still should be able to place a hold
5) Try this with multiple titles - one or more of them should be from
history
6) You should see this information in "Information" column
7) There is also new column placed at the beggining with checkbox, you
could uncheck it for titles you do not want to place a hold on it
8) Confirm the hold is placed only on checked titles

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Bin Wen <bin.wen@inlibro.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-29 13:35:35 +00:00
ef5adaff5a Bug 22650: Prevent multiple holds on individual items
This patch corrects a missing id on the holds_to_place field and adds code to disable the box when an item is checked

Additionally script login now places a single hold if an itemnumebr is passed and checks for holdability of the specific item

To test:
 1 - Allow multiple holds per record in circ rules
 2 - In staff client, go to place a hold on a record
 3 - Select a patron
 4 - Increase the number of holds
 5 - Then select a specific item to hold
 6 - Patron now has multiple holds on a single item
 7 - Apply patch
 8 - Repeat, notice that count is disabled when item checked
 9 - Confirm count is enabled when 'Hold next available item' is checked
10 - Set number to more than 1
11 - Check an item and submit
12 - Confirm only one item is reserved
13 - Hit the script directly (with valid info):
     http://localhost:8081/cgi-bin/koha/reserve/placerequest.pl?biblionumber=1&checkitem=1&holds_to_place_count=2&borrowernumber=5
14 - Confirm only one hold is placed
15 - Confirm multiple hits of the url do not generate further holds

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-25 10:24:19 +00:00
fa53eb4cfa Bug 17978: Check if hold can be placed before placing on placerequest.pl
To test:
 1 - Set an All/All/All rule with reserves limited 2 to
 2 - Search in the staff side
 3 - Select all records (or more than 2) from the results
 4 - Click 'Place hold'
 5 - Find a patron, place holds
 6 - You get more holds than you should
 7 - Delete those holds
 8 - Apply patch
 9 - Search and select more than 2 records
10 - Find patron, place holds
11 - Only 2 holds are placed

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-10 19:59:28 +00:00