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 _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com