Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script. Also checked
t/db_dependent/Holds.t
t/db_dependent/HoldsQueue.t
Tested holds triggering with different settings of
AllowHoldsOnDamagedItems. Works as described.
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>
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>
If IndependentBranches is ON and canreservefromotherbranches is OFF,
a patron is not permittedo to request an item whose homebranch (i.e.,
owner of the item) is different from the patron's own library.
However, if canreservefromotherbranches is turned ON, the patron can
create such hold requests.
Note that canreservefromotherbranches has no effect if
IndependentBranches is OFF.
To test, run prove -v t/db_dependent/Holds.t. Without the bugfix
patch for bug 2394, the last two tests should fail.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- wrap in a transaction
- create the patron records needed for the test
To test:
[1] Run prove -v t/db_dependent/Holds.t
[2] Verify that all tests have passed.
[3] Verify that the additional patron records created
by the test no longer exist in the database.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* C4::Reserves::_FixPriority
- The previous code checked the cancellationdate. If think you never pass
in it with bad parameters, but in order to be sure I added the check on
this value.
- The reservedates array was never used.
* circ/circulation.tt
There was a bug: it was not possible to remove an hold from the
circulation page. Passing reserve_id fixes the issue.
* C4::Reserves::GetReserveId
This subroutine did not have a unit test.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch switches from using a combination of
biblionumber/borrowernumber to using reserve_id where possible.
Test Plan:
1) Apply patch
2) Run t/db_dependent/Holds.t
Signed-off-by: Maxime Pelletier <maxime.pelletier@libeo.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
