[rt-users] RT::Extension::SLA -- problems

William Graboyes william.graboyes at theportalgrp.com
Mon Jul 6 18:25:16 EDT 2009


Hi Ruslan,

> Do I understand it right that you want to set resolve deadline
> manually and keep reply deadline from the config? The only thing that
> I have in mind and want to implement some day is "manual resolve
> deadline". When a person sets due date on  a ticket manually then this
> date used as resolve deadline and extension changes due dates
> according to the current doc.
>
> Hope that description is clear enough. Is it close to your
> requirements? I can not say that it will be in the next version or any
> time soon, dates guaranted only if it's sponsored work. Patches are
> always welcome at no charge.

That sounds about right, basically I would think it could be as simple as an
if-then check... something along the lines of, if SLA hasn't changed, then
don't run the SLA date change... else run the sla date change.  I may even
attempt to hack it out.

Yay, sandbox time.

> Sounds reasonable, but not sure how make this transparent and trigger
> "re-open" event. Too many variants for different workflows. It may be
> possbile to adjust scrips and come up with required setup even with
> the current version, but I'm not sure.

Could just add it as a config flag, time stalls when stalled... when a
ticket is coresponded to the ticket automagically changes state from stalled
to open, really could just be a scrip action based on the change of state
from stalled to opened.

if the above was implimented, with a manual due date override, the latter
would be fairly easy, just some simple time changes and math.

Thanks,
Bill Graboyes

On Mon, Jul 6, 2009 at 1:52 PM, Ruslan Zakirov <ruslan.zakirov at gmail.com>wrote:

> On Mon, Jul 6, 2009 at 10:30 PM, William
> Graboyes<william.graboyes at theportalgrp.com> wrote:
> > Hi Ruslan,
> >
> >> What are you trying to achive?
> >
> > We have some SLA Categories that the due dates are "as mutually agreed
> upon"
> > Thus they are sending a due date along with the ticket.
> >
> >> How is extension is configured?Set( %ServiceBusinessHours, (
>
> [snip]
>
> > );
> >> I want to know more about use case to understand if it's possible to
> >> improve this extension.
> >
> > The use case is as explained more or less above, where the due date is
> > determined either via the logging and classification of the ticket, or
> via
> > contact with the requester.  Most of the service levels that we have do
> have
> > very hard due dates, just a couple of categories have soft due dates.
> > Sometimes the due dates need to move, even in the categories that have
> hard
> > SLA due dates, simply because of incomplete information from the
> requester.
>
>
> Do I understand it right that you want to set resolve deadline
> manually and keep reply deadline from the config? The only thing that
> I have in mind and want to implement some day is "manual resolve
> deadline". When a person sets due date on  a ticket manually then this
> date used as resolve deadline and extension changes due dates
> according to the current doc.
>
> Hope that description is clear enough. Is it close to your
> requirements? I can not say that it will be in the next version or any
> time soon, dates guaranted only if it's sponsored work. Patches are
> always welcome at no charge.
>
> > While we are on the topic of improvements.
> >
> > I would also like to see the due date shift the amount of time that the
> > ticket was stalled upon re-open.  For our organization we use the stalled
> > status to indicate that the "ball is out of our court" in other words we
> are
> > waiting for input from some other source.
>
> Sounds reasonable, but not sure how make this transparent and trigger
> "re-open" event. Too many variants for different workflows. It may be
> possbile to adjust scrips and come up with required setup even with
> the current version, but I'm not sure.
>
>
> >
> > Thanks,
> >
> > Bill Graboyes
> >
> > On Mon, Jul 6, 2009 at 10:47 AM, Ruslan Zakirov <
> ruslan.zakirov at gmail.com>
> > wrote:
> >>
> >> Nope, cuz SLA extension is used to automate due date management. What
> >> are you trying to achive? How is extension is configured? I want to
> >> know more about use case to understand if it's possible to improve
> >> this extension.
> >>
> >> On Mon, Jul 6, 2009 at 9:12 PM, William
> >> Graboyes<william.graboyes at theportalgrp.com> wrote:
> >> > Hi all,
> >> >
> >> > I am having a problem with the SLA module.
> >> >
> >> > Any time we change a due date, The SLA module changes it back to the
> >> > prescribed due date in the config file.
> >> >
> >> > Is there any way to change this behavior?
> >> >
> >> > RT Version: 3.8.4
> >> >
> >> > --
> >> > Bill Graboyes
> >> > On Assignment At:
> >> > Toyota Motor Sales, USA, Inc.
> >> > Consumer Portal Delivery
> >> > Office: (310) 468-6754
> >> > Cell: (714) 515-8312
> >> >
> >> > _______________________________________________
> >> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >> >
> >> > Community help: http://wiki.bestpractical.com
> >> > Commercial support: sales at bestpractical.com
> >> >
> >> >
> >> > Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> >> > Buy a copy at http://rtbook.bestpractical.com
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards, Ruslan.
> >
> >
> >
> > --
> > Bill Graboyes
> > On Assignment At:
> > Toyota Motor Sales, USA, Inc.
> > Consumer Portal Delivery
> > Office: (310) 468-6754
> > Cell: (714) 515-8312
> >
>
>
>
> --
> Best regards, Ruslan.
>



-- 
Bill Graboyes
On Assignment At:
Toyota Motor Sales, USA, Inc.
Consumer Portal Delivery
Office: (310) 468-6754
Cell: (714) 515-8312
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20090706/31d8e787/attachment.htm>


More information about the rt-users mailing list