Commit graph

169 commits

Author SHA1 Message Date
ebccf4099f Bug 5786 [QA Followup]
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-03-25 10:33:31 -03:00
Srdjan
1802aa9153 Bug 5786 - Move AllowOnShelfHolds and OPACItemHolds system prefs to the Circulation Matrix
C4::Reserves:
* Added OnShelfHoldsAllowed() to check issuingrules
* Added OPACItemHoldsAllowed() to check issuingrules
* IsAvailableForItemLevelRequest() changed interface, now takes
  $item_record,$borrower_record; calls OnShelfHoldsAllowed()

opac/opac-reserve.pl and opac/opac-search.pl:
* rewrote hold allowed rule to use OPACItemHoldsAllowed()
* also use OnShelfHoldsAllowed() through
* IsAvailableForItemLevelRequest()

templates:
* Removed AllowOnShelfHolds and OPACItemHolds global flags, they now
  only have meaning per item type

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>

I have tested this patch left, right and upside down for the last
several months. All tests have passed.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-03-25 10:33:14 -03:00
fcaa6f35c0 Bug 13636 - Staff search results item status incorrect for holds
Imagine this scenario: we have one record with four items. Two of those
items are checked out, one of those items is a waiting hold, and one of
those items is available. We would expect to see this on the search
results page. Instead, we will see both non-checked out items as
unavailable due to waiting holds.

This is due to a semantic issue GetReserveStatus.
C4::Search::searchResults uses GetReserveStatus to get the reserve
status of each item, but unlike all other calls to the sub, this one
passes in not only itemnumber, but biblionumber.

When no reserve is found for the available item, the subroutine uses the
biblionumber to grab what is essentially an arbitrary reserve to use for
the status. This makes no sense and this functionality should be
entirely removed from the subroutine so regressions like this will be
prevented in the future.

Test Plan:
1) Create one record with 4 items
   a) check two of the items out to patrons
   b) set one of the items as a waiting hold
   c) leave the fourth item as available
2) Run a search where this record will be in the results list
3) Note that the results list 2 items on loan, two unavailable
4) Apply this patch, reload the search results
5) Note that the results list 1 available, 2 on loan, 1 unavailable

Signed-off-by: John Andrews <jandrews@washoecounty.us>
Signed-off-by: Sheila Kearns <sheila.kearns@state.vt.us>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Note: This is for the staff search result list!

Works as expected.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-02-11 10:20:35 -03:00
Jonathan Druart
0f406a840a Bug 12792: C4::Reserves breaks my vim syntax color
C4/Reserves.pm is unreadable with my vim configuration.
It appears I am the only one having this problem.
For an incomprehensible reason, a string constructs with
  qq/my string/;
completely breaks the syntax color for all the rest of the file (~2300l).
If I replace it with
  qq{my string};
all is fine!

Test plan:
launch
  git show HEAD
and verify this patch won't break anything.

Additionally, prove t/db_dependent/Reserves.t
This will trigger the three functions that were modified.
The prove currently fails on test 8, but the other succeeding
tests prove that this change is fine.

Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests pass on my installation.
No problems found.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2015-01-14 12:42:32 -03:00
Chris Cormack
ef6bc21b2c Bug 13368 Holds priority messed up on checkout
To Test

1/ Create 3 (or more holds) on one biblionumber, make sure at least
one item is not on loan
2/ Check out the not on loan item to a borrower (maybe number 2 in the
queue)
3/ Look in the database (or on the holds tab on the moredetail.pl)
notice the priorities have not been reordered
4/ Apply patch and try again, notice now they have

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

Confirmed the problem without the patch, and confirmed that the patch
corrects it.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-12-17 19:59:44 -03:00
e3fe0bdb31 Bug 13152 - Duplicate phone hold notices when using Talking Tech
If a library is using Talking Tech for phone notices, any waiting hold
phone notice will show up twice!

This is because Koha generates on at the time the hold is set to
waiting, and then the cronjob TalkingTech_itiva_outbound.pl generates
it's own notice as well.

The former notice will always have a status of 'pending', as the
TalkingTech_itiva_inbound.pl script will update the notice the outbound
script created.

The solution is to prevent Koha from creating a phone notice for waiting
holds if TT is enabled, and let the cron script do it.

Test Plan:
1) Enable Talking Tech from the system preferences
2) Set a hold waiting phone notice in the notices and slips editor
3) Choose a patron, enable hold phone notices for that patron
4) Place a hold for a patron, and check it in so it's marked as waiting
5) Note the phone notice generated for the patron
6) Apply this patch
7) Repeat step 4
8) Note that this time, a phone hold waiting notice is not generated

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Amends condition with an additional or statement. Shoudn't affect
anything but phone notices. Change appears logical.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-25 17:33:56 -03:00
3b300146b2 Bug 11634 [QA Followup 3] - Found holds should be considered unavailable
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-12 11:27:42 -03:00
ebf4350735 Bug 11634 - Allow renewal of item with unfilled holds if other available items can fill those holds
The current holds behavior in Koha allows a situation like this:
- Patron A has an item currently checked out.
- Patron B places a hold on the next available copy of that title.
- Then Patron A will not be able to renew his item, even if there are
  other available copies of that title that could potentially fill Patron
  B's hold.

Since this seems unfair to Patron A, we should allow renewal of items
even if there are unfilled holds, but those holds could all be filled
with currently available items.

Test Plan:
1) Apply this patch
2) Create a record with two items
3) Check out the item to a patron
4) Place a hold on the record
5) Note you cannot renew the item for the patron
6) Enable the new system preference AllowRenewalIfOtherItemsAvailable
7) Note you can now renew the item, as all the holds can be satisfied
   by available items.
8) Place a second hold on the record
9) Note you can no longer renew the item, as all the holds *cannot*
   be filled by currently available items

Signed-off-by: Holger Meissner <h.meissner.82@web.de>
Signed-off-by: Chris Rohde <crohde@roseville.ca.us>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-12 11:27:31 -03:00
3bc14af683 Bug 13116 [QA Followup] - Remove tabs, use unless instead of if
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-12 11:23:45 -03:00
Olli-Antti Kivilahti
51f0a0b722 Bug 13116 - Make it possible to propagate errors from C4::Reserves::CanItemBeReserved() to the web-templates.
This patch changes the way CanBookBeReserved() and CanItemBeReserved() return error
messages and how they are dealt with in the templates. This change makes it possible
to distinguish between different types of reservation failure.

Currently only two types of errors are handled, all the way to the user, from the CanItemBeReserved():
-ageRestricted
-tooManyReserves which translates to maxreserves

 #############
 - TEST PLAN -
 #############
((-- AGE RESTRICTION --))
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You get a notification, that placing a hold on ageRestricted material is
   forbidden. (previously you just got a notification about maximum amount of reserves reached)

((-- MAXIMUM RESERVES REACHED --))
0. Set the  maxreserves -syspref to 3 (or any low value)
STAFF CLIENT AND OPAC
1. Make a ton of reserves for one borrower.
2. Observe the notification about maximum reserves reached blocking your reservations.

((-- MULTIPLE HOLDS STAFF CLIENT --))
3. Observe the error notification "Cannot place hold on some items"

((-- MULTIPLE HOLDS OPAC --))
1. Make a search with many results, of which atleast one is age restricted to the current borrower.
2. Select few results and "Place hold" from to result summary header element.
       (Not individual results "Place hold")
3. Observe individual Biblios getting the "age restricted"-notification, where others can be
   reserved just fine.

Updated the unit tests to match the new method return values.
t/db_dependent/Holds.t & Reserves.t

Followed test plan. Works as expected and displays meaningful messages for the reason why placing a hold is not possible.

Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-12 11:23:41 -03:00
Olli-Antti Kivilahti
7767f2e53b Bug 13113 - Prevent juvenile/children from reserving ageRestricted material
There is no reason for underage borrowers to reserve ageRestricted material and
then be denied it's check-out due to ageRestriction.

This patch prevents reserving material for borrowers not suitably aged.

 # # # # # #
 # A PRIORI #
 # # # # # #
BOTH THE STAFF CLIENT AND THE OPAC
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You can reserve an ageRestricted Record with ease.
STAFF CLIENT ONLY
5. Check-in an Item from the ageRestricted Record and catch the reservation.
6. Check-out the ageRestricted Item for this underage Borrower.
7. You get a notification about being unable to check-out due to age restriction.
   How lame is that for a 12 year old?

 # # # # # # # #
 # A POSTERIORI #
 # # # # # # # #
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Check-out an ageRestricted Item for this underage Borrower.
4. You get a notification about having the maximum amount of reserves.
5. Place a hold for the underage Borrower for the ageRestricted Record.
6. You get a notification, that placing a hold on ageRestricted material is
   forbidden.

Includes Unit tests.

Followed test plan. Patch behaves as expected. (Note: Propagating error messages to template will be handled in Bug 13116 or 11999)

Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-11 09:53:55 -03:00
Jonathan Druart
659f7cd097 Bug 11126: qa follow-up
- use Modern::Perl;
- fix a typo
- remove an old comment

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-04 18:53:51 -03:00
3463dd2449 Bug 11126 [QA Followup] - Make reserves returned by _Findgroupreserve sorted by priority
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-04 18:53:43 -03:00
6b2d2abb19 Bug 11126 - Make the holds system optionally give precedence to local holds
This feature will allow libraries to specify that, when an item is returned,
a local hold may be given priority for fulfillment even though it is
of lower priority in the list of unfilled holds.

This feature has three settings:
* LocalHoldsPriority, which enables the feature
* LocalHoldsPriorityPatronControl, which selects for either tha patron's
  home library, or the patron's pickup library for the hold
* LocalHoldsPriorityItemControl, which selects for either the item's
  holding library, or home library.

So, this feature can "give priority for filling holds to
patrons whose (home library|pickup library) matches the item's
(home library|holding library)"

Test Plan:
1) Apply this patch
2) Run t/db_dependent/Holds/LocalHoldsPriority.t

Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-11-04 18:53:37 -03:00
Jonathan Druart
9daef6fb53 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>
2014-09-23 20:46:57 -03:00
Rafal Kopaczka
e9eef04b95 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>
2014-09-23 20:46:50 -03:00
Julian Maurice
45f474abdf Bug 8868: ILS-DI: CancelHold needs to take a reserve_id
CancelHold takes two parameters: patron_id and item_id.
If item_id is considered as an itemnumber, holds on title can't be
canceled.
If item_id is considered as a biblionumber, all holds on this
biblionumber (for a borrower) will be canceled.

So CancelHold have to consider item_id as a reserve_id.

- Added subroutine C4::Reserves::GetReserve
- C4::ILSDI::Services::GetRecords now returns the reserve_id
- Fix the text in the ilsdi.pl?service=Describe&verb=CancelHold page
- Unit tests for CancelReserved and GetReserve
- Do not delete row in reserves table if insert in old_reserves fails

Signed-off-by: Leila and Sonia <koha.aixmarseille@gmail.com>
Signed-off-by: Benjamin Rokseth <bensinober@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signing off, while noting a style issue in the patch review

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Placed and cancelled a hold using ILS-DI successfully.
Adding a follow-up to also update the ils-di documentation
page in the bootstrap theme.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

EDIT: I removed the changes it did to the prog theme.
2014-09-18 09:48:41 -03:00
3e78a908f0 Bug 10226 - suspended holds still show not available
If you suspend a hold, the item does not show Available.  It still shows
the person next in line, who isn't eligible for the hold yet because of
the suspension.  This is not the case for a delayed hold, where you
originally place the hold and tell it not to start until a future date.
If you do that, it shows as Available.  This is confusing and
inconsistent.

Test Plan:
1) Create an item level suspended hold for a record with no other holds
2) Note in the record details that the hold shows an item level hold
3) Apply this patch
4) Refresh the record details page, note the item is "Available"
5) Optional: prove t/db_dependent/Holds.t t/db_dependent/Reserves.t

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-14 02:02:51 -03:00
3c1f7dae0a Bug 8735 - Expire holds waiting only on days the library is open - Followup - Switch from C4::Calendar to Koha::Calendar
Test Plan:
 1) Set ExpireReservesMaxPickUpDelay
 2) Set ReservesMaxPickUpDelay to 1
 3) Place a hold, set it to waiting
 4) Using the MySQL console, modify the waiting date and set it to the
    day before yesterday.
 5) Set today as a holiday for the pickup branch in question.
 6) Run misc/cronjobs/holds/cancel_expired_holds.pl
 7) The hold should remain unchanged
 8) Remove today as a holiday
 9) Run misc/cronjobs/holds/cancel_expired_holds.pl again
10) The hold should now be canceled

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-05 11:51:01 -03:00
3b092a899f Bug 8735 - Expire holds waiting only on days the library is open
Signed-off-by: Leila <koha.aixmarseille@gmail.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-09-05 11:50:58 -03:00
0f6ff54104 Bug 12086 - Hold priorities incorrect, when waiting status was reversed
1) Test record has 1 single item, checked out to patron X
2) Place 3 holds for patrons A, B and C, all title level hold this time
   A, B, C, item branches and staff branch are the same.
3) Return item, confirm hold
4) Confirm item is now waiting for patron A
   Priorities are: A = Waiting, B = 1, C = 2
5) Open patron account of user B, checkout book
   Koha asks: Item X has been waiting for patron A... Revert
   waiting status
   Confirm.
6) Check priorities:
   Hold list shows: A = 1, C = 1
   Database says: A = 1, C = 3
7) Apply this patch
8) Repeat steps 1-6
9) Note the priorities are correct

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

Test plan correctly predicts the error and the correction made by the
patch.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2014-06-23 15:07:11 -03:00
Fridolyn SOMERS
7acd7f43a7 Bug 9532: fix reservability check when bib-level item types are in use
When itemtype is defined on biblio (item-level_itypes syspref), the
method C4::Reserves::CanItemBeReserved uses item->{itemtype}. But
ithe item comes from C4::Items::GetItem and it does not have an
'itemtype' key; in this method the item type value is always in
'itype' key.

This patch corrects it.

Test plan:

You should have itemtype on biblio and 'item-level_itypes' syspref
set to biblio.

This test plan is with ReservesControlBranch on ItemHomeLibrary.
- Choose a branch, a borrower category and an item type, for example
  'NYC', 'CHILD' and 'DVD'
- Set an issuing rule for 'NYC', CHILD' and 'DVD' with 'Holds allowed'
  set to 10
- Set an issuing rule for 'NYC', CHILD' and all item types with
  'Holds allowed' set to 0
- Choose an item of a biblio with itemtype 'DVD', that can be reserved,
  with 'NYC' as homebranch
- Choose a borrower with category 'CHILD'
- Try to request the item for the borrower
=> without the patch, you can
=> with the patch, you can't
You may check reserve is allowed with 'Holds allowed' > 0 on issuing
rule for 'DVD'.

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Great test plan - thanks!

Confirmed the bug, and the fix. Looks good to me.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-05 17:17:36 +00:00
Galen Charlton
e25c42715a Bug 9016: (follow-up) treat missing transports for hold available notices as warnings, not fatal errors
This patch fixes a situation where a patron that has preferences
set for transport of a notice via a method that is not supported
for that notice type can result in a failure.  Rather than
make it a fatal error during checkin, simply log a warning and skip.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-02 20:54:55 +00:00
Olli-Antti Kivilahti
9270f06463 Bug 11561: restore previous behavior of generation of hold print notices
This patch prevents duplicate hold available print notices from being
sent and enforces making a print notice if no other transports can be
used.

-------------------------
- REPLICATING THE ISSUE -
-------------------------

1. Set a Patrons "Hold filled"-messaging preference to SMS + Email
2. Remove the SMS number (sms notification number) and all email
   addresses.
3. Make a reservation for this Patron.
4. Check-in the reserved Item.
5. message_queue-table has two generated print notices for the
   Hold_filled event.
   One for both failed message transport types, email and sms.

1. Set a Patrons "Hold filled"-messaging preference to empty, remove all
   checks from boxes.
2. Make a reservation for this Patron
3. Check-in the reserved Item.
4. message_queue-table has no message for the Hold-filled event. This is
   problematic because a Patron should get some kind of a notification
   for a filled Hold.

-----------------------------
- AFTER APPLYING THIS PATCH -
-----------------------------

If all message transport types for "Hold filled" fail, a print notice is
queued in the message_queue table. Only one print message is queued even
if many transports attempts fail.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-02 20:29:19 +00:00
Jonathan Druart
7e878d42a0 Bug 10845: (follow-up) add the MTT in the die message
If no template is defined for the HOLD letter and the needed MTT, we
should display the MTT.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-02 20:29:19 +00:00
Jonathan Druart
777814a260 Bug 10845: Multi transport types for holds
The HOLD_PRINT and HOLD_PHONE notices become useless.
This patch modifies existing notices in order to group them into the
main notice type 'HOLD', with any pre-existing print and phone
templates in the appropriate places.

Test plan:
- Apply the patch and execute the update database entry.
- Verify that your previous HOLD_PHONE and HOLD_PRINT are displayed
  when editing the HOLD notice (under phone and print).
- Choose a patron and check SMS, email, phone for "Hold filled"
  (on the patron messaging preferences).
- Place a hold.
- Check the item in and confirm the hold.
- If the patron has an email *and* a SMS number, 2 new messages are put
  into the  message_queue table: 1 sms and 1 email.
  If the patron does not have 1 of them, there are 2 new messages: 1
  sms/email and 1 print.
  If the user has neither of them, there is 1 new message: 1 print.
- The generated messages should correspond with the notices defined,
  depending the message transport type.

Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Just noting that if email and SMS are disabled in the msg prefs, the user
will not have a print message.
And if the SMS driver fails, the record status in message_queue is 'failed',
but staff may not be aware of that.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-05-02 20:29:19 +00:00
Galen Charlton
695fdebdee Bug 12079: ensure that CheckReserves() includes reserve_id in its response
This patch modifies _Findgroupreserve so that its one caller,
CheckReserves(), would include the reserve_id field in the
hold request it returns.

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

To test:

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

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

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

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

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

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

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-17 15:32:25 +00:00
Robin Sheat
95056d17b7 Bug 11947 - renumber reserves when hold is confirmed
Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.

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

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

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

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

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

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-04-15 14:18:19 +00:00
cb62a47bbf Bug 11694: [QA Followup] strip out time portion when setting suspension date for individual hold
This patch fixes an issue originally reported by bug 11702.

RM note: the patch is clear enough and doesn't break existing tests,
but on the other hand, I have been completely unable to reproduce
the original issue.

To test:

[1] Verify that prove -v t/db_dependent/Holds.t passes

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-03-26 16:51:03 +00:00
cb45d4c218 Bug 10452: make AllowHoldsOnDamagedItems control using damaged items to fulfill holds
AllowHoldsOnDamagedItems will stop item-specific holds from being placed
on damaged items, but does not stop Koha from using damaged items to
fill holds. This seems like incorrect behavior.

Test Plan:
1) Set 'AllowHoldsOnDamagedItems' to "Don't Allow"
2) Pick an item, set it to damaged
3) Place a bib-level hold on this item's record
4) Scan the item though the returns system
5) Koha will ask to use this item to fill the hold, click "ignore"
6) Apply this patch
7) Repeat step 4
8) Koha will not ask to use this item to fill the hold

Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-03-10 18:15:12 +00:00
Galen Charlton
e51b441781 Bug 8918: (follow-up) tidy code and description of CalculatePriority()
This patch improves the formatting and the description of the new
CalculatePriority() routine.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-03-10 17:48:54 +00:00
Julian Maurice
3e344d7e07 Bug 8918: Fix reserve priority in ILS-DI
The priority of new hold requests was not calculated when using ILS-DI.

A new routine is added, C4::Reserves::CalculatePriority(), to calculate
the priority prior to placing a request.

A separate bug report, 11640, covers the changes in reserves to
use this new routine more generally.

This patch does therefore only affect ILS-DI.

Note: ILS-DI already allows you to generate multiple holds on a biblio or
item for the same patron. This patch does not change that behavior.

Test plan:
[1] Place multiple holds using ILS-DI HoldTitle service:
    /cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_id=BORROWERNUMBER&bib_id=BIBLIONUMBER&request_location=test
    Check the priority.
[2] Do the same using HoldItem service:
    /cgi-bin/koha/ilsdi.pl?service=HoldItem&patron_id=BORROWERNUMBER&bib_id=BIBLIONUMBER&item_id=ITEMNUMBER
    Check the priority again.
[3] Use a biblio with multiple items. Place item level holds on both.
    Check in one of these items in another branch. Confirm transfer.
    Check in the other item in the original branch. Confirm hold.
    Now you have a waiting and a transit hold.
    Test HoldTitle and HoldItem service again a few times.
[4] Enable AllowHoldDateInFuture and add a future hold.
    Now test HoldTitle and HoldItem again and check if these holds are
    inserted before the future hold (lower priority).

January 29, 2014: Rebased this patch and amended it to make a distinction
between fixing the ILS-DI bug and using the new routine.
Updated commit message and test plan (marcelr).

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-03-10 17:31:05 +00:00
Galen Charlton
7b58255028 Bug 9823: (follow-up) improve POD for C4::Reserves::GetReservesFromBiblionumber
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-30 16:48:26 +00:00
Jonathan Druart
8b685c1e80 Bug 9823: Refactor return from GetReservesFromBiblionumber
The return from GetReservesFromBiblionumber contains an unnecessary
extra variable. In scalar context an array returns its element count.
Maintaining a separate count can lead to unforeseen bugs
and imposes ugly constructions on the subroutine's users.

Remove the useless count variable from the return

This patch also changes the parameters: now the routine takes a hashref.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Placed biblio holds, future holds and item holds. Works as expected.
Tested Holds.t and Reserves.t. Pass.
Tested /cgi-bin/koha/ilsdi.pl?service=GetRecords&id=999 with two holds on
one item. Fine.
C4/SIP/ILS/Item.pm: Looked for "whatever" and "arrayref" and could not find
them anymore. Looks good.
Handled a few unneeded calls in QA follow-up.
Left only one point to-do for serials/routing-preview.pl. See Bugzilla.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-30 16:19:55 +00:00
Jonathan Druart
38edd714c5 Bug 9788: QA followup
1/ CURRENT_DATE() is a MySQLism and should be replaced with CAST(now() AS
DATE).
2/ The date formatting should be done in the template (using the TT
plugin).

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-17 05:10:42 +00:00
92be11bbcf Bug 9788: (follow-up) removing the alldates parameter from GetReservesFromItemnumber
Before bug 9788 the alldates parameter of GetReservesFromItemnumber was
actually not used in the codebase.
The first patch of bug 9788 did change that and passed true by default.

But a closer look revealed that we do not really need it.

The parameter is removed by this patch; the SQL statement is slightly
adjusted: if reservedate<=now or a waitingdate is filled for the
requested itemnumber, GetReservesFromItemnumber will return the reserve.

This includes so-called future waits: a future hold that has been confirmed
ahead of time with pref ConfirmFutureHolds > 0 days.

Note that future item-level holds are not really interesting to return; this
just corresponds to original behavior. Future next-available holds are not
in view at all; they do not contain an item number.

Test plan:
Actually, the test plan of the first patch is valid. But for completeness I
repeat it here:

[1] Enable future holds and set ConfirmFutureHolds to 2 days.
[2] Place a future next-available hold for 2 days ahead.
[3] Check item status on catalogue detail. Available? That is fine.
[4] Confirm the future hold by checking it in. ('future wait')
[5] Look at item status again on catalogue detail. Must be Waiting now.
[6] Switch to OPAC and login as another opac user. Goto Place a hold.
[7] Check item status with item level hold info. Is it waiting?
[8] Try to place hold in staff, check item level status again. Waiting?
[9] Make a transfer for the item. Switch branch. Check hold status on
    Transfers to receive.

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

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-17 05:07:32 +00:00
1a9737be76 Bug 9788: Improvements when calling GetReservesFromItemnumber
This patch makes GetReservesFromItemnumber also returns the waiting
date and removes some repeated code.

Improves item status display on catalogue detail, when placing a hold at
opac-reserve and in staff, and on transfers to receive form.

This patch builds on work from reports 9367 and 9761.

Test plan:

Place a future next-av. hold (enable future holds prefs), say 2 days ahead.
Check item status on catalogue detail. Nothing to see.
Enable ConfirmFutureHolds by inserting a number of days, say 2.
Confirm earlier hold by checking it in. Look at item status again on detail.
Switch to other opac user. Try to place a hold again. Check item status with
item level hold info. Try to place hold in staff, check item level status.
Make a transfer for that item. Switch branch. Look at transfers to receive.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-17 05:06:01 +00:00
Galen Charlton
7af64ff7bd Bug 11336: (follow-up) fix typo in previous follow-up
This patch corrects a typo that broken ModReserveFill().  This
patch also adds a unit test that (via two levels of indirection)
exercises ModReserveFill().

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-06 16:16:22 +00:00
Galen Charlton
543e1dc673 Bug 11336: (follow-up) improve POD for _FixPriority()
This patch improves the POD for C4::Reserves::_FixPriority()
to (hopefully) describe its function thoroughly.  It also
adjusts the call of _FixPriority() by CancelReserve() to
omit passing reserve_id, since by that point no row in
the reserves table for that request still exists.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-04 23:25:25 +00:00
Galen Charlton
80fc94f86a Bug 11336: (follow-up) correct change to POD for GetReserve()
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-04 22:45:29 +00:00
Jonathan Druart
78037c5573 Bug 11336: update hold queue priorities correctly when deleting holds
In various places, deleting a hold request did not trigger recalculating
the priority of the other holds on the bib:

To reproduce the bug:
- select or create 2 users U1 and U2
- select or create an holdable item
- place on hold for both U1 and U2. U1 has priority 1 and U2 has
  priority 2.
- delete the hold for U1
- go on circ/circulation.pl?borrowernumber=XXXX for U2 (or in the DB
  directly) and verify the priority has not been set to 1

The issue is repeatable (at least) on these 2 pages:
 * circ/circulation.pl?borrowernumber=XXXX (tab 'Holds', select "yes"
  in the dropdown list and submit the form)
 * reserve/request.pl?biblionumber=XXXX (click on the red cross)

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reran my tests:

Preparations:
- Create holds for different patrons on a record:
  * 1st - title level hold
  * 2nd - item level hold
  * 3rd - title level hold
  * 4th - title level hold
- AllowOnShelfHolds = On/Allow (items were not checked out)

Tests:
Deleted holds from various pages, confirming bugs first,
then testing with applied patches. Reloading database
after each test.

1) Cancel holds from OPAC patron account
  /cgi-bin/koha/opac-user.pl#opac-user-holds
- Cancel 4th - ok, before and after applying the patch
- Cancel 2nd - ok, after applying the patch

2) Cancel hold from holds tab on staff detail page
  /cgi-bin/koha/reserve/request.pl?biblionumber=7

  a) Setting priority to 'del', submitting with 'Update holds'
  - Cancel first (1st) - ok, before and after
  - Cancel hold in the middle (was 3rd) - ok, before and after
  - Cancel last (was 4th) -ok, before and after

  b) Using red X
  - Repeating tests from a) - before the patch is applied holds
    get totally 'out of order' - after applying the patch, it works
    correctly

Additional tests done on this page:
- Change priority using up, down, to top, to bottom icons
- Change priority with 'toggle to lowest'

3) Cancel hold from the patron's account

  a) Check out tab - Delete? Yes, 'Cancel marked holds'
    /cgi-bin/koha/circ/circulation.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  b) Details tab - Delete? yes, 'Cancel marked holds'
    /cgi-bin/koha/members/moremember.pl?borrowernumber=X
  - Cancel first (1st) - ok, after applying the patch
  - Cancel hold in the middle (was 3rd) - ok, after applying the patch
  - Cancel last (was 4th) - ok, after applying the patch

  Without the patch, holds priorities get out of order.

Additional tests done:
- Check in one item to trigger first hold
- Check in one item to trigger second hold
- Check out first item
Priorities are kept while the item is waiting, when it's
checked out, priorities of remaining holds get reset correctly.

Conclusion:
Big improvement, no regressions found.

Passes all tests in t, xt and QA script.
Also: t/db_dependent/Holds.t
      t/db_dependent/HoldsQueue.t
      t/db_dependent/Reserves.t

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2014-01-04 22:42:10 +00:00
Galen Charlton
fe08a0ef97 Bug 11445: avoid sending duplicate hold waiting notifications
This patch fixes a problem where a patron could receive duplicate
hold waiting notifications.  For example, this could happen if a
circ operator checked in an item more than once and confirmed the
same hold each time.

To test:

[1] Set up a test patron that received hold waiting notifications.
[2] Put an item on hold for the patron, then check the item in
    and confirm the hold.  Verify that a hold notification is
    sent (or inspect the message_queue table).
[3] Check the item in again and confirm the hold again.  A duplicate
    hold notification will be generated.
[4] Apply the patch.
[5] Repeat steps 2 and 3.  This time, only one notification should be
    generated.
[6] Verify that prove -v t/db_dependent/Reserves.t passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-12-30 15:10:28 +00:00
dd22c0ec0f Bug 8037: (follow-up) fix various issues
[1] Add test for GetBudgetByOrderNumber()
[2] Remove unconditional warn.
[3] Remove MySQLism

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-31 14:53:16 +00:00
3910d5e8b4 Bug 8037: Display holds & fund on the already received table on order receipt summary
Adds a column to indicate holds on received items, as well as adding
a new column for fund and showing the subtotals per fund above
the total subtotal.

To test:

[1] Create an order basket containing at least one title and
    ensure that an item is created for that title.  Close the
    basket.
[2] Place a hold on the title.
[3] Receive the order.  After receiving it, but before finishing
    the invoice, the table of already received orders should now
    have columns for the order budget and number of holds on the
    title as well as lines with the subtotal per fund.

Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-31 14:53:07 +00:00
2e4411e77f Bug 10493: Add renewal script
This patch adds a renewal tool that functions similar to the returns where a
librarian can continuously scan items for renewal. This script blocks
renewals that are impossible, and allow the same renewal overrides
as circulation.pl

Test plan:
 1) Apply the patches for bug 8798
 2) Apply this patch
 3) Browse to /cgi-bin/koha/circ/renew.pl
 4) Enter an invalid barcode, you should get an error message
 5) Enter a valid, but not checked out barcode, you should get an error
    message.
 6) Enter a valid barcode that is checkout out and should be renewable,
    you should get a success message.
 7) Enable AllowRenewalLimitOverride
 8) Enter a barcode for an item that has been renewed too many times
 9) You should get a warning which you can override.
10) Disable AllowRenewalLimitOverride
11) Repeat steap 8
12) You should get a blocking error message
11) Enter a barcode for an item with unfilled holds on it,
    you should get an overridable warning

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Passes all tests and QA script, some issues have been
addressed in follow-ups.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-22 17:04:03 +00:00
Jonathan Druart
45e6a7e58f Bug 10380: Change prototype for output_pref() routine
Koha::DateUtils::output_pref took 4 parameters and the last one is a
boolean, so some calls were:
  output_pref($dt, undef, undef, 1)

This patch changes its prototype to
  output_pref({
    dt => $dt,
    dateformat => $dateformat,
    timeformat => $timeformat,
    dateonly => $boolean
  });

An alternative is to call the output_pref routine with a datetime
object, without using an hashref:

  output_pref($dt);

Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-17 23:34:26 +00:00
Kenza Zaki
3b56392a6f Bug 10682: remove inappropriate uses of finish() from C4::Reserves
This patch gets rid of finish.

From the man page

finish()
Indicate that no more data will be fetched from this statement handle
before it is either executed again or destroyed.
You almost certainly do not need to call this method.

Adding calls to "finish" after loop that fetches all rows is a common
mistake, don't do it, it can mask genuine problems like uncaught fetch errors.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Similar to other patches from the same author
I run prove t/db_dependent/Reserves.t without errors
don't know if more tests are needed.
No koha-qa errors

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-09 03:37:15 +00:00
Galen Charlton
11606693ef Bug 10949: restore ability to successfully print hold slips
This fixes a regression introduced by the patch for bug
9394 -- when printing a hold slip using the 'print and confirm'
button, the slip would contain only the text 'reserve not found',
not a full hold slip.

This patch also adds a regression test.

To test:

[1] Check in an item that would fill a hold.  Use the 'print
    and confirm button' to confirm the hold.
[2] The printout will only contain text to the effect of
    'reserve not found'.
[3] Apply the patch.
[4] Repeat step 1.  This time, a full hold slip should be printed.
[5] Verify that prove -v t/db_dependent/Reserves.t passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Pass all tests, new and old, and QA script.
Verified wrong and corrected behaviour.

Note: Sometimes there will not be the message 'reserve not found'
showing up, but hold information for a different record. This happens
when there exists a reserve_id with the borrowernumber of the patron
in question in your database.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-10-02 14:38:30 +00:00
ded520afdc Bug 9761: Make it possible to confirm future hold requests at checkin time
Description:

A new pref ConfirmFutureHolds is added. When confirming a hold at checkin time,
the number of days in this pref is taken into account when looking for reserves.
Note that this pref does not interfere with renewing, issuing or transferring
a book. For report Holds to pull, the default end date is calculated with this
new preference.
The use of ConfirmFutureHolds is useful only when future holds are allowed.

Test plan:
1) Enable future holds. Add a number of days into ConfirmFutureHolds.
2) Place a future hold within this number of days.
3) Run holds to pull report. Check default startdate and enddate.
4) Check this book in. Can you confirm the hold? Do not confirm.
5) Issue the book to another patron. You should not see a warning.
6) Renew the book for this patron via opac or staff. No warning either.
7) Check in again. Warning pops up again.
8) Transfer book. Switch branch. Check in. Hold found pops up. Do not confirm.
9) Back to first branch. Check in (with popup). Remove the hold. Add new future
hold past the number of days. Check in (no warn).

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-09-25 00:26:34 +00:00
dbaefb626c Bug 10550: Fix database typo wthdrawn
This patch updates the wthdrawn field in items and deleteditems to be
withdrawn instead. No functional changes are made.

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

Comment: Save for translation files (that will be fixed on next release),
only occurrence of wthdrawn is on updatedatabase.pl
No koha-qa errors.

This touch many files, and I did not test everything,
but all seems normal. I think that any problem could
be fixed later.

Perhaps both entries in updatedatabase.pl could be joined
into one, but thats for QA.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
2013-09-08 01:58:41 +00:00