|
Description
David Bourgault
2017-09-18 17:31:04 UTC
Created attachment 67191 [details] [review] Bug 19336 - Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Hi David After checking out an item out with a due date set to be over 30 days ago and then running this cronjob I have found that the following error is thrown in the cronjob output: kohadev-koha@kohadevbox:/home/vagrant/kohaclone/misc/cronjobs$ ./fines.pl --maxfinesdays 30 DateTime::Duration does not overload comparison. See the documentation on the compare() method for details. at ./fines.pl line 129. And no maximum fine is added to the accountlines table Created attachment 68318 [details] [review] Bug 19336 - Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Created attachment 68335 [details] [review] Bug 19336 - Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 68336 [details] [review] Bug 19336 - Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Hello David, What about $type and $unitcounttotal variables? If maxfinesdays is defined and amount != 0, they are empty. Indeed, $type is always empty since chargename is never populated. But this could be fixed in another BZ... Moving to FQA to trigger reaction from developter to question on comment#6 Despite the 'uninitialized value in join...' , I feel like $unitcounttotal shouldn't take any _numerical_ values. The concept of chargeunits stops making sense once you arbritraly charge the overduefinescap after X given days, which is exactly what maxfinesdays does. It's not bothered by closing hours, nor does it care about grace periods, it bluntly maxes out the fine. This seems like a reason not to consider any information derived from $issuing_rule->lengthunit. Now, as I hinted at the beginning, I'm definitely open to initializing $unitcounttotal. Since its only use is to be concanated with other fields before being outputed to a file, it could make sense to inform the fines report's reader that maxfinesdays was applied. Is this approach sound in your opinion? Created attachment 75379 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 75380 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 75381 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Rewrote the patch titles to abide by the standardized notation. Provided a way out of the 'In discussion' status by initializing $unitcounttotal to 'n/a', the common abbreviation used in a report for a field that does not apply. Back in Needs Signoff. Created attachment 85914 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85915 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85916 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Created attachment 85917 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85918 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85919 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Created attachment 85920 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85921 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 85922 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Created attachment 85923 [details] [review] Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Couldn't apply the patch $ git bz apply 19336 y Bug 19336 - Add option to fines.pl to apply maximal fine amount after delay 85920 - Bug 19336: Add --maxfinesday option to fines.pl 85921 - Bug 19336: (follow-up) Correct DateTime and Koha calls 85922 - Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written 85923 - Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Apply? [(y)es, (n)o, (i)nteractive] Applying: Bug 19336: Add --maxfinesday option to fines.pl Using index info to reconstruct a base tree... M misc/cronjobs/fines.pl Falling back to patching base and 3-way merge... Auto-merging misc/cronjobs/fines.pl CONFLICT (content): Merge conflict in misc/cronjobs/fines.pl error: Failed to merge in the changes. Patch failed at 0001 Bug 19336: Add --maxfinesday option to fines.pl The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-19336-Add---maxfinesday-option-to-finespl-d37mQ0.patch Created attachment 124197 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Created attachment 124198 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 124199 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Created attachment 124200 [details] [review] Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Created attachment 124201 [details] [review] Bug 19336: (QA follow-up) Using CirculationRules instead of IssuingRules Created attachment 153504 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 153505 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Created attachment 153506 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Created attachment 153507 [details] [review] Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Created attachment 153508 [details] [review] Bug 19336: (QA follow-up) Using CirculationRules instead of IssuingRules Created attachment 168517 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Created attachment 168518 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Created attachment 168519 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Created attachment 168520 [details] [review] Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Created attachment 168521 [details] [review] Bug 19336: (QA follow-up) Using CirculationRules instead of IssuingRules Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Created attachment 172982 [details] [review] Bug 19336: Add --maxfinesday option to fines.pl This is a functionality we have for some of our clients we want to push to the community. Adds the --maxfinesday argument to fines.pl which creates or updates a fine with the maximum amount set in the circulation rules after the delay has passed. e.g.: ./fines.pl --maxfinesdays 30 All item over 30 days late will have the maximal fine applied. Here is a test plan I followed based on above. Test plan: 1. Create circulation rule with Overdue fines cap set 2. Set finesMode systempreference to 'Calculate and charge' 3. Check out an item with the due date set 30 days ago 4. In Koha shell run ./fines.pl --maxfinesdays 30 5. There should now be a new fine in the accountlines table of the amount set in overdue fines cap Followed test plan, patch worked as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 172983 [details] [review] Bug 19336: (follow-up) Correct DateTime and Koha calls This fixes the 'DateTime does not overload' error. It also fixes the next error, which was that C4::GetIssuingRules is deprecated. Finally it now handles no overduefinescap being define (does nothing). Passes QA test tool Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 172984 [details] [review] Bug 19336: (QA follow-up) Initialize $unitcounttotal in case a report is written Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 172985 [details] [review] Bug 19336: (follow-up) Initialize $unitcount instead of $unitcounttotal after changes on master Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 172986 [details] [review] Bug 19336: (QA follow-up) Using CirculationRules instead of IssuingRules Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Created attachment 172987 [details] [review] Bug 19336: (QA follow-up) Tidy fines.pl Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> I am aware that this has gone through a lot of different hands already. The fines.pl script is quite a sensitive spot. We want to add the new feature, without breaking anything of the old behavior.
I tried reviewing the code myself, but it's also not our prettiest script and there is a lot of variables flying around.
May I request a second set of QA eyes here please?
- my ( $amount, $unitcounttotal, $unitcount ) =
- CalcFine( $overdue, $patron->categorycode,
- $branchcode, $datedue, $today );
+ my ( $amount, $unitcounttotal, $unitcount );
+ if ( defined($maxfinesdays) && $maxfinesdays <= $datedue->delta_days($today)->in_units('days') ) {
+ my $itype = $overdue->{itemtype} || $overdue->{itype};
+ my $data = Koha::CirculationRules->get_effective_rule(
+ {
+ rule_name => 'overduefinescap', categorycode => $patron->categorycode, itemtype => $itype,
+ branchcode => $branchcode
+ }
+ );
+ if ( defined( $data->rule_value ) ) {
+ $amount = $data->rule_value;
+ $unitcount = 'n/a';
+ } else {
+ print
+ "No overduefinescap defined for {branchcode = $branchcode, itemtype = $itype and categorycode = $patron->categorycode}\n";
+ }
+ }
+ if ( !$amount ) {
+ ( $amount, $unitcounttotal, $unitcount ) =
+ CalcFine( $overdue, $patron->categorycode, $branchcode, $datedue, $today );
+ }
Some things I wondered about:
+ if ( !$amount ) {
Why this added condition on the calculation?
To me it looks like that would keep fines from increasing. I had expected an else case that keeps things like before if the new option is not used.
+ $unitcount = 'n/a';
Why this assignment? Unit count is usually numeric, but now set to a string.
>
> Some things I wondered about:
>
> + if ( !$amount ) {
> Why this added condition on the calculation?
> To me it looks like that would keep fines from increasing. I had expected an
> else case that keeps things like before if the new option is not used.
OK, sometimes it takes a moment longer, I just realized my mistake: The if makes sense to me now. Amount is not the current fine, but what is calculated within the script as the new fine. if there is already a new fine (maxfinesday was used and calculated), we don't want to change it, but when it wasn't calculated, it should calculate the normal fine.
One new question: What about CalculateFinesOnReturn?
This changes how fines are calculated in fines.pl, but leaves CalcFine unchanged. So when fines in Koha are recalculated for some reason, like when using CalculateFinesOnReturn, the fine will be reduced or changed to the multipe of fine amount * fine interval eventually.
|