This way ILS-DI HoldItem and HoldTitle services also benefit from this
check
Test plan:
1/ Define some default holds policies by item type in
/admin/smart-rules.pl
2/ Use ILS-DI HoldItem service and check that those rules are respected
3/ Check that staff and opac hold behaviour is unchanged regarding
these rules.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script. No regressions found,
improves the ILS-DI HoldItem response.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
