I think you could probably do it without adding a new status to the lifecycle if you didn’t want to add one, but I think the idea of having custom fields is worth pursuing. You might just be able to get away with just one scrip and, as @knation says, the use of rt-crontool to do the periodic checking for the need to send reminders and resolve tickets.
I’d suggest a “flag” custom field with states of “Awaiting Reply”, “Reminder Sent” and another “timeout” custom field that the owner can set to the number of days to wait. You then need one scrip (with “blank” output) that triggers on correspondence for tickets with owners that are open, have a non-zero timeout custom field and :
a) if the correspondence is an outgoing email from the owner, set the flag custom field to “Awaiting Reply” if it isn’t already set,
b) if the correspondence is an outgoing email and the flag is already set to “Awaiting Reply”, set the flag custom field to “Reminder Sent”,
c) if the correspondence is an incoming email (from the requestor if you wish) then clear the flag custom field.
You’ll then need to use two rt-crontool commands:
-
search for open tickets with the flag set to “Reminder Sent” and the last update time earlier than “timeout” days ago. Set the matched tickets’ statuses to resolved.
-
search for open tickets with the flag set to “Awaiting Reply” and the last update over “timeout” days ago. For matched tickets send a templated reminder email from the owner (which will trigger b) above to reset the flag custom field)
One thing I can see that might scupper this would be if the owner or other people interacted with the ticket whilst waiting for a reply, as that would change the last updated time on the ticket. If that’s the case you might want to use the “timeout” CF value to set a third custom field with an actual date for the rt-crontool to use as @knation suggested. You can reset this in the scrip in condition b) by adding the “timeout” value to the current date/time.
