Duplicate response checking

RT Developers
1

Hey all,

We’ve been using RT for quite a while, and I have noticed that on occasion, we will have two employees respond to the same ticket/question–which can obviously confuse the client.

I am considering adding some kind of protection for this in /Ticket/Update.html. Perhaps adding a unix timestamp as a hidden field in Update.html when the page is loaded, and then when that page is submitted, the responses for that ticket can be checked to see if there have been any submitted after that timestamp (I.E. after the Update.html page was loaded). If so, it would redisplay the response edit page to the user with a warning at the top (but no timestamp hidden in for form this time), so they can decide whether or not they actually want to force submission of the response.

Does this sound like something that would be useful to anyone else? I hate to have to patch the source every time I upgrade, and if it sounds like something others would use, would love to see it included in the program by default.

Let me know,
Matt

2

[formatting fixed]

Matt Lightner wrote:

We’ve been using RT for quite a while, and I have noticed that
on occasion, we will have two employees respond to the same
ticket/question–which can obviously confuse the client.

Another approach (which we considered but decided against for
other reasons) might be to only grant the ReplyToTicket right
to the Owner (and CCs and Requestors) so that the ticket must
be taken before replying.
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

3

[formatting fixed]

Matt Lightner wrote:

We’ve been using RT for quite a while, and I have noticed that
on occasion, we will have two employees respond to the same
ticket/question–which can obviously confuse the client.

Another approach (which we considered but decided against for
other reasons) might be to only grant the ReplyToTicket right
to the Owner (and CCs and Requestors) so that the ticket must
be taken before replying.

Trouble is, there’s nothing to stop somebody stealing the ticket and
replying before you’ve finished :slight_smile:

Unless stealing should also not be allowed, but I think that it is
needed.

Robie.

4

Trouble is, there’s nothing to stop somebody stealing the ticket and
replying before you’ve finished :slight_smile:

Unless stealing should also not be allowed, but I think that it is
needed.

The way we do it is a person doesn’t take a ticket unless it’s specifically
for them. All other tickets are left with no owner, and the on-duty
admin/tech will just respond to them. So this issue tends to come up a bit
for us.

I just finished a pretty basic modification to prevent this from happening.
I’m not sure how graceful it is, but it seems to get the job done. A more
practical patch would redisplay the Update.html page with the
newly-submitted response and allow the user to re-submit their response if
they were sure they wanted to reply again. Oh well… maybe something for
2.1 :slight_smile:

A simple patch against the 2.0.13 source is below. I included 5 lines of
context so that people with newer versions can apply the patch easily.

Best Regards,
Matt Lightner
Vice President, Technical Operations
Site5 Internet Solutions, Inc.
mlightner@site5.com

diff -bBdNrw -U5 rt-2-0-13/webrt/Ticket/Display.html
rtmod/webrt/Ticket/Display.html
— rt-2-0-13/webrt/Ticket/Display.html Tue Nov 6 18:07:07 2001
+++ rtmod/webrt/Ticket/Display.html Wed Sep 18 04:26:22 2002
@@ -127,10 +127,17 @@
my $action = $1;
my ($res, $msg)=$Ticket->$action();
push(@Actions, $msg);
}
}
+if (defined $ARGS{pageload}) {

  •    if ($ARGS{pageload} <= $Ticket->ToldObj->Unix) {

  •        Abort("This ticket has been updated since you loaded the

response page.");

  •    }

+}
$ARGS{‘UpdateContent’} =~ s/\r\n/\n/g;
chomp ($ARGS{‘UpdateContent’}) ;

 if ($ARGS{'UpdateContent'} &&
     $ARGS{'UpdateContent'} ne '' &&

diff -bBdNrw -U5 rt-2-0-13/webrt/Ticket/Update.html
rtmod/webrt/Ticket/Update.html
— rt-2-0-13/webrt/Ticket/Update.html Wed Feb 20 20:45:38 2002
+++ rtmod/webrt/Ticket/Update.html Wed Sep 18 04:22:42 2002
@@ -54,10 +54,11 @@
of email addresses. Does not change who will receive future
updates.)

Attach: <& /Elements/MessageBox, Name=>"UpdateContent", QuoteTransaction=>$ARGS{QuoteTransaction} &> +
5

For a possibly more elegant solution: How about adding a flag to mark the
ticket as ‘being edited’, a field to show who is editing it, and a timer
to ensure that the ‘being edited’ bit is unset if the responder takes too
long. [For example, they get a long support call, or walk off to lunch.]

Its not perfect, but at least it would be implemented in the API rather
then the web app. If you only implement solutions in the webapp you
leave yourself open to abuse from the command line tools, and any tools
that are integrated with RT though the api.

-Matt

6

Robie Basak wrote:

Another approach (which we considered but decided against for
other reasons) might be to only grant the ReplyToTicket right
to the Owner (and CCs and Requestors) so that the ticket must
be taken before replying.

Trouble is, there’s nothing to stop somebody stealing the ticket and
replying before you’ve finished :slight_smile:

No problem. Stealing requires a conscious attempt by the thief.
The intent here is to prevent accidental duplicates. If you go
to reply and find you need to steal the ticket first, you’ll know
someone else has taken the ticket and may be replying now. :slight_smile:
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

7

Matt Lightner wrote:

I just finished a pretty basic modification to prevent this from happening.
I’m not sure how graceful it is, but it seems to get the job done. A more

mmm, I kinda like this…
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

8

Matt Lightner wrote:

I just finished a pretty basic modification to prevent this from
happening.
I’m not sure how graceful it is, but it seems to get the job done. A
more

mmm, I kinda like this…

Hey thanks. When I finished it, I realized that there is somewhat of a
problem with the way it’s done. I think that the “pageload” timestamp
should actually be from the time that Display.html was originally
loaded–not Update.html. Someone could have Display.html open for an hour
while they are working on an issue, and someone else could respond to the
ticket before Update.html is loaded, but after Display.html is loaded, and
they wouldn’t know about the new response unless they saw the response come
in via email, or they reloaded Display.html and checked for new responses
before loading Update.html.

Of course, sometimes they may already be aware that someone else responded
and not want to have to refresh the Display.html page before clicking on
“reply”. Maybe a “Protected reply” link could be added to the link bar that
would pass the pageload variable (via GET) to Update.html, and then the
regular “Reply” link wouldn’t pass the pageload time, and therefore wouldn’t
have the duplicate response protection enabled.

Obviously there’s still the issue of duplicate email responses, which is
going to be difficult to protect against because there’s no way to tell who
is reading or responding to a ticket on their own system. About the only
thing I can see working there is adding an option to not allow two responses
to the same ticket from adminCCs within a certain time period if the
customer didn’t respond in-between them. But obviously that’s not perfect
and could be a hassle for some people.

Anyway, just a thought. What I already wrote seems to work fine for basic
protection, but it would be nice to see something more practical in a future
release if it seemed warranted to more than just a couple people.

Matt