[rt-users] SLA reporting

[Asif Iqbal]

On Fri, Feb 17, 2012 at 10:48 AM, Ruslan Zakirov <ruz at bestpractical.com>
wrote:

> Hi,
>
> There is a custom branch in the repository that makes a stab at
> calculating whether people met deadlines or not. It's not complete,
>


I could not find it under different branches of the github repo
 https://github.com/bestpractical/rt

Can you provide a link please? I need to generate sla report monthly


Thanks for your help


but it's a good start. This code walks history of a ticket and
> calculates whether configured deadlines were met or not.
>
> Your idea with crontool is bad.
>
> It's better to use scrips with on correspond and on resolve
> conditions. With this solution you get accurate statistics, but you
> get it late to react.


> On Fri, Feb 17, 2012 at 18:19, Soula, Christophe <csoula at hach-lange.com>
> wrote:
> > Hi,
> >
> >
> >
> > We are using RT4.02 for our IT service Center with SLA module defining
> start
> > and due date (Response time and resolution time as defined in
> > RT_Siteconfig.pm).
> >
> > My concern right now is to find a way to report Performance against the
> SLA
> > at two level:
> >
> > -          Response time
> >
> > -          Resolution time
> >
> >
> >
> > The idea we have is to use rt-crontool to store into CF Request already
> late
> > in regards of response time and also in regards of resolution time
> >
> >
> >
> > For response time the query could be something like : Status = 'new' AND
> > TimeLeft > 0
> >
> > For resolution time the query could be something like : TimeLeft > 0 AND
> (
> > Status = 'open' OR Status = 'stalled' )
> >
> >
> >
> > Now the idea is to set a specific hidden CF called LateResponse and
> > LateResolution with value 0 or 1 to keep a track of late response or late
> > resolution
> >
> > The solution to update the CF could be to use then bin/rt/ command line.
> >
> >
> >
> > And finally query directly the MySQL DB to get our report.
> >
> >
> >
> > Is there any other idea to create this report from your point of view
> >
> >
> >
> > thanks
> >
> >
> > Please be advised that this email may contain confidential information.
> If
> > you are not the intended recipient, please notify us by email by
> replying to
> > the sender and delete this message. The sender disclaims that the
> content of
> > this email constitutes an offer to enter into, or the acceptance of, any
> > agreement; provided that the foregoing does not invalidate the binding
> > effect of any digital or other electronic reproduction of a manual
> signature
> > that is included in any attachment.
> >
> > --------
> > RT Training Sessions (http://bestpractical.com/services/training.html)
> > * Boston — March 5 & 6, 2012
>
>
>
> --
> Best regards, Ruslan.
> --------
> RT Training Sessions (http://bestpractical.com/services/training.html)
> * Boston  March 5 & 6, 2012




-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140531/6d39a80a/attachment.htm>