[rt-devel] Duplicate response checking

Matt Lightner mlightner at site5.com
Thu Sep 19 00:31:53 EDT 2002


> 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




More information about the Rt-devel mailing list