[rt-users] rt-crontool change priority silently?

Kenneth Marshall ktm at rice.edu
Wed Jan 14 09:44:17 EST 2009


On Wed, Jan 14, 2009 at 01:38:11PM +0000, Adam Smith wrote:
> I was wondering if there was a way to make rt-crontool increase  
> priority over time but without setting a History entry each time it  
> updates?
> 
> I am using the following command :
> 
> /opt/rt3/bin/rt-crontool --verbose --search RT::Search::FromSQL -- 
> search-arg "Queue='58' AND 'CF.{Internal Status}' LIKE 'Accepted'" -- 
> action RT::Action::EscalatePriority
> 
> I want my priority to move up but I don't want the History to be  
> overloaded with dozens of lines should any ticket be sitting silent  
> for that long.
> 
> 
> Adam
> 
Adam,

You need to add a action that increments the priority without
recording the transaction. Here is a diff off the version that
records and the one that does not:

--- ./local/lib/RT/Action/IncrementPriorityNoRecord.pm  2005-07-20 08:28:59.000000000 -0500
+++ ./local/lib/RT/Action/IncrementPriority.pm  2005-05-27 09:11:20.000000000 -0500
@@ -43,7 +43,7 @@
 # those contributions and any derivatives thereof.
 # 
 # }}} END BPS TAGGED BLOCK
-package RT::Action::IncrementPriorityNoRecord;
+package RT::Action::IncrementPriority;
 require RT::Action::Generic;
 
 use strict;
@@ -83,17 +83,16 @@
 
 sub Commit {
     my $self = shift;
-#   my ($val, $msg) = $self->TicketObj->SetPriority($self->{'prio'});
-   my ($val, $msg) = $self->TicketObj->_Set(Field => 'Priority', Value => $self->{'prio'}, RecordTransaction => 0);
+   my ($val, $msg) = $self->TicketObj->SetPriority($self->{'prio'});
 
    unless ($val) {
         $RT::Logger->debug($self . " $msg\n");
    }
 }
 
-eval "require RT::Action::IncrementPriorityNoRecord_Vendor";
-die $@ if ($@ && $@ !~ qr{^Can't locate RT/Action/IncrementPriorityNoRecord_Vendor.pm});
-eval "require RT::Action::IncrementPriorityNoRecord_Local";
-die $@ if ($@ && $@ !~ qr{^Can't locate RT/Action/IncrementPriorityNoRecord_Local.pm});
+eval "require RT::Action::IncrementPriority_Vendor";
+die $@ if ($@ && $@ !~ qr{^Can't locate RT/Action/IncrementPriority_Vendor.pm});
+eval "require RT::Action::IncrementPriority_Local";
+die $@ if ($@ && $@ !~ qr{^Can't locate RT/Action/IncrementPriority_Local.pm});
 
 1;
----------------------

I do have one comment about priority escalation. We implemented it
and had very poor results. The major problem is that tickets or
incidents importance or relative importance was not a function of
the time since being logged. The priority needs to be aggressively
tied to resource allocations, otherwise you end up with "high priority"
tickets, as a result of escalation, that are ignored because a really
important new ticket was just logged. We also found that the auto
escalation devalued the contents of the priority value and made it
useless in any type of scheduling.

I would recommend using targeted rt-crontool commands to adjust
key items and not clutter the database with the incremental priority
changes. My two cents. I hope that this helps.

Cheers,
Ken




More information about the rt-users mailing list