Can't use new status when replying to tickets

RT Users
#1

I created a new lifecycle for tickets. It is the same as the default, but includes “pending-customer” and “nudge”. This is what it looks like:

Screen Shot 2021-02-16 at 8.59.52 AM
Screen Shot 2021-02-16 at 8.59.52 AM1222×484 33.3 KB

When I click on the pencil icon in the Basics block, I can assign any of the status as desired. (Within limitations of the lifecycle, e.g. I can’t move from “new” to “nudge”.) When I use the “Nudge” action I created in the lifecycle (see below), RT gives an error that I can’t set the ticket to the status “nudge”.

Screen Shot 2021-02-16 at 9.42.36 AM
Screen Shot 2021-02-16 at 9.42.36 AM945×52 6.55 KB

I believe this is because my scrips are telling the ticket to move to status “open” on correspondence and I can’t move from “open” to “nudge”. This is an intentional limit so that my technicians don’t accidentally forget that “nudge” is for people who already received a question over email.

Any advice on how to handle this?

In an ideal world, I would have the move from “pending-customer” to “nudge” be completely handled via cron jobs that send a form letter to the end users and include the previous correspondence in that form letter. For example, “Hi, I’m a robot helping the I.T. department. I see that they emailed you the following question recently. If you could please reply with an answer, I’ll let them know and they can help you out. Thanks! \n ----- \n $previous_correspondence”. Would such a thing be possible? Would it prevent the issue above? Or should I handle this in the GUI first and worry about automation later, if ever?

#2

You can disable the script that is doing on correspondence set status open. Or set a precondition so that it only runs if the $self->TransactionObj->Creator is not Privileged.

In fact, you can have your technicians replying automatically move the ticket to pending, even if it’s not an allowed transition (a scrip could cheat here).

In an ideal world, I would have the move from “pending-customer” to “nudge” be completely handled via cron jobs that send a form letter (…) Would such a thing be possible?

Yes. It would be possible. We currently do something similar.

You basically want in your cron

/usr/bin/rt-crontool-4 \
    --search RT::Search::FromSQL \
    --search-arg "$CRONTOOL_CONDITION" \
    --action RT::Action::RecordCorrespondence \
    --template "$TEMPLATE_NAME"

If you wanted to change the status as well, you can add --action RT::Action::SetStatus --action-arg $NEWSTATUS

We use a custom RT::Condition to count the number of reminders already sent (there is a point after which we don’t want to continue sending reminder emails).

Do note that if you changed the Requestors of the ticket, you could end up “reminding” someone of a correspondence with someone else (which may be unintended). We are using a generic template rather than including the original / previous message, which is safer in that sense but result in a worse experience for the receiver.

#3

Thanks. I think I follow what you’re saying and just need to test run it. I have a few questions, if you are willing.

Do you put the $self->TransactionObj->Creator test into “Custom condition:” when editing the scrip? For me, it is scrip #1, so it is an old script that goes all the way back to when I installed RT 1.0.x. I don’t think that is an issue, but I just wanted to mention it just in case.

Screen Shot 2021-02-16 at 1.14.20 PM
Screen Shot 2021-02-16 at 1.14.20 PM1154×732 41.5 KB

Can you perform both an --action RT::Action:RecordCorrespondence and --action RT::Action:SetStatus on the same rt-crontool command?

Why did you have rt-crontool-4 instead of rt-crontool? I only have rt-crontool installed.

#4

Based on your advise, I think I want to add the conditions “Not ( (TicketUpdater = PrivilegedUser) and (TicketStatus = pending-customer) )” to the scrip.

That was in pseudo-code, obviously. I don’t know how to learn the proper syntax. Can you point me in the right direction?

#5

Or set a precondition so that it only runs if the $self->TransactionObj->Creator is not Privileged.

Does the code for that look something like this?

my $Creator = $self->TransactionObj->Creator;  # ID# of user.
my $Privs = $Creator->User->Privileged;  # True if user is granted privileges, i.e. can login to web GUI.
my $Status = $self->TicketObj->Status;  # Status of ticket.
if ( ($Status eq 'pending-customer') && ($Privs) ) {
  return 0; # If the status is "pending-customer" and the person writing the reply is a tech, don't change the status to "open".
} else {
  return 0; # In all other cases, the ticket's status should switch to "open".
}

I’ll be honest; I’m guessing based on some examples I’ve seen in other posts and some of the documentation at https://docs.bestpractical.com/rt/5.0.0/. I’ve written Perl code before, but not usually object oriented code. So I could be way off. Your advice is greatly appreciated!

#6

Does the code for that look something like this?

The only bit that looks wrong to me is how you’re loading the creator user:

my $Creator = $self->TransactionObj->Creator;  # ID# of user.
my $Privs = $Creator->User->Privileged;

Since $Creator is the ID of the user, you can’t call a method like “->User->Privileged”. Instead you can do:

my $Privs = $self->TransactionObj->CreatorObj->Privileged;
#7

Thanks. In hindsight, that makes sense, since it is an integer and not an object. Now I’m confused, though, because I don’t see “CreatorObj” in https://docs.bestpractical.com/rt/5.0.0/RT/Transaction.html. I feel like there is something fundamental I’m missing about how the OOP aspect of RT works.

#8

That method is inherited from RT::Record:

https://docs.bestpractical.com/rt/5.0.0/RT/Record.html#CreatorObj

#9

Why did you have rt-crontool-4 instead of rt-crontool? I only have rt-crontool installed.

This was provided by debian packaging. They install it as /usr/bin/rt-crontool-4 and then setup /usr/bin/rt-crontool as a symlink to that via alternatives. Just use rt-crontool.

Can you perform both an --action RT::Action:RecordCorrespondence and --action RT::Action:SetStatus on the same rt-crontool command?

Yes.

Do you put the $self->TransactionObj->Creator test into “Custom condition:” when editing the scrip?

Note rt-crontool isn’t a scrip. It’s placed in the cron. But you may be able to do this with a scrip as well.