From cb609ca098823734dde590fcf42164f72bbfbf37 Mon Sep 17 00:00:00 2001 From: Wolfgang Bumiller Date: Thu, 15 Nov 2018 10:28:01 +0100 Subject: [PATCH] fix #1974: postscreen_stat_graph: go through all entries When the GUI requests the values for a whole month containing a DST switch it will request a range a little longer or shorter than a month, eg. 31.04166 days for October 2018 in CET. Since we use integer math to calculate the number of entries we expect, the database then returns one more value than expected, and we forget to fill in the last time value. For example, requesting Oct. 2018 from CET causes the equivalent of this query: # pmgsh get /statistics/rejectcount --starttime=1538344800 --endtime=$[1541026800] --timespan=86400 400 Result verification failed [31].time: property is missing and it is not optional Note that: $ echo $[(1541026800-1538344800) / (60*60*24.)] 31.041666666666668 This also happens when for example taking the working range for the month and simply subtracting 1 second from the end-time. Our division will then round down by a day while the database timestamps still cause that day to be included in the result. --- PMG/Statistic.pm | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/PMG/Statistic.pm b/PMG/Statistic.pm index ac9473f..c2b103f 100755 --- a/PMG/Statistic.pm +++ b/PMG/Statistic.pm @@ -780,13 +780,14 @@ sub postscreen_stat_graph { my $sth = $rdb->{dbh}->prepare($cmd); $sth->execute (); + my $max_entry = int(($to - $from) / $span); while (my $ref = $sth->fetchrow_hashref()) { - $res->[$ref->{index}] = $ref; + my $i = $ref->{index}; + $res->[$i] = $ref; + $max_entry = $i if $i > $max_entry; } - my $c = int (($to - $from) / $span); - - for my $i (0..$c) { + for my $i (0..$max_entry) { $res->[$i] //= { index => $i, rbl_rejects => 0, pregreet_rejects => 0}; my $d = $res->[$i]; -- 2.39.2