Comment on Resolve, rather than Reply on Resolve?

RT Users
1

There may be a very simple answer to this but why is
the default action to “Comment” when the Resolve
option is chosen from the ticket header?

Surely it would be better if it were a REPLY?

The default action is to send a standard template
saying the ticket has been resolved but none of the
information entered in the resolution actions. I’ve
tried changing the RESOLVED template to include the
contents on the update but these appear not to carry
through.

Is there an easy way to change the default action on
Resolve from Comment to Reply?

Thanks in advance.

Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/

2

There may be a very simple answer to this but why is
the default action to “Comment” when the Resolve
option is chosen from the ticket header?

Surely it would be better if it were a REPLY?

The default action is to send a standard template
saying the ticket has been resolved but none of the
information entered in the resolution actions. I’ve
tried changing the RESOLVED template to include the
contents on the update but these appear not to carry
through.

That doesn’t work because the Comment and the Resolve
are 2 separate transactions in RT.

Is there an easy way to change the default action on
Resolve from Comment to Reply?

I think you will have to make a local copy of
html/Ticket/Elements/Tabs and change the resolve
link $actions->{‘B’} to “Action=Respond”

Thanks in advance.

No problem.

-Todd

3

brian mccabe wrote:

There may be a very simple answer to this but why is
the default action to “Comment” when the Resolve
option is chosen from the ticket header?

Surely it would be better if it were a REPLY?

Brian,

I’m just conjecturing here, but in my mind there’s two standard ways to deal with the idea of ticket resolution.

  1. Query: Ensure that the requestor is absolutely satisfied with your resolution (or acknowledges that you can’t do any further work on it) and close it when they respond.
  2. Notify: Tell the requestor that you are done with the ticket and close it in one fell swoop.

I believe that bestpractical subscribes to the first notion. That the requestor will send the final “It’s working now.” or “Thanks!” and that you then resolve the ticket with no further correspondence.
This avoids the problem of the second form where most likely you say “Your solution is XYZ - I’m resolving this ticket now” and the requestor comes back with “thank you” and the ticket re-opens.
The first is more verbose, however, and perhaps not in tune with standard system-administrator thinking “here ya go, have a nice life”. You can also end up with lots of tickets in wait-mode on user response.

It would be nice if there was some sort of global RT_SiteConfig.pm knob like “ResolvePolicy” that would make things behave according to the established site policy.

At our location, we modified the occurrences of “Comment” to be “Correspond”.

–stephen
Stephen Dowdy - Systems Administrator - NCAR/RAP
303.497.2869 - sdowdy@ucar.edu - http://www.rap.ucar.edu/~sdowdy/

4

I agree with the knob recommendation. A lot of my users complain that they get two emails when a ticket is resolved. I explain this is because there are two different scrips, and that sometimes you will want to set the status without making a comment/reply. (But of course, users don’t care why it doesn’t work like they want, they just want it fixed.) I had thought about tweaking the scrips to get the desired result, but I would have to replace the “on status change send reply” with two scrips, one that has an exception for if it is resolved, and replace the “on correspond” with two scrips. Or maybe just tweak the latter to accomodate for the former. Not sure, I hadn’t tried to map it out, but it’s not necessarily straightforward.-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of Stephen
Dowdy
Sent: Wednesday, December 14, 2005 10:37 AM
To: brian mccabe
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Comment on Resolve, rather than Reply on
Resolve?

I’m just conjecturing here, but in my mind there’s two standard ways to deal with the idea of ticket resolution.

  1. Query: Ensure that the requestor is absolutely satisfied with your resolution (or acknowledges that you can’t do any further work on it) and close it when they respond.
  2. Notify: Tell the requestor that you are done with the ticket and close it in one fell swoop.

I believe that bestpractical subscribes to the first notion. That the requestor will send the final “It’s working now.” or “Thanks!” and that you then resolve the ticket with no further correspondence.
This avoids the problem of the second form where most likely you say “Your solution is XYZ - I’m resolving this ticket now” and the requestor comes back with “thank you” and the ticket re-opens.
The first is more verbose, however, and perhaps not in tune with standard system-administrator thinking “here ya go, have a nice life”. You can also end up with lots of tickets in wait-mode on user response.

It would be nice if there was some sort of global RT_SiteConfig.pm knob like “ResolvePolicy” that would make things behave according to the established site policy.

5

Stephen,

I don't think a "global" policy or configuration on how to notify a

user about a resolution is something that would benefit RT. If RT did
that, I’d just have to make modifcations to undo it. Your site may not
always want the same policy you currently think should apply. Global
resolutions remove flexibility. That makes it more complicated when the
"global" policy needs a change. We allow each Queue administrator to set
the limits for their users via ROLES and GROUP rights, along with scrips
applied to individual queues. This allows for the company to be flexible
on how each Department/Queue/group handles their business. As the System
administrator, I don’t have the headache of all of that, I just give
advice to the Queue Admins on the options they have on handling a
problem. Hope this helps you.

Kenn

Stephen Dowdy wrote:

6

My users complained about receiving two emails once a ticket was
resolved as well (after editing resolve to default to reply)

Instead I’ve undone that change, and added this bit of code into the
resolved template.

{
my $resolution_comment;
my $Transactions = $Ticket->Transactions;

$Transactions->Limit( FIELD => ‘Type’, VALUE => ‘Comment’ );
$Transactions->OrderByCols (
{ FIELD => ‘Created’, ORDER => ‘DESC’ },
{ FIELD => ‘id’, ORDER => ‘DESC’ },
);

my $CommentObj = $Transactions->First;
if( $CommentObj && $CommentObj->id ) {
$resolution_comment = $CommentObj->Content;
}

$resolution_comment;
}

Which works out quite well. I do wonder though if someone were to not
comment when resolving if it would grab a comment previous to that.
Either way, I’d like to setup a requirement for a comment to resolve an
issue.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Schultz, Eric
Sent: Wednesday, December 14, 2005 11:47 AM
To: sdowdy@ucar.edu; brian mccabe
Cc: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Comment on Resolve, rather than Reply on
Resolve?

I agree with the knob recommendation. A lot of my users complain that
they get two emails when a ticket is resolved. I explain this is
because
there are two different scrips, and that sometimes you will want to
set
the status without making a comment/reply. (But of course, users
don’t
care why it doesn’t work like they want, they just want it fixed.) I
had
thought about tweaking the scrips to get the desired result, but I
would
have to replace the “on status change send reply” with two scrips, one
that has an exception for if it is resolved, and replace the “on
correspond” with two scrips. Or maybe just tweak the latter to
accomodate
for the former. Not sure, I hadn’t tried to map it out, but it’s not
necessarily straightforward.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of Stephen
Dowdy
Sent: Wednesday, December 14, 2005 10:37 AM
To: brian mccabe
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Comment on Resolve, rather than Reply on
Resolve?

I’m just conjecturing here, but in my mind there’s two standard ways
to
deal with the idea of ticket resolution.

  1. Query: Ensure that the requestor is absolutely satisfied with your
    resolution (or acknowledges that you can’t do any further work on it)
    and
    close it when they respond.
  2. Notify: Tell the requestor that you are done with the ticket and
    close
    it in one fell swoop.

I believe that bestpractical subscribes to the first notion. That the
requestor will send the final “It’s working now.” or “Thanks!” and
that
you then resolve the ticket with no further correspondence.
This avoids the problem of the second form where most likely you say
“Your
solution is XYZ - I’m resolving this ticket now” and the requestor
comes
back with “thank you” and the ticket re-opens.
The first is more verbose, however, and perhaps not in tune with
standard
system-administrator thinking “here ya go, have a nice life”. You can
also end up with lots of tickets in wait-mode on user response.

It would be nice if there was some sort of global RT_SiteConfig.pm
knob