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

[Steve OBrien]

Thanks Matthew!
I am still a bit foggy on how to use this module and what it really
does.  I configured the custom fields with a sort value, name and
description (I did not know what to put for category).

Care to share your ColorMap config with the SLA priorities?

TIA,
Steve

On Tue, 2009-02-17 at 11:42 -0800, Matthew Seaman wrote:
> Ruslan Zakirov wrote:
> > [snip]
> > 
> >> You just need to configure the SLA custom field in the usual way -- as a
> >> 'Select one value' and then add your service levels as the list of available
> >> options.  Now when you go to set the SLA on a ticket it should automatically
> >> set the 'Starts' and 'Due' dates on the ticket.  You'll need to set up
> >> rt-crontool
> >> to run at regular intervals -- given your 'System Inoperable' SLA is two
> >> hours,
> >> you'll probably need to run it more frequently than hourly.  You may want to
> >> Google
> >> for ways of supressing the rt-crontool transactions from ticket histories
> >> lest they
> >> swamp all other  transactions.
> > 
> > Matthew,
> > 
> > I don't understand why you're suggesting crontool here, can you describe?
> > 
> > RT::Extension::SLA shipped with pretty good scrips that can be
> > disabled and re-enabled to turn off or turn back on some
> > functionality. For example it has scrip that sets default value of the
> > SLA according to the config. Starts/Due dates are set by another scrip
> > which doesn't care when and by whom SLA CF has be changed. Such setup
> > allows you to disable assigning of default service level for tickets
> > and set them manually for every ticket (some companies may like it).
> > 
> > [snip]
> > 
> 
> Apologies.  I'm too much in the thick of things right now that I'm losing
> track of what is local customisation and what is add-on module and what is
> core functionality.  I guess we will be using the SLA stuff a bit differently
> to how it was initially conceived.
> 
> We're in the process of replacing an ancient and  distinctly unsatisfactory
> ticketing system with RT.  What we've done is set up a '[_1] Highest Priority
> Tickets in the Support Queue' search portlet on the At-a-Glance screen for
> our Support team, displayed in descending order of priority.  There will be
> an on-duty Support person 24x7 one of whose tasks will be to watch for incoming
> support requests and assign SLA values according to the nature of the problem:
> these can vary from '10 business days' for routine things like renewing SSL certificates down to 1 hour for a 'Service Down' incident.
> 
> We also use a modification of the 'StatusInColour' customization from the
> Wiki to colour the items based on the value of the priority field (Well, we
> will be. I upgraded from 3.6.7 to 3.8.2 yesterday and haven't quite got round
> to porting that bit over yet.  Tomorrow probably)  The idea is: if it's at the
> top of the priority list, then that's the next thing to work on, and if it's
> coloured bright red, it really needs attention *right* *now*.
> 
> This works by using rt-crontool with LinearEscalate to raise ticket priorities
> as they get closer to their due dates.  We're running rt-crontool for the
> Support queue every 15 minutes -- however as all the tickets default to using
> the Queue's default initial and final priorities (0 and 99 respectively) it
> means an urgent problem with a SLA of an hour only gets 3 or 4 updates before
> it's overdue, and it would only tend to come to the top of the list on the last
> update.  Hence the desire to automatically set initial and final priorities based
> on the manually chosen SLA value.
> 
> 	Cheers,
> 
> 	Matthew