Change ticket status after elapsed time period

I would like to configure RT to automatically change the status of a ticket
in certain cases. An example of this would be when a ticket is set to
"waiting on customer" response. After a certain period without a response
(ideally working days rather than calendar days) we would like to resolve
the ticket. I’ve been unable to find the right term to search on to find the
answer to this. Any help appreciated.

I would like to configure RT to automatically change the status of a ticket
in certain cases. An example of this would be when a ticket is set to
“waiting on customer” response. After a certain period without a response
(ideally working days rather than calendar days) we would like to resolve
the ticket. I’ve been unable to find the right term to search on to find
the
answer to this. Any help appreciated.

For such things you use rt-crontool. Start with search that uses TicketSQL,
for example “LastUpdated < ‘10 days ago’ AND Status = ‘waiting on
customer’”. Figure out how to use SetStatus action.

When above is ready then you can do two things:

  1. use bash or any other programming language to calculate time span and
    execute rt-crontool. What I mean is that if your script is executed on
    Monday and you want 5 days time span then your code generates ‘7 days ago’
    to compensate weekend.

  2. write RT’s custom condition that does additional date checks using
    pretty much the same logic as above solution.

Best regards, Ruslan.

I would like to configure RT to automatically change the status of a
ticket
in certain cases. An example of this would be when a ticket is set to
“waiting on customer” response. After a certain period without a response
(ideally working days rather than calendar days) we would like to resolve
the ticket. I’ve been unable to find the right term to search on to find
the
answer to this. Any help appreciated.

For such things you use rt-crontool. Start with search that uses
TicketSQL, for example “LastUpdated < ‘10 days ago’ AND Status = ‘waiting
on customer’”. Figure out how to use SetStatus action.

Ramon Kagan wrote a RT::Action::SetStatus module
http://lists.bestpractical.com/pipermail/rt-users/2005-February/028827.html

You can place it at /opt/rt3/local/lib/RT/Action/SetStatus.pm and use it.
You may have to run mkdir -p /opt/rt3/local/lib/RT/Action

YMMV.

When above is ready then you can do two things:

  1. use bash or any other programming language to calculate time span and
    execute rt-crontool. What I mean is that if your script is executed on
    Monday and you want 5 days time span then your code generates ‘7 days ago’
    to compensate weekend.

  2. write RT’s custom condition that does additional date checks using
    pretty much the same logic as above solution.


Best regards, Ruslan.

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Ramon Kagan wrote a RT::Action::SetStatus module
[rt-users] auto-close tickets after X amount of time

You can place it at /opt/rt3/local/lib/RT/Action/SetStatus.pm and use
it. You may have to run mkdir -p /opt/rt3/local/lib/RT/Action

Asif, RT has shipped with an RT::Action::SetStatus in core since 4.0.0.

Ramon Kagan wrote a RT::Action::SetStatus module

[rt-users] auto-close tickets after X amount of time

You can place it at /opt/rt3/local/lib/RT/Action/SetStatus.pm and use
it. You may have to run mkdir -p /opt/rt3/local/lib/RT/Action

Asif, RT has shipped with an RT::Action::SetStatus in core since 4.0.0.

Awesome! Waiting for my hardware to upgrade. Thanks for the info.


RT Training in Seattle, June 19-20: http://bestpractical.com/training

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?