[rt-users] R: [SLA] Custom (and very imperfect) solution for parking stalled tickets

Scotto Alberto al.scotto at reply.it
Sat Jun 9 14:17:58 EDT 2012


Much better, following KISS rule: we could simply use hidden CFs to store temporary values!
This way it's much cleaner, isn't it?

The only pain is that I would have to reconfigure ACL, since I used to give Everyone the SeeCustomField right.
BTW ACL is not much featured at all... In this case it would be great if I could *deny* the SeeCustomField right for just one specific CF, instead of having to *grant* the right selectively.

Anyway, IMHO disallowing the update of some of the tickets' attributes is still useful (e.g. to avoid that malicious AdminCCs set Due date forward) and still I'd like some help about it.

Thank you,
have a nice week end





Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it
www.reply.it


________________________________
Inizio: Scotto Alberto
Inviato: sabato 9 giugno 2012 19.38
Fine: Ruslan Zakirov
Cc: rt-users at lists.bestpractical.com
Oggetto: R: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets

Yep, I think it would be cool.
But you should also help me dealing with assumption #2: I'd like to disallow the modification of the tickets' attributes involved. Maybe not to everyone; maybe we could work with ACEs, splitting the ModifyTicket right in ModifyTicket and ModifyDates, or something like that.
What do you think?





Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it<UrlBlockedError.aspx>
www.reply.it<UrlBlockedError.aspx>


________________________________
Inizio: Ruslan Zakirov [ruslan.zakirov at gmail.com]
Inviato: sabato 9 giugno 2012 13.21
Fine: Scotto Alberto
Cc: rt-users at lists.bestpractical.com
Oggetto: Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets


I'm glad if it works for you. Would like to see functionality in extension. Your solution needs refactoring to be merged. If you like I can guide you and help put it into shape for merge.

Ruslan from phone.

08.06.2012 2:24 пользователь "Scotto Alberto" <al.scotto at reply.it<mailto:al.scotto at reply.it>> написал:
Working with the SLA Extension, I came across the problem of stalled tickets: by default, there is no way to stop the "timer" for the due date when a ticket becomes stalled, as stated by the author in
http://www.gossamer-threads.com/lists/rt/users/105845#105845

So I've just implemented a small customization (very imperfect indeed) and I want to share it with all of you. Feel free to contribute, and please share your improvements.

First of all, a few assumptions (aka limitations):
- in $RT::ServiceBusinessHours we defined only 'Default' ServiceBusinessHours
- users will not modify the date fields we set, otherwise everything would screw up

The idea is to move the due date forward as soon as the ticket exits the stalled status. To compute the new due date we need to know when the tickets became stalled. So, we first have to save somewhere the time when it became stalled: we temporarly save it in the Resolved attribute (very dirty, I know..!), which shouldn't be used while stalled.

This solution includes two actions, two conditions, and two scrips which put everything together.

Conditions, which you can easily build thanks to sbin/rt-setup-database and the ExecModule StatusChange:
- on stalled
- on un-stall

Actions (the code is below):
- Set resolved temporarly
- Update due date on un-stall

Scrips:
- On stalled Set resolved temporarly
- On un-stall Update due date


I think the most important improvement would be to avoid the use of the Resolved attribute as temporary. Instead, it would be better to define a new private attribute in Ticket.pm; consequently, a new column in the DB, etc.

Of course, I will appreciate any suggestions, comments, etc.

Thanks

AS


======== Action1. Set resolved temporarly =====
my $tkt = $self->TicketObj;
my $id = $tkt->Id;
my $stalled_date = RT::Date->new( $RT::SystemUser );
$stalled_date->SetToNow;
my ($status, $msg) = $tkt->_Set(
       Field => 'Resolved',
       Value => $stalled_date->ISO,
       RecordTransaction => 0
);
unless ( $status ) {
    $RT::Logger->error("Unable to set Resolved date to ticket #$id: $msg");
    return 0;
}
$RT::Logger->debug("Set Resolved date of ticket #". $id . " to ". $stalled_date->ISO);
return 1;
===================================

======== Action2. Update due date on un-stall =====
my $t = $self->TicketObj;
my $id = $t->Id;
use Business::Hours;

my $now = RT::Date->new( $RT::SystemUser );
$now->SetToNow;
my $bhours = Business::Hours->new();
$bhours->business_hours( %{ $RT::ServiceBusinessHours{ 'Default' } } );
my $delta = $bhours->between($t->ResolvedObj->Unix, $now->Unix);
my $new_due = $bhours->add_seconds($t->DueObj->Unix, $delta);

my $due_date = RT::Date->new( $RT::SystemUser );
$due_date->Set(Format => 'unix', Value => $new_due );
# finally set new due date
my ($status, $msg) = $t->_Set(
       Field => 'Due',
       Value => $due_date->ISO,
       RecordTransaction => 0
);
# if the two transitions (*->stalled and stalled->*) take place out of hours,
# in the same interval, then $delta will be 0
if( !($t->DueObj->Diff($due_date)) ) {
    $RT::Logger->debug("Unable to set Due date to ticket #$id: new_due_date = old_due_date " . $due_date->ISO);
}
elsif ( !($status) )  {
    $RT::Logger->error("Unable to set Due date to ticket #$id: $msg");
    return 0;
}
# reset Resolved date
($status, $msg) = $t->_Set(
       Field => 'Resolved',
       Value => 0,
       RecordTransaction => 0
);
unless ( $status ) {
    $RT::Logger->error("Unable to reset Resolved date to ticket #$id: $msg");
}
$RT::Logger->debug("Due date updated after un-stalling ticket #". $id );
return 1;
==============================



Alberto Scotto

[Blue]
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it<http://al.scotto@reply.it>
www.reply.it<http://www.reply.it>


________________________________

--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

________________________________

--
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/9d321dae/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: blue.png
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/9d321dae/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: blue.png
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/9d321dae/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: blue.png
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/9d321dae/attachment-0002.png>


More information about the rt-users mailing list