http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367
Paola Rossi <paola.ro...@cineca.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #91 from Paola Rossi <paola.ro...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/