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

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@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.

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@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
Carbon60: Managed Cloud Services

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.scotto@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.

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@reply.it
www.reply.it

Inizio: Ruslan Zakirov [ruslan.zakirov@gmail.com]
Inviato: sabato 9 giugno 2012 13.21
Fine: Scotto Alberto
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@reply.itmailto:al.scotto@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

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@reply.ithttp://al.scotto@reply.it
www.reply.ithttp://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.

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@reply.it
www.reply.it

Inizio: Scotto Alberto
Inviato: sabato 9 giugno 2012 19.38
Fine: Ruslan Zakirov
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@reply.it<UrlBlockedError.aspx>
www.reply.it<UrlBlockedError.aspx>

Inizio: Ruslan Zakirov [ruslan.zakirov@gmail.com]
Inviato: sabato 9 giugno 2012 13.21
Fine: Scotto Alberto
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@reply.itmailto:al.scotto@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

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@reply.ithttp://al.scotto@reply.it
www.reply.ithttp://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.

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.scotto@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.scotto@reply.it http://UrlBlockedError.aspx
www.reply.it http://UrlBlockedError.aspx


Inizio: Ruslan Zakirov [ruslan.zakirov@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.

написал:

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
Carbon60: Managed Cloud Services

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.scotto@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.



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.

Best regards, Ruslan.

Dnia 2012-06-09, sob o godzinie 22:50 +0400, Ruslan Zakirov pisze:

    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

Dnia 2012-06-09, sob o godzinie 22:50 +0400, Ruslan Zakirov pisze:

    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.

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

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-slaOn Tue, Jun 19, 2012 at 9:39 AM, Robert Wysocki robert.wysocki@contium.pl 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.