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”.
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?
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.
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.
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.
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?
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 RT 5.0.0 Documentation - Best Practical. I’ve written Perl code before, but not usually object oriented code. So I could be way off. Your advice is greatly appreciated!
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 RT::Transaction - RT 5.0.0 Documentation - Best Practical. I feel like there is something fundamental I’m missing about how the OOP aspect of RT works.
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.
I’m finally getting back to this project, but I’m kind of stuck. Any help would be appreciated.
I figured I’d break this into smaller pieces and work on the most necessary part. So, first up, I tried to make the “Nudge” action not change the status to “open”. I went to scrip #1, which is called “On Correspond Open Tickets”. I added the following code to “Custom condition”. (Screenshot at bottom of this posting, too.)
my $Privs = $self->TransactionObj->CreatorObj->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 1; # In all other cases, the ticket's status should switch to "open".
}
Then I took a ticket with the status of “pending-customer” and used the Nudge command in the “Actions” menu. It changed the status from “pending-customer” to “open” and then gave the error message that I can’t change the status from “open” to “nudge”.
I’m including screenshots in case there is some detail I’m failing to mention.
I feel like I might be missing something obvious. For example, can I even use the “Custom condition” text area for the code when the “Condition” menu above it is set to “On Correspond”?
This is the quickest bit to answer: “no”. The three custom boxes are for when you’re defining new scrips that have user defined conditions (first box) or actions (second and third boxes). They don’t do anything if you’re using a pre-defined condition (“On Correspond” in this case) action (“Open Tickets”).
The error about not being able to change status from “open” to “nudge” indicates that either you don’t have a transition in your lifecycle between these two states, or accessing that transition requires rights this user doesn’t have.
Thanks, @GreenJimll. That is what I suspected. As far as the error message, that is because the lifecycle is intentionally set up to not allow “open” to go to “nudge”. “Nudge” is only supposed to be used if the ticket is already on “pending-customer”. The problem is that when I send correspondence (e.g. “Hey, I see it’s been a week. Did you see the previous message? Can I close this ticket?”) and set the ticket to “nudge”, it actually moves it to “open” first due to the pictured scrip named “On Correspond Open Tickets”. I want to avoid that. It should move to “nudge” at that point. I just can’t figure out how to do that.
If you look at the scrips being applied to the queue you should be able to shuffle the order (at least to some extent) . You should be able to move the nudge scrip before OCOT. Althought this may result in the status going pending-customer->nudge->open .
You can also try setting the scrip that opens the ticket as a batch scrip and have it check if any other scrips ran to set the status to “nudge” and if so it won’t do anything
The three custom boxes are for when you’re defining new scrips that have user defined conditions (first box) or actions (second and third boxes). They don’t do anything if you’re using a pre-defined condition (“On Correspond” in this case) action (“Open Tickets”).