[Koha-bugs] [Bug 8367] How long is a hold waiting for pickup at a more granular level

Wed Nov 5 11:53:49 CET 2014

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367

Paola Rossi <paola.rossi at cineca.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |Failed QA

--- Comment #91 from Paola Rossi <paola.rossi at cineca.it> ---
[I beg you pardon for the length of this comment, my delay in answering and
possible inaccuracies.]

I've applied the patch against master 3.17.00.044 [HEAD 10860].

To test the patch IMHO on ADMIN it is better:
- (as required by the test plan) kept the value of syspref
"ReservesMaxPickupDelay" > 0
- set the syspref "EnhancedMessagingPreferences" to ON (default is OFF)

To test the patch IMHO on ADMIN it could be better:
- kept the default value "Don't allow" to the syspref "AllowOnShelfHolds"
- set the "Charge" of the item-types to 0.00 (default 5.00) for all types
- [remember to set the circulation rules]
- set the syspref "KohaAdminEmailAddress" to a value not filtered by antispam's
own emailing-system [to receive notices' email]
- [remeber to refresh the cache [Ctrl r - Ctrl F5] after seeing master's
behaviour].

At my tests, the RESERVESLIP and HOLD notices are allowed to be cloned to your
specific library, but I saw that koha uses only the "ALL LIBRARIES" notices,
and never the cloned ones.
So I changed those 2 notices to test the 2 parts of the test plan about LETTER.

To test the part of the test plan about the RESERVESLIP notice, i.e. see below:
*** TEST: LETTER PLACEHOLDER ***,
IMHO the functions to test are "Confirm"/"Print and confirm", on cheching in a
record already on hold by another patron.

To test the last part of the test plan about the HOLD notice, i.e. see below:
*** TEST: LETTER lastpickupdate PLACEHOLDER AND REGRESSION ****,
if I'm not wrong :
- set the notice's email [i.e. "Primary email"] of the test patron to your own
email
- if this patron had a found/status W hold, you'll receive a mail soon after:
perl ./misc/cronjobs/advance_notices.pl  -c
perl ./misc/cronjobs/process_message_queue.pl

IMHO it would be better explicitly adding a further last part to the test plan
about the provided:
t/db_dependent/Holds.t
[perhaps other parts of the preamble could need a testing action too.]

At my tests the upgrade of the DB is OK.

The 4 *.tt are OK.
NB1.: on ADMIN, in the "Circ and fines issuing rules", perhaps the new column
"Holds wait for pickup (day)" could be better set at the right of "Holds
allowed (count)", at the right of all the 4 columns about renewal, and not
among these 4 ones.

NB2.: on CIRC, on waitingreserves.pl (="Holds awaiting pickup"), on the "Holds
over" tag, the present string:
"Holds listed here have been awaiting pickup for more than days." could be
modified. In master it was:
"Holds listed here have been awaiting pickup for more than X days." where X was
the value of the syspref "ReservesMaxPickUpDelay" which has been removed by
this patch.

NB3.: On opac-user.pl, for a logged in user with W holds, the W holds had not
neigher the "Cancel" icon nor the "Suspend" icon. [I didn't check the master
about this behaviour, sorry. If this patch had changed the behaviour, this
regression would be on error, and this point will be added to the errors'
list.]

PROBLEMS:

NB4.: [MASTER] at my tests the "W" found/status of a hold/reserve is set in
only 1 case:
it is set to a hold, that previously had been opened on a biblio record which
was already checked out (found=NULL), and then checked in (found=W) without
"Ignore" submit. [I'd like to have a feedback about it, please, because all my
tests were about this assumption.]
NB5.: [MASTER] So, at my tests, the waitingdate of a hold/reserve can be only
the current date, i.e. the current day on which I check-in a biblio record.
[I'd like to have a feedback about it, please, because all my tests were about
this assumption.]

1) I saw no reserves.lastpickupdate nor the reserves.waitingdate on RESERVESLIP
notice. But I think that this problem is out of this bug, because the master
too behaves so. [On the contrary, on master (and after applying too) the
reserves.reservesnotes is correctly shown by the notice.]
2) Whilst a check out lasts 1 more day for an intervening holiday, the hold's
period doesn't: I'd like to have a feedback about this, please. If the W hold
would last 1 more day, the patch would be in error.
3) On upgrading the DB, by syspref "ReservesMaxPickupDelay" > 0, all the holds
for all the patrons' categories and item types would receive the same lasting
period. Whilst the patch, once applied, could assign a different value to each
of them. I think this remarkable to get coherent DB datas.
4) The found/status "W" meaning is about the lasting period available to the
patron to pick up the document. But when a "Transfer" is needed from the
check-out' library, to the hold's library, koha [master] doesn't set the
found/status to "W", but to NULL/T: I think that this behaviour could be
evaluated, that it can be a master's bug, and, if this is the case, that this
patch could be tested after having resolved this bug on a DB with such cases.
5)  prove t/db_dependent/Holds.t
t/db_dependent/Holds.t .. 1/46
#   Failed test 'GetLastPickupDate(): Not using Calendar'
#   at t/db_dependent/Holds.t line 436.
#          got: '2014-11-10'
#     expected: '2014-11-05'

#   Failed test 'GetLastPickupDate(): Moving lastpickupdate over holidays, but
not affected by them'
#   at t/db_dependent/Holds.t line 448.
#          got: '2014-11-10'
#     expected: '2014-11-05'

#   Failed test 'MoveWaitingdate(): Moving to past'
#   at t/db_dependent/Holds.t line 401.
#          got: ''
#     expected: '1'

#   Failed test 'Waiting reserve with lastpickupdate for 2014-11-04 totally
canceled'
#   at t/db_dependent/Holds.t line 367.
#          got: '1'
#     expected: '0'
# Looks like you failed 4 tests of 46.
t/db_dependent/Holds.t .. Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/46 subtests

Test Summary Report
-------------------
t/db_dependent/Holds.t (Wstat: 1024 Tests: 46 Failed: 4)
  Failed tests:  37, 39, 41, 44
  Non-zero exit status: 4
Files=1, Tests=46,  1 wallclock secs ( 0.01 usr  0.01 sys +  0.91 cusr  0.29
csys =  1.22 CPU)
Result: FAIL

For the 5-th problem I pass the patch to "Failed QA" status.

-- 
You are receiving this mail because:
You are watching all bug changes.