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 -- Dr Matthew Seaman The Bunker, Ash Radar Station PGP: 0x60AE908C on servers Marshborough Rd Tel: +44 1304 814890 Sandwich Fax: +44 1304 814899 Kent, CT13 0PL, UK
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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