[rt-users] Comment on Resolve, rather than Reply on Resolve?

[Nathan Oyler]

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 at lists.bestpractical.com [mailto:rt-users-
> bounces at lists.bestpractical.com] On Behalf Of Schultz, Eric
> Sent: Wednesday, December 14, 2005 11:47 AM
> To: sdowdy at ucar.edu; brian mccabe
> Cc: rt-users at 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 at lists.bestpractical.com
> [mailto:rt-users-bounces at lists.bestpractical.com]On Behalf Of Stephen
> Dowdy
> Sent: Wednesday, December 14, 2005 10:37 AM
> To: brian mccabe
> Cc: rt-users at 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.
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Be sure to check out the RT Wiki at http://wiki.bestpractical.com
> 
> Download a free sample chapter of RT Essentials from O'Reilly Media at
> http://rtbook.bestpractical.com
> 
> WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
> San Francisco - Find out more at
> http://bestpractical.com/services/training.html