Due date is not set when number of days is above 21

1

I have a problem where the due date does not get set when the number of days is above 22.
The following is the config:

‘Business Hours’ => {
1 => { Name => ‘Monday’, Start => ‘08:00’, End => ‘16:30’ },
2 => { Name => ‘Tuesday’, Start => ‘08:00’, End => ‘16:30’ },
3 => { Name => ‘Wednesday’, Start => ‘08:00’, End => ‘16:30’ },
4 => { Name => ‘Thursday’, Start => ‘08:00’, End => ‘16:30’ },
5 => { Name => ‘Friday’, Start => ‘08:00’, End => ‘16:30’ },
}

‘22-BDays’ => {
Resolve => { BusinessMinutes => 8.5 * 60 * 22 },
BusinessHours => ‘Business Hours’,
}

However, with a config like the one below where it’s 21 days, the due date is set as expected.

‘21-BDays’ => {
Resolve => { BusinessMinutes => 8.5 * 60 * 21 },
BusinessHours => ‘Business Hours’,
}

Is there a reason why the due date would not be set when the number of days is more than 21?

2

I believe it’s a bug, not sure if it’s been fixed. Where the business hours module only handles up to some value in one computation. So where ever the conversion from 22 days is made into business hours time, you need to split that up into a couple of conversions

3

Thank you for your response, I suspected it could be a bug as I saw nothing in the config that could influence this. I wonder if we can expect to have a fix soon, or if one may submit a pull request. Perhaps I can take a crack at it.

4

My quick look says a fix would look something like this:

diff --git a/lib/RT/SLA.pm b/lib/RT/SLA.pm
index 791e76dc0..0cc649808 100644
--- a/lib/RT/SLA.pm
+++ b/lib/RT/SLA.pm
@@ -191,8 +191,9 @@ sub CalculateTime {
                             my $bhours = $self->BusinessHours( $agreement->{ 'BusinessHours' } );
                             my $time = $bhours->between( $last_time, $txn->CreatedObj->Unix );
                             if ( $time > 0 ) {
-                                $res = $bhours->add_seconds( $res, $time );
-                            }
+                                for my $i (0..3) {
+                                    $res = $bhours->add_seconds( $res, $time / 4 );
+                                }
                         }
                         else {
                             my $time = $txn->CreatedObj->Unix - $last_time;
@@ -209,9 +210,9 @@ sub CalculateTime {

         if ( defined $agreement->{'BusinessMinutes'} ) {
             if ( $agreement->{'BusinessMinutes'} ) {
-                $res = $bhours->add_seconds(
-                    $res, 60 * $agreement->{'BusinessMinutes'},
-                );
+                    for my $i (0..3) {
+                        $res = $bhours->add_seconds( $res, (60 * $agreement->{'BusinessMinutes'}) / 4 );
+                    }
             }
             else {
                 $res = $bhours->first_after( $res );

Ref:

I am sure it can be made smarter than just dividing by 4 though

5

I suspected it could be a bug as I saw nothing in the config that could influence this. I wonder if we can expect to have a fix soon, or if one may submit a pull request. Perhaps I can take a crack at it.

6

Found lots of useful info in this blog thanks for sharing this keep it up.

7

It’s year 2024 and RT version is 5.0.x but this bug is still there.

9

One possibility is that there might be an issue with how the system calculates business days or business minutes for durations longer than 21 days. It’s possible that there could be a limitation or a bug in the calculation logic that affects durations beyond a certain threshold.

10

Following this link to METACPAN from @knation’s comment above, you can read:

add_seconds START, SECONDS
Returns a time SECONDS business seconds after START. START should be specified in seconds since the epoch.
Returns -1 if it can’t find any business hours within thirty days.

So, it’s some kind of “feautre” rather than a bug (yes, I agree with everybody that it’s not the expected behavior) so, @knation’s patch is one solution for your problem right now (note that if your due date needs to be set, for example, 6 months later, 4 loops won’t be enough).