Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
Hi, We've implemented something that is simple and should work in most common cases. You can try it from our repository. Note that it needs a DB upgrade. https://github.com/bestpractical/rt-extension-sla On Tue, Jun 19, 2012 at 9:39 AM, Robert Wysocki wrote: > Dnia 2012-06-12, wto o godzinie 18:24 +0400, Ruslan Zakirov pisze: >> >> Sorry. Didn't notice that. >> >> I'm not sure why you need additional data storage. > > Additional storage in form of CF's in my solution is merely a product of > the lack of time. I needed it to work and the simplest way was then for > me to code it like this. > Now I see some other options; I belive that if I move the scrip-part of > the code to module code I won't have the need for additional storage any > more. > >> I see putting Due >> date on hold in the following way: >> >> 1) When status is changed from initial/active to some that marked as >> "on hold", we just unset Due date. We can not keep old value in the >> Due field as it will mess sorting of tickets. >> >> 2) When status is changed from "on hold" to any active, we >> re-calculate Due date. > > That sounds good. > >> Re-calculation is hard to make sane. RT out of the box opens tickets >> on replies, so reply and activation from "on hold" events match. > > In our case we decided that in the event of re-activating ticket after > it was parked for some time we change it's status to "open". So we > really don't care about what other scrips do to tickets' status - our > logic goes the other way. > >> This >> case is very simple, we treat it as any other reply. > > We shoudn't change status to "open" if reply wasn't from one of the > requestors - ticket should stay parked. > >> It becomes questionable when people disable "auto open" on some >> replies. There are several interesting timelines that may happen: >> >> 1) reply ... on hold ... no replies ... activation >> 2) reply ... on hold ... reply(ies) ... activation >> >> In first case due date can be calculated from reply plus time ticket >> was on hold. Second case is harder and I'm still not sure how to treat >> it. > > In our logic there's no place for ticket activation when there was no > reply from one of the requestors. > In other words if someone will activate a parked ticket "by hand" > recalculation won't happen. > > Best regards, > > -- > Robert Wysocki > administrator systemów linuksowych > Contium S.A., http://www.contium.pl > > -- Best regards, Ruslan.
Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
Dnia 2012-06-12, wto o godzinie 18:24 +0400, Ruslan Zakirov pisze: > > Sorry. Didn't notice that. > > I'm not sure why you need additional data storage. Additional storage in form of CF's in my solution is merely a product of the lack of time. I needed it to work and the simplest way was then for me to code it like this. Now I see some other options; I belive that if I move the scrip-part of the code to module code I won't have the need for additional storage any more. > I see putting Due > date on hold in the following way: > > 1) When status is changed from initial/active to some that marked as > "on hold", we just unset Due date. We can not keep old value in the > Due field as it will mess sorting of tickets. > > 2) When status is changed from "on hold" to any active, we > re-calculate Due date. That sounds good. > Re-calculation is hard to make sane. RT out of the box opens tickets > on replies, so reply and activation from "on hold" events match. In our case we decided that in the event of re-activating ticket after it was parked for some time we change it's status to "open". So we really don't care about what other scrips do to tickets' status - our logic goes the other way. > This > case is very simple, we treat it as any other reply. We shoudn't change status to "open" if reply wasn't from one of the requestors - ticket should stay parked. > It becomes questionable when people disable "auto open" on some > replies. There are several interesting timelines that may happen: > > 1) reply ... on hold ... no replies ... activation > 2) reply ... on hold ... reply(ies) ... activation > > In first case due date can be calculated from reply plus time ticket > was on hold. Second case is harder and I'm still not sure how to treat > it. In our logic there's no place for ticket activation when there was no reply from one of the requestors. In other words if someone will activate a parked ticket "by hand" recalculation won't happen. Best regards, -- Robert Wysocki administrator systemów linuksowych Contium S.A., http://www.contium.pl
Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
On Mon, Jun 11, 2012 at 10:45 AM, Robert Wysocki wrote: > Dnia 2012-06-09, sob o godzinie 22:50 +0400, Ruslan Zakirov pisze: >> >> >> On Sat, Jun 9, 2012 at 10:17 PM, Scotto Alberto >> wrote: >> Much better, following KISS rule: we could simply use hidden >> CFs to store temporary values! >> This way it's much cleaner, isn't it? >> >> >> >> Have you seen Attributes class/table in RT. It's designed for such >> things. Store anything developer like tied to any RT object. >> > > Actually few days ago I posted my solution for parking tickets that uses > two extra CF's and also asked in the same post is there any way to avoid > those. Unfortunately I didn't get any answer then, now I have one. Sorry. Didn't notice that. I'm not sure why you need additional data storage. I see putting Due date on hold in the following way: 1) When status is changed from initial/active to some that marked as "on hold", we just unset Due date. We can not keep old value in the Due field as it will mess sorting of tickets. 2) When status is changed from "on hold" to any active, we re-calculate Due date. Re-calculation is hard to make sane. RT out of the box opens tickets on replies, so reply and activation from "on hold" events match. This case is very simple, we treat it as any other reply. It becomes questionable when people disable "auto open" on some replies. There are several interesting timelines that may happen: 1) reply ... on hold ... no replies ... activation 2) reply ... on hold ... reply(ies) ... activation In first case due date can be calculated from reply plus time ticket was on hold. Second case is harder and I'm still not sure how to treat it. So my question is how do you want this to work? If you have sane ideas, I would love to know. > Regards, > > -- > Robert Wysocki > administrator systemów linuksowych > Contium S.A., http://www.contium.pl -- Best regards, Ruslan.
Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
Dnia 2012-06-09, sob o godzinie 22:50 +0400, Ruslan Zakirov pisze: > > > On Sat, Jun 9, 2012 at 10:17 PM, Scotto Alberto > wrote: > Much better, following KISS rule: we could simply use hidden > CFs to store temporary values! > This way it's much cleaner, isn't it? > > > > Have you seen Attributes class/table in RT. It's designed for such > things. Store anything developer like tied to any RT object. > Actually few days ago I posted my solution for parking tickets that uses two extra CF's and also asked in the same post is there any way to avoid those. Unfortunately I didn't get any answer then, now I have one. Regards, -- Robert Wysocki administrator systemów linuksowych Contium S.A., http://www.contium.pl
Re: [rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
On Sat, Jun 9, 2012 at 10:17 PM, Scotto Alberto wrote: > Much better, following KISS rule: we could simply use hidden CFs to > store temporary values! > This way it's much cleaner, isn't it? > Have you seen Attributes class/table in RT. It's designed for such things. Store anything developer like tied to any RT object. 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 > > [image: Blue] > Via Cardinal Massaia, 83 > 10147 - Torino - ITALY > phone: +39 011 29100 > al.sco...@reply.it > www.reply.it > > -- > *Inizio:* Scotto Alberto > *Inviato:* sabato 9 giugno 2012 19.38 > *Fine:* Ruslan Zakirov > *Cc:* rt-users@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 > > [image: Blue] > Via Cardinal Massaia, 83 > 10147 - Torino - ITALY > phone: +39 011 29100 > al.sco...@reply.it <http://UrlBlockedError.aspx> > www.reply.it <http://UrlBlockedError.aspx> > > ---------------------- > *Inizio:* Ruslan Zakirov [ruslan.zaki...@gmail.com] > *Inviato:* sabato 9 giugno 2012 13.21 > *Fine:* Scotto Alberto > *Cc:* rt-users@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" > написал: > >> 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; &g
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" написал:
> 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
>
> [image: Blue]
> Via Cardinal Massaia, 83
> 10147 - Torino - ITALY
> phone: +39 011 29100
> al.sco...@reply.it
> 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.
>
<>
[rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
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.sco...@reply.it
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.
<>
