On Fri, Feb 17, 2012 at 10:48 AM, Ruslan Zakirov <[email protected]> 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 <[email protected]> > 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?
-- RT Training - Boston, September 9-10 http://bestpractical.com/training
