[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