[rt-devel] You should really get the HTML out the code....

Fraser Gunn fhgunn at mfcf.math.uwaterloo.ca
Mon Feb 12 14:44:18 EST 2001


> From: "Brandon S. Allbery KF8NH" <allbery at ece.cmu.edu>
> To: Jesse <jesse at fsck.com>
> Cc: rt-devel at lists.fsck.com
> Subject: Re: [rt-devel] You should really get the HTML out the code....
> 
> On Saturday, February 10, 2001 16:04:54 -0500, Jesse <jesse at fsck.com> wrote:
> +-----
> | Ah. everywhere I've been, we've dealt with that at the policy layer.
> | The policy was: "Don't touch a ticket unless you're the owner or
> | have gotten approval from the owner."
> +--->8
> 
> Random people do not take tickets, nor are they supposed to.  Admins assign 
> them to people instead.
> 
> The problem is that not everyone can watch the queue all the time, so three 
> of us watch the queue as time permits.  This usually works out well --- 
> tickets get assigned on a timely basis, becaue it's unusual for Jim, Lou, 
> and myself to *all* be too busy to watch the queue.  But occasionally this 
> means two admins conflict.
> 
> The *real* problem is that sometimes one admin will kill a ticket (often, 
> in fact --- we do get a fair number of "noise" tickets from cron jobs 
> etc.).  This is permitted even if it's been assigned to someone else, which 
> just sucks if another admin sees something he doesn't like in the ticket 
> and takes or assigns it.
...

I looked at the problem of conflicting updates in RT.

You can't simply lock a ticket (or other record) when someone gets a form
to change something.  Because of the nature of an HTML interface, you have
no guarantee that they'll ever submit the update.  We allow ordinary users
to make some kinds of updates.  So user training is not the answer either.

What I do in my version of RT is save the current values in hidden form
variables.  When the update is finally submitted, I compare new values
to hidden to see what fields the user wants to change.  Then for each
of those fields I compare the hidden value to the current value in the
database.  If any of them differ, the update is refused with the message
"The value for '$_' has changed underneath you" and the form is refreshed
with the current values.

Unfortunately, I can't provide diffs -- our version of RT is too mutated!

-- fhgunn at math.uwaterloo.ca
Fraser Gunn, Math Faculty Computing Facility, University of Waterloo, Canada




More information about the Rt-devel mailing list