Rt-crontool change priority silently?

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

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