Not sure about the SLA times, maybe someone else can elaborate on that? -- Bart
Op 24 november 2011 11:13 schreef Bart <[email protected]> het volgende: > Not sure if this is how you'd want to solve this but here's a thought on > what you could do. > > 1) Hide the SLA field from view (or only show the content, basically the > goal is to not give users the ability to edit the field themselves) > > 2) Create a queue specific scrip which sets the SLA value based on either > simply the queue name (which can be done with the SLA plugin) or based on > the priority field or other CF fields. > > For the latter we have the following setup: > > - A CF called "Ticket Priority", dropdown (to prevent error input, could > be done with the priority to string plugin as well) > - A CF called "Ticket Type" (incident, problem, change as possible values) > - And the SLA field with possible values named "4, 8, 24, 48" respectively > related to the amount of hours. > > Then with the following scrip we set the SLA value based on the > combination Ticket Priority and Ticket Type, this scrip could be simplified > to only match priority or even match other CF's: > > * Condition: On Transaction > * Action: User Defined > * Template: Blank > * Stage: Transaction Batch > * Custom condition: <empty> > * Custom action prep: return 1; > * Custom action cleanup: > > my $my_type = $self->TicketObj->FirstCustomFieldValue('Ticket Type'); > my $my_prio = $self->TicketObj->FirstCustomFieldValue('Ticket Prioriteit'); > > if($my_type =~ /^I/ && $my_prio == '1') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '4'); > $self->TicketObj->SetPriority ('1'); } > if($my_type =~ /^I/ && $my_prio == '2') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '8'); > $self->TicketObj->SetPriority ('2'); } > if($my_type =~ /^I/ && $my_prio == '3') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '24'); > $self->TicketObj->SetPriority ('3'); } > if($my_type =~ /^I/ && $my_prio == '4') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '48'); > $self->TicketObj->SetPriority ('4'); } > > if($my_type =~ /^UC_I/ && $my_prio == '1') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '4'); > $self->TicketObj->SetPriority ('1'); } > if($my_type =~ /^UC_I/ && $my_prio == '2') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '8'); > $self->TicketObj->SetPriority ('2'); } > if($my_type =~ /^UC_I/ && $my_prio == '3') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '24'); > $self->TicketObj->SetPriority ('3'); } > if($my_type =~ /^UC_I/ && $my_prio == '4') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '48'); > $self->TicketObj->SetPriority ('4'); } > > if($my_type =~ /^P/ && $my_prio == '1') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '48'); > $self->TicketObj->SetPriority ('1'); } > if($my_type =~ /^P/ && $my_prio == '2') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '48'); > $self->TicketObj->SetPriority ('2'); } > if($my_type =~ /^P/ && $my_prio == '3') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '48'); > $self->TicketObj->SetPriority ('3'); } > if($my_type =~ /^P/ && $my_prio == '4') { > $self->TicketObj->AddCustomFieldValue(Field => 'SLA', Value => '480'); > $self->TicketObj->SetPriority ('4'); } > > In addition this scrip makes sure that the CF Priority is leading, when > the SLA is set it changes the priority field (the default one) to the value > of the CF. > > We chose the CF solution for the priority because this field is also > visible during ticket creation (easy input for users). > > Modifying this scrip to match your flows should be quite easy + this can > be queue specific. > > Because it's queue specific we chose to name the SLA fields values (sla's) > based on the amount of hours, this makes it easier to reuse those values in > different queue's. > > Hopefully this gives you some ideas. > > > -- Bart > > > Op 24 november 2011 10:46 schreef Soula, Christophe <[email protected] > > het volgende: > >> I have setup the SLA extension 0.05 (Business::Hours 0.09) and works >> pretty well if I focus it on one single timezone but my problem is still >> that I have IT team in Europe (Timezone Europe/Berlin) and IT team in US >> (Timezone : America/Denver).**** >> >> At this step and moving from Mod_perl to fastcgi I’m able to set per user >> timezone and display the right time for EU and US associates.**** >> >> Please find here the SLA part of my RT_SiteConfig.pm (RT 4.02):**** >> >> ** ** >> >> %RT::ServiceAgreements = (**** >> >> Default => 'Priority 1',**** >> >> ** ** >> >> QueueDefault => {**** >> >> 'US_IT_Service_Center' => 'HachIT',**** >> >> Europe_IT_Service_Center' => 'Priority 1',**** >> >> },**** >> >> Levels => {**** >> >> 'HachIT' => {**** >> >> BusinessHours => 'US1',**** >> >> Response => { BusinessMinutes => 15 },**** >> >> Resolve => { BusinessMinutes => 60*4 },**** >> >> },**** >> >> 'Priority 1' => {**** >> >> BusinessHours => 'Europe1',**** >> >> Response => { BusinessMinutes => 15 },**** >> >> Resolve => { BusinessMinutes => 60*4 },**** >> >> },**** >> >> 'Priority 2' => {**** >> >> BusinessHours => 'Europe1',**** >> >> Response => { BusinessMinutes => 30 },**** >> >> Resolve => { BusinessMinutes => 60*8*4 },**** >> >> },**** >> >> 'Priority 3' => {**** >> >> BusinessHours => 'Europe1',**** >> >> Response => { BusinessMinutes => 45 },**** >> >> Resolve => { BusinessMinutes => 60*8*20 },**** >> >> },**** >> >> },**** >> >> );**** >> >> %RT::ServiceBusinessHours = (**** >> >> 'US1' => {**** >> >> 0 => { Name => 'Sunday', Start => undef, End => undef },* >> *** >> >> 1 => { Name => 'Monday', Start => '15:00', End => '23:59' >> },**** >> >> 2 => { Name => 'Tuesday', Start => '15:00', End => >> '23:59' },**** >> >> 3 => { Name => 'Wednesday', Start => '15:00', End => >> '23:59' },**** >> >> 4 => { Name => 'Thursday', Start => '15:00', End => >> '23:59' },**** >> >> 5 => { Name => 'Friday', Start => '15:00', End => '23:59' >> },**** >> >> 6 => { Name => 'Saturday', Start => undef, End => undef }, >> **** >> >> },**** >> >> 'Europe1' => {**** >> >> 0 => { Name => 'Sunday', Start => undef, End => undef },* >> *** >> >> 1 => { Name => 'Monday', Start => '07:00', End => '17:00' >> },**** >> >> 2 => { Name => 'Tuesday', Start => '07:00', End => >> '17:00' },**** >> >> 3 => { Name => 'Wednesday', Start => '07:00', End => >> '17:00' },**** >> >> 4 => { Name => 'Thursday', Start => '07:00', End => >> '17:00' },**** >> >> 5 => { Name => 'Friday', Start => '07:00', End => '17:00' >> },**** >> >> 6 => { Name => 'Saturday', Start => undef, End => undef }, >> **** >> >> },**** >> >> );**** >> >> ** ** >> >> ** ** >> >> I have some issue at this step that I will try to explain here:**** >> >> **· **SLA is a global CF create during the make initdb once >> installing the SLA extension that means that the same CF is used for my two >> queue ('US_IT_Service_Center' and ‘Europe_IT_Service_Center')**** >> >> **· **SLA CF is configured as “select one value” and get at >> this step three value (Priority 1 – Priority 2 and priority 3)**** >> >> ** ** >> >> First issue : How to setup priority 1 2 and 3 based on the two different >> Set of Business Hours (not covered in my example of SLA setup)**** >> >> ** ** >> >> Second issue : What are the best practice to use efficiently this SAL >> extension in my environment**** >> >> In my example **** >> >> **- **US team is working from 07:00 to 17:00 (Denver time)**** >> >> **- **EU team is working from 07:00 to 17:00 (Berlin time)**** >> >> The only “solution” find to realize this is to fake the system for the US >> business hour but this is not possible if I keep the actual server timezone >> like this :**** >> >> We should cover on each side 10 hours of business hour but if you look at >> the example below you will see that my fake for the US1 business hours can >> only cover 9 hours (15:00 -> 23:59) **** >> >> ** ** >> >> Thanks,**** >> >> ** ** >> >> *Christophe***** >> >> 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) >> * Barcelona, Spain — November 28 & 29, 2011 >> > >
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * Barcelona, Spain November 28 & 29, 2011
