[rt-users] [SLA] Custom (and very imperfect) solution for parking stalled tickets
Ruslan Zakirov
ruslan.zakirov at gmail.com
Sat Jun 9 14:50:02 EDT 2012
On Sat, Jun 9, 2012 at 10:17 PM, Scotto Alberto <al.scotto at reply.it> 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.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
>
> [image: Blue]
> Via Cardinal Massaia, 83
> 10147 - Torino - ITALY
> phone: +39 011 29100
> al.scotto at reply.it <http://UrlBlockedError.aspx>
> www.reply.it <http://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>
> написал:
>
>> 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.scotto at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/8e09c234/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/8e09c234/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/8e09c234/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue.png
Type: image/png
Size: 2834 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120609/8e09c234/attachment-0002.png>
More information about the rt-users
mailing list