RT SLA Extension

Hi, I’ve encountered what appears to be a limitation in the RT SLA extension, if the minutes value applied to an SLA is greater then 1000 the Due date value fails to be set.

For example, we’ve got an SLA for 1 month, which equates to 20, 8.5 hour days, therefore business minutes for the SLA would be defined as 608.520 - in practice this doesn’t work, the due date is blank, when i reduce the SLA to 19 days it works.

I’m guessing there is some sort of limitation in the code?

Craig

Hello,

It’s limitation and I’m forwarding this email to bugs queue on
rt.cpan.org. I believe it can be improved in Business::Hours and this
module itself to handle wider periods of time, but at this moment I
don’t have time to work on this.

You can either send me patch or order custom development from best
practical to change this.

If you’re going to patch things then you should look at add_seconds
method in Business::Hours module. There is static $MAXTIME variable in
that function. The variable should become an optional argument of the
method and RT::Extension::SLA should generate some reasonable value
depending on the current configuration.On Mon, Mar 22, 2010 at 1:31 AM, Craig Scott Craig.Scott@stc.ac.uk wrote:

Hi, I’ve encountered what appears to be a limitation in the RT SLA
extension, if the minutes value applied to an SLA is greater then 1000 the
Due date value fails to be set.

For example, we’ve got an SLA for 1 month, which equates to 20, 8.5 hour
days, therefore business minutes for the SLA would be defined as 608.520 –
in practice this doesn’t work, the due date is blank, when i reduce the SLA
to 19 days it works.

I’m guessing there is some sort of limitation in the code?

Craig


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

2010 RT Training Sessions!
San Francisco, CA, USA - Feb 22 & 23
Dublin, Ireland - Mar 15 & 16
Boston, MA, USA - April 5 & 6
Washington DC, USA - Oct 25 & 26

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Craig,

Bug landed as https://rt.cpan.org/Ticket/Display.html?id=55783On Mon, Mar 22, 2010 at 4:19 PM, Ruslan Zakirov ruslan.zakirov@gmail.com wrote:

Hello,

It’s limitation and I’m forwarding this email to bugs queue on
rt.cpan.org. I believe it can be improved in Business::Hours and this
module itself to handle wider periods of time, but at this moment I
don’t have time to work on this.

You can either send me patch or order custom development from best
practical to change this.

If you’re going to patch things then you should look at add_seconds
method in Business::Hours module. There is static $MAXTIME variable in
that function. The variable should become an optional argument of the
method and RT::Extension::SLA should generate some reasonable value
depending on the current configuration.

On Mon, Mar 22, 2010 at 1:31 AM, Craig Scott Craig.Scott@stc.ac.uk wrote:

Hi, I’ve encountered what appears to be a limitation in the RT SLA
extension, if the minutes value applied to an SLA is greater then 1000 the
Due date value fails to be set.

For example, we’ve got an SLA for 1 month, which equates to 20, 8.5 hour
days, therefore business minutes for the SLA would be defined as 608.520 –
in practice this doesn’t work, the due date is blank, when i reduce the SLA
to 19 days it works.

I’m guessing there is some sort of limitation in the code?

Craig


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

2010 RT Training Sessions!
San Francisco, CA, USA - Feb 22 & 23
Dublin, Ireland - Mar 15 & 16
Boston, MA, USA - April 5 & 6
Washington DC, USA - Oct 25 & 26

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


Best regards, Ruslan.

Best regards, Ruslan.

Thanks Ruslan, came to same conclusion last night.

I edited the “my $MAXTIME = ( 30 * 24 * 60 * 60 );” in the add_seconds method to “my $MAXTIME = ( 90 * 24 * 60 * 60 );” so it can handle up to 90 days, seams to work OK with no adverse effects noticed yet.

CraigFrom: Ruslan Zakirov [mailto:ruslan.zakirov@gmail.com]
Sent: 22 March 2010 13:20
To: Craig Scott
Cc: rt-users@lists.bestpractical.com; bug-RT-Extension-SLA@rt.cpan.org
Subject: Re: [rt-users] RT SLA Extension

Hello,

It’s limitation and I’m forwarding this email to bugs queue on
rt.cpan.org. I believe it can be improved in Business::Hours and this
module itself to handle wider periods of time, but at this moment I
don’t have time to work on this.

You can either send me patch or order custom development from best
practical to change this.

If you’re going to patch things then you should look at add_seconds
method in Business::Hours module. There is static $MAXTIME variable in
that function. The variable should become an optional argument of the
method and RT::Extension::SLA should generate some reasonable value
depending on the current configuration.