[rt-users] SLA module in international environment
Bart
bart at pleh.info
Thu Nov 24 05:14:46 EST 2011
Not sure about the SLA times, maybe someone else can elaborate on that?
-- Bart
Op 24 november 2011 11:13 schreef Bart <bart at pleh.info> 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 <csoula at hach-lange.com
> > 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111124/94534e6e/attachment.htm>
More information about the rt-users
mailing list