Commit Graph

296 Commits

Author SHA1 Message Date
Jonathan Druart 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
Nick Clemens a2b805a0df Bug 14576: (follow-up) Using item objects, not hashrefs
Signed-off-by: Liz Rea <wizzyrea@gmail.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-25 11:36:24 +00:00
Hayley Mapley 23a12cf4d8 Bug 14576: Replaced calls using deprecated method GetItem with Koha::Items->find
Test plan:
1) Apply all patches except this one
2) Checkout out an item to a patron
3) Check the item in - note that this will fail
4) Apply this patch, and repeat steps 1-3, noting instead that the the
check is instead successful
5) Verify also that reserves act as expected
5) Sign off

Sponsored-by: Catalyst IT

Signed-off-by: Liz Rea <wizzyrea@gmail.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-25 11:36:24 +00:00
Nick Clemens 78a7d5aada Bug 14576: Allow arbitrary automatic update of location on checkin
This patch adds a new syspref "UpdateItemLocationOnCheckin" which
accepts pairs of shelving locations.  On check-in the items location is
compared ot the location on the left and, if it matches, is updated to
the location on the left.

This preference replaces ReturnToShelvingCart and
InProcessingToShelvingCart preferences.  The update statement should
insert values that replciate these functions.  Note existing
functionality of all items in PROC location being returned to
permanent_location is preserved by default.  Also, any items issued from
CART location will be returned to their permanent location on issue (if
it differs)

Special values for this pref are:
_ALL_ - used on left side only to affect all items
_BLANK_ - used on either side to match on/set to blank (actual blanks
        will work, but this is an easier to read option)
_PERM_ - used on right side only to return items to permanent location

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Set the new system preference UpdateitemLocationOnCheckin
   to the following (assuming sample data):
   NEW: FIC
   FIC: GEN
4) Create an item, set its location to NEW
5) Check in the item, note its location is now FIC
6) Check in the item again, note its location is now GEN
7) Check in the item again, note its location remains GEN
8) Test using _ALL_, _BLANK_ and _PERM_ for updates
9) Try entering various incorrect syntax in the pref and note you are warned

Sponsored by:
    Arcadia Public Library (http://library.ci.arcadia.ca.us/)
    Middletown Township Public Library (http://www.mtpl.org/)
    Round Rock Public Library (https://www.roundrocktexas.gov/departments/library/)

Signed-off-by: Michal Denar <black23@gmail.com>

Signed-off-by: Liz Rea <wizzyrea@gmail.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-25 11:36:23 +00:00
Nick Clemens bf1100fbf1 Bug 20837: Use ReservesControlBranch to determine holdability of items
To test:
 1 - Set a default holds plicy for an item type as 'from home library'
 2 - Set CircControl to 'logged in library'
 3 - Log in as staff from a library without the rule set
 4 - Note you can set holds for patrons of any library on items of type
above
 5 - Toggle ReservesControlBranch and note that nothing changes
 6 - Toggle CircControl and note some combinations don't allow holds
 7 - Apply patch
 8 - Toggle ReservesControlBranch and note that holdability is affected
 9 - Toggle CircControl and note holdability does not change
10 - Read the note on admin/smartrules.pl and confirm it makes sense

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:26:22 +00:00
Owen Leonard 30ab16657b Bug 12166: Improve display of Reserve charges in patron account
This patch makes changes to the way hold fees are recorded and displayed
in the OPAC and staff client:

 - No English strings should be stored in the accountline description.
 - The accounttype code should be used to display what kind of charge it
   is.

To test, apply the patch and go to the staff client:

 - Configure a patron category to have a hold fee.
 - Place one or more holds for a patron in that category.
 - On the patron's record, view Accounting -> Make a payment
   - There should be a separate column for "Account type" showing "Hold
     fee" for the hold charges.
   - There should be no "Res" or "Reserve Charge" text in the
     description column--just the title.
 - Switch to the "Transactions" tab. The display should be similar.
 - In the OPAC, log in as a patron who has hold fees on their account.
   - View the "your fines" page to confirm that the information is
     displayed correctly there as well.

 - Place a hold for a patron who incurs hold charges.
 - Log in to the self-checkout module as that patron and check out an
   item which will fulfill that hold.
 - The correct fine information should be saved to accountlines: A "Res"
   type with a description consisting only of the title.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-11 12:16:19 +00:00
Kyle M Hall d7a5925aa0 Bug 17978: Circ rules will not limit holds
The crux of this issue is that all those holds are unfilled record level holds. The code that checks for the number of holds the user already has *always* uses a branchcode of some form. Because of this, any open record level holds are completely ignored for this purpose.

Test Plan:
1) Set ReservesControlBranch to "item's home library"
2) Set an All libraries/All Patrons/All itemtypes rules limiting a patron to 2 holds
3) Place 3 record level holds, you can but you should not be able to!
4) Delete the holds
5) Apply this patch
6) Attempt to place 3 record level holds
7) Note that you cannot!

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

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

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
Martin Renvoize 9ec4d86636 Bug 22600: Add 'interface' to accountlines
This patch adds the 'interface' field to the accountlines table and
updates all Koha::Object routines and calls to use it.

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

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-04-10 19:43:11 +00:00
Martin Renvoize d522d80c5c Bug 22593: Fix bad ternaries after bug 22008
A series of ternaries were introduced when we moved to add_debit which
defaulted to 'user 0' should a userenv not be set.  This was incorrect
as userenv may well not be set (during cronscript runs for example) and
the new constraint would not allow such a default. We switch to 'undef'
here to satisfy the constraint.

Test plan
1) Ensure you have data in your system that would be caught by the
longoverdues cronjob.
2) Ensure you're sysprefs are setup to charge for lost items
3) Run the script and varify it runs to completion without errors

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

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

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-28 13:40:44 +00:00
Kyle M Hall dbcd0511e7 Bug 22330: (QA follow-up) Remove duplicate use lines, combine and sort remaning lines
Signed-off-by: Liz Rea <wizzyrea@gmail.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-21 16:22:56 +00:00
Kyle M Hall a57723fc59 Bug 22330: Transfer limits should be respected for placing holds in staff interface and APIs
Branch transfer limits are respected for placing holds in the OPAC but nowhere else. This should be remedied.

Test Plan:
1) Set up a branch transfer limit from Library A to Library B
2) Verify you cannot set up a hold for an item from Library A for pickup at Library B from the staff interface ( without overriding )
3) Verify you cannot place that hold via ILS-DI
4) Verify you cannot place that hold via SIP
4) Verify a forced hold from Library A to Library B will not show up in the holds queue

Signed-off-by: Liz Rea <wizzyrea@gmail.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-21 16:22:56 +00:00
Martin Renvoize e7dbe41242 Bug 21728: Use Koha::Account->add_debit in ChargeReserveFee
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-03-04 19:08:25 +00:00
Tomas Cohen Arazi 7c3a5c78c1 Bug 21765: Make AutoUnsuspendReserves call Koha::Hold->resume
This patch makes the mentioned method use the biult-in method for
resuming a suspended hold, instead of manually setting the specific
attributes using the accessors.

The side effect for this is that HoldsLog is now honoured.

This patchset also refactors the tests a bit so they rely on the exposed
methods and thus don't rely on specific implementation details (like
suspended hold means a date in suspended_until plus suspended=1).

To test:
- Apply the regression tests patch
- Run:
  $ kshell
 k$ prove t/db_dependent/Reserves/AutoUnsuspendReserves.t
=> FAIL: It fails loudly because things are done manually
- Apply this patch
- Run:
 k$ prove t/db_dependent/Reserves/AutoUnsuspendReserves.t
=> SUCCESS: Tests pass!

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

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-02-27 09:14:21 -05:00
Jonathan Druart 31c29fd31f Bug 21206: Replace C4::Items::GetItem
Note: This is here for information purpose, feel free to test it if you
wan to play with it.

TODO: C4::Reserves::_get_itype is not longer in use

No more GetItem must be returned by:
git grep GetItem|grep -v GetItemsAvailableToFillHoldRequestsForBib|grep
-v GetItemsForInventory|grep -v GetItemsInfo|grep -v
GetItemsLocationInfo|grep -v GetItemsInCollection|grep -v
GetItemCourseReservesInfo|grep -v GetItemnumbersFromOrder|grep -v
GetItemSearchField|grep -v GetItemTypesCategorized|grep -v
GetItemNumbersFromImportBatch|cut -d':' -f1|sort|uniq

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-02-26 13:24:07 +00:00
Alex Arnaud 102b1ca4bf Bug 21738: make call of CanBookBeReserved more safe
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

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

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-02-08 20:44:07 +00:00
Kyle M Hall 2c2d0cd699 Bug 7614: (QA follow-up) Fix POD merge missed in rebase
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-25 16:06:42 +00:00
Lari Taskula b028a2d1a5 Bug 7614: Check transfer limit in CanBookBeReserved and CanItemBeReserved
This patch adds $branchcode_to parameter to CanBookBeReserved and
CanItemBeReserved. It represents the pickup location for the hold. This patch
checks if the library is configured to be a pickup location (see Bug 7534), and
also if the item can be transferred into the given library (see Bug 18072).

To test:
1. prove t/db_dependent/Holds.t

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-25 14:46:58 +00:00
Tomas Cohen Arazi 48dab3c126 Bug 19066: (QA follow-up) Fix ChargeReserveFee
This patch fixes a bug in ChargeReserveFee:

To test:
- Run:
  $ kshell
 k$ prove t/db_dependent/Reserves.t
=> FAIL: Tests fail because branchcode is not set
- Apply this patch
- Run:
 k$ prove t/db_dependent/Reserves.t
=> SUCCESS: Tests pass!

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-03 18:58:41 +00:00
Kyle M Hall 897ddc82b3 Bug 19066: Add branchcode to accountlines
For the purposes of statistics, it appears that it would help many
libraries to have branchcode recorded in the accountlines table. For
payments, the field would contain the code for the branch the payment
was made at. For manual invoices, it would be the code of the library
that created the invoice.

Test Plan:
1) Apply this patch set
2) Create and pay some fees
3) Note the branchcode for those fees and payments is set
   to your logged in branch

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2019-01-03 18:58:38 +00:00
Tomas Cohen Arazi c5641af82a Bug 15486: (follow-up) Default to unlimited
While it doesn't have a practical effect (the variable is reset several
lines below) I agree this should be explicitly set to its default.

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

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-10-24 13:24:06 +00:00
Tomas Cohen Arazi fb0ab55fd0 Bug 15486: Extend CanItemBeReserved so it handles daily holds limits
This patch implements the required changes in
C4::Reserves::CanItemBeReserved so it implements a daily limit on holds.

It returns the 'tooManyReservesToday' string if the policy doesn't allow
placing the hold. It returns 'OK' (current behaviour) otherwise.

To test:
- Run:
  $ sudo koha-shell kohadev
 k$ cd kohaclone
 k$ prove t/db_dependent/Holds.t
=> FAIL: Tests fail because the error condition is not making
CanItemBeReserved return the desired error code.
- Apply this patch
- Run:
 k$ prove t/db_dependent/Holds.t
=> SUCCESS: Tests pass!
- Sign off :-D

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-10-24 13:24:05 +00:00
Jonathan Druart f185785b8c Bug 18887: Insert undef instead of '*'
Koha::CirculationRules->get_effective_rule will become the method to
call to retrieve a specific rule, we should start using it when
possible.

Moreover undef could replace '*' to mean 'any', that way we will be able
to add FK on circulation_rules

TODO: Add more tests

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Jesse Maseto <jesse@bywatersolution.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-10-03 17:58:14 +00:00
Kyle M Hall b9727d2058 Bug 18887: (follow-up) Fix null/empty behavior
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Jesse Maseto <jesse@bywatersolution.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-10-03 17:58:13 +00:00
Kyle M Hall 35265c0a9b Bug 18887: Port max_holds rules to new CirculationRules system
This is the first step in the circulation rules revamp as detailed
in the RFF https://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC

This patch moves the recent max_holds rule to the new circulation_rules table.

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Go to the circ rules editor, note the new max holds rules
   by patron category in the "Checkout limit by patron category".
   ( Should we rename this section? )
4) Create find a patron that is allowed to place a hold, count the
   number of holds that patron has. Lets make that number 'X'.
5) Set the new max holds rule to X for "All libraries"
6) Note the patron can no longer place another hold
7) Set the new max holds rule to X + 1 for the patron's home library
8) Note the patron can again place another hold
9) Set the new max holds rule to X for the patron's home library
10) Note the patron can no longer place another hold

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>

Signed-off-by: Jesse Maseto <jesse@bywatersolution.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-10-03 17:58:12 +00:00
Kyle M Hall 42c94d185a Bug 19469: Add ability to split view of holds view on record by pickup library and/or itemtype
It is possible to set up circulation rules to limit trapping of holds by pickup library and itemtype.
To make it easier to understand which holds will be trapped in a given circumstance,
it would be nice if we could optionally group holds by pickup library and/or itemtype.

Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Enable AllowHoldItemTypeSelection
4) Pick a record and create holds with various pickup libraries and itemtype combinations
5) Enable HoldsSplitQueueNumbering
6) Try the different combinations of HoldsSplitQueue
7) Ensure the hold "arrows" move the items correctly
   * Up and down arrows should move hold above or below the adjacent hold within a hold fieldset
   * Top and borrom arrows should move hold to the top or bottom within a hold fieldset

Sponsored-by: Stockholm University Library

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

Followed test plan, patch worked as described. Also passed QA test tool

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-09-14 17:36:32 +00:00
Nick Clemens b40070f4ad Bug 7534: (RM follow-up) Fix tests and adjust after bug 15524
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-09-06 17:32:26 +00:00
Kyle M Hall 3afbe3cf5d Bug 7534: Disambiguate branchcode parameter, make it match between subroutines
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-09-06 17:32:26 +00:00
Lari Taskula ce411c186d Bug 7534: Validate pickup location in CanBook/ItemBeReserved
This patch adds $branchcode_to parameter to CanBookBeReserved and
CanItemBeReserved. It represents the pickup location for the hold.

To test:
1. prove t/db_dependent/Holds.t

Signed-off-by: Koha Team AMU <axelle.clarisse@univ-amu.fr>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-09-06 17:32:25 +00:00
Jonathan Druart 02633edc7d Bug 21201: Replace C4::Items::GetItemnumbersForBiblio calls
Those calls to C4::Items::GetItemnumbersForBiblio can be replaced with
    my @itemnumbers = Koha::Items->search({ biblionumber => $biblionumber})->get_column("itemnumber")

Test plan:
- Use the GetAvailability service of ILS-DI
- Try to place a hold on an item that is available and another one
- Use the batch record deletion tool to remove record with and without items.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-31 10:44:04 +00:00
Nick Clemens 5bdf9acf67 Bug 15524: (RM follow-up) Fix calls and add filter
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-24 16:27:27 +00:00
Kyle M Hall 5f485e476b Bug 15524: (QA follow-up) Change Can[Book|Item]BeReserved to return hashref, pass limit to template
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-24 16:27:27 +00:00
Kyle M Hall 27b2b0bb95 Bug 15524: (QA follow-up) Respect ReservesControlBranch
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-24 16:27:26 +00:00
Kyle M Hall 7e956e85b1 Bug 15524: Set limit on maximum possible holds per patron by category
It's possible to set a limit on the maximum number of holds for a particular branch/category/itemtype, but not on the total number of holds for a given patron (by branch/category).
This new rule works in conjunction with the existing branch/borrower/item rules in that Koha will use the lower of the two limits. This new rule counts all holds of all types, which prevents bib-level holds from not being counted for the purpose of these limits. This makes the most sense and was also requested by the sponsor.

Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Go to the circ rules editor, note the new max holds rules
   by patron category in the "Checkout limit by patron category".
   ( Should we rename this section? )
4) Create find a patron that is allowed to place a hold, count the
   number of holds that patron has. Lets make that number 'X'.
5) Set the new max holds rule to X for "All libraries"
6) Note the patron can no longer place another hold
7) Set the new max holds rule to X + 1 for the patron's home library
8) Note the patron can again place another hold
9) Set the new max holds rule to X for the patron's home library
10) Note the patron can no longer place another hold

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-24 16:23:27 +00:00
Nick Clemens c0f7aed84d Bug 21075: AutoUnsuspendHolds should unsuspend holds <= today
To recreate:
 1 - Place a hold in your system
 2 - Set that hold (or all holds) to expire today
    update reserves set suspend_until=CONCAT( CURDATE()," 00:00:00");
 3 - Run misc/cronjobs/holds/auto_unsuspend_holds.p
 4 - Note the hold is sitll suspended
 5 - Visit /cgi-bin/koha/reserve/request.pl for the book with the hold
 6 - Note the suspend date is tomorrow (and cannot be set to today]
 7 - Click update holds - the date in db is now set to tomorrow
 8 - Reset to today
 9 - Apply patch
10 - Run the cron again
11 - Visit the page and note hold is unsuspended

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-08-08 21:07:15 +00:00
Kyle M Hall 777b24bbb4 Bug 17561: (QA follow-up) Simplify new ReserveSlip code
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-06-04 13:40:37 -04:00
Benjamin Rokseth 2c1f7d2281 Bug 17561: ReserveSlip needs itemnumber for item level holds on same biblio
This patch fixes a regression after bug 14695.
This patch adds itemnumber and barcode as optional params in ReserveSlip used
by hold-transfer-slip.pl to generate HOLD_SLIP. This is for ReserveSlip to be
able to generate correct slips when items in multi-item holds are checked in.

Test plan:

1) activate a circulation rule with multi-item holds
2) Place two holds on same biblio for patron
3) for debugging, either use browser console to observe POST request and responses
   or use info from reserves, e.g. reserve_id in the HOLD_SLIP
4) checkin two items from same biblio on pickup branch
5) note that both holds are effectuated, but reserve_id is the same on both slips
6) also note that there is no itemnumber or barcode in the requests from returns.pl
7) Apply this patch
8) repeat 2-4
9) note that reserve_id is now different on the two slips

and/or:
Run tests:
  t/db_dependent/Reserves/ReserveSlip.t

Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Maksim Sen <maksim.sen@inlibro.com>

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

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

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
2018-06-04 13:40:36 -04:00
Jonathan Druart 1798d22e76 Bug 20724: Move the ReservesNeedReturns logic to AddReserve
Signed-off-by: Victor Grousset <victor.grousset@biblibre.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-05-16 10:53:13 -03:00
Kyle M Hall c585f11497 Bug 20724: Correctly mark an hold as waiting - ReservesNeedReturns
We need to call Koha::Hold->set_waiting to correctly
calculate the expiration date.

It fixes a regression introduced by
  commit 26634151db
  Bug 12063 - Fix QA failures

The expiration date has to be set for waiting holds

== Test plan (time to execute: less than 4min) ==
1. Set ReservesNeedReturns to "Don't automatically"
2. Place a hold on a specific item
3. Check it in and confirm hold
4. The hold should have an expiration date
     record page → Hold → "Expiration" column
5. It should be listed in staff:/cgi-bin/koha/circ/waitingreserves.pl
6. Set ReservesNeedReturns to "Automatically"
7. Place a hold on a specific item
    (which should also behave like we check the item in to
    keep it for the patron)
8. The hold should have an *empty* expiration date
     record page → Hold → "Expiration" column
9. Holds awaiting pickup page should crash
     staff:/cgi-bin/koha/circ/waitingreserves.pl
10. Cancel the hold to remove the corrupted data
     record page → Hold → the red X
11. Apply this patch
12. Place a hold on a specific item
13. The hold should have an expiration date (not empty)
14. It should be listed in staff:/cgi-bin/koha/circ/waitingreserves.pl
15. Celebrate!

Signed-off-by: Victor Grousset <victor.grousset@biblibre.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-05-16 10:53:13 -03:00
Jonathan Druart c06bc6422f Bug 19301: Remove C4::Reserves::OnShelfHoldsAllowed
At this point the subroutine is not used anymore

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-13 13:36:00 -03:00
Jonathan Druart 39e1fbcbe9 Bug 19301: Move C4::Reserves::OnShelfHoldsAllowed to get_onshelfholds_policy
Following the pattern introduced by bug 19300, we are going to move the
OnShelfHoldsAllowed logic to Koha::IssuingRules->get_onshelfholds_policy

Test plan:
Make sure the onshelfholds policy is correct when placing a hold

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-13 13:36:00 -03:00
Marcel de Rooy 7ac45d00b6 Bug 4319: (QA follow-up) Consistency in IsAvailableForItemLevelRequest
[1] For consistency going back to IsItemOnHoldAndFound in this sub.
    This call is used in the on_shelf_holds == 2 case too.
    The routine will be refactored quite soon.
    Adding the else branch for on_shelf_holds == 0 for more clarity.
[2] Removing the test for found==F in reserves. In Koha F is only used
    when the hold is filled and moved to oldreserves.

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-13 13:02:23 -03:00
Alex Arnaud a9779b67d6 Bug 4319: [OPAC] Allow holds on waiting/transit items
Test plan:

 - Checkout an item
 - Place hold on this item,
 - Return the item
 - Make sure the hold is waiting (found W) and AllowOnShelfHolds is
   not to 'Allow'
 - Check that the button "Place hold" appears in opac detail page of
   the biblio

 - do the samewith items/reserves in transit

Changes on C4::Reserves::IsAvailableForItemLevelRequest

Make sure this tests pass:
  - t/db_dependent/Reserves.t
  - t/db_dependent/Holds/DisallowHoldIfItemsAvailable.t

Rebased - 2017-12-12 - Alex Arnaud

Bug 4319 - [QA fix] Create Koha::Biblio->hasItemswaitingOrInTransit

Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-02-13 13:02:23 -03:00
Jonathan Druart 3a5534fcf5 Bug 19304: Move C4::Members::GetNoticeEmailAddress to Koha::Patron->notice_email_address
This subroutine is quite trivial and can be replaced easily with a new
method of Koha::Patron

Test plan:
Overdue notices and shelf sharing must be send the to an email address,
according to the value of the pref AutoEmailPrimaryAddress

Signed-off-by: David Bourgault <david.bourgault@inlibro.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-01-02 11:46:40 -03:00
Jonathan Druart 19e5eeb8e5 Bug 19300: Replace C4::Reserves::OPACItemHoldsAllowed - Remove the subroutine
At this point the subroutine is not longer in use, we can remove it

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-01-02 11:46:40 -03:00
Jonathan Druart e110f90c34 Bug 19299: Replace C4::Reserves::GetReservesForBranch with Koha::Holds->waiting
GetReservesForBranch simply returns the waiting holds, for a specific
branch of not. This can easily be replaced with a call to
Koha::Holds->waiting

To avoid any regressions, I reuse the exact conditions (priority = 0),
but I do not think it is useful.

Test plan:
Make sure the holds information are correctly displayed on the waiting
holds screen.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-12-11 11:34:19 -03:00
Jonathan Druart d5a6179852 Bug 19766: (bug 19058 follow-up) Fix Preview routing slip
This patch fixes the following errors:
The method reserve_id is not covered by tests at /home/vagrant/kohaclone/C4/Reserves.pm line 859.
The method set is not covered by tests at /home/vagrant/kohaclone/C4/Reserves.pm line 871.
Can't call method "store" on an undefined value at /home/vagrant/kohaclone/C4/Reserves.pm line 871.

This is caused by
  commit ba1f2f93ef
    Bug 19058: Move C4::Reserves::GetReserveId to the Koha namespace

We are calling ->reserve_id on a Koha::Holds set.

Test plan:
- Serials -> Find subscription -> "Edit routing list" in the sidebar
- Add 1+ recipients
- Save -> "Save and preview routing slip"

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

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-12-07 09:37:01 -03:00
Mirko Tietgen eba47394d1 Bug 18547: On shelf holds allowed > "If all unavailable" ignores default hold policy
If in the circ rules matrix you set "On shelf holds allowed" to "If all unavailable",
default hold policy "From home library" is ignored.

Test plan:

- Have a test user from one branch (eg Centerville)

- Set "On shelf holds allowed" to "If all unavailable" for your patron and item
  category (or everyone and everything)
- For "Default checkout, hold and return policy", set hold policy to "From home library"
  -> make sure there is no "Default holds policy by item type" to override the setting

- Have two items for a record.
  1. An item with home branch same as test user (eg Centerville)
  -> check this item out to somebody else
  2. an item with a different home branch (eg Fairfield)
  -> available, not checked out
- Try to place a hold for your test user. Does not work.

- Apply the patch
- Try to place a hold. Should work now.

Followed test plan, worked as intended
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

Followed test plan in the intranet and OPAC, worked as intended.
With few assumptions made:
- when the hold works, should be on the item 1 (Centerville)
  item 2 is only there to trigger the bug
- the circ rules were identically setup on each branch and in "Standard rules for all libraries"
Signed-off-by: Victor Grousset <victor.grousset@biblibre.com>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-11-26 11:30:17 -03:00
Marcel de Rooy 3cf0caf05c Bug 19260: [QA Follow-up] Remove obsolete $dbh
The variable is no longer used.
Removed a few empty lines on the way.

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-06 11:27:01 -03:00
Josef Moravec 49c879150d Bug 19260: Holds marked as problems being seen as expired ones and deleted wrongly
Test plan:
0) Apply just the first patch - the one with test
1) Run t/db_dependent/Reserves.t - test for CancelExpiredReserves should
fail
2) Apply the second patch
3) t/db_dependent/Reserves.t should pass now

Followed test plan, patch worked as described. Passes QA test tool

Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-10-06 10:59:41 -03:00
Josef Moravec 80fd5cd0db Bug 19116: Hold not set to waiting after transfer
Test plan:

0) Do not apply the patch
1) Place hold on item from another branch
2) Switch to that branch
3) Check them in at the other branch to set them into transport status (T)
4) Switch back to your homebranch
5) Check items in again, use the different confirm buttons and
    compare: Only "confirm and print" will be set to waiting, "confirm"
    remains in transport.
6) Apply the patch
7) Repeat 1-5 - now should work as expected - the hold is marked waiting
on "confirm" button too
8) Check the hold from the same branch, to make sure this doesn't add
regression

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

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

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2017-09-29 12:20:52 -03:00