Thank you for your product.
A+ for Effort, but You should really get the HTML out the code… put the HTML in templates like you did with the mail templates.
Also, you should really keep track of which “admin user” is displaying which “request”, and notify any other admin users that "such and such admin’ is currently accessing the request record. (timestamp upon select, release timestamp when admin moves on to another transaction.)
Keith
Thank you for your product.
A+ for Effort, but You should really get the HTML out the code… put the HTML in templates like you did with the mail templates.
Keith. I suspect you were looking at the 1.0 version of RT which, at it’s core
is about 6 years old at this point.
The webui for RT 2.0, which we’re hard at work on right now, is based around
the HTML::Mason templating engine and should allow much easier customization.
Also, you should really keep track of which “admin user” is displaying which “request”, and notify any other admin users that "such and such admin’ is currently accessing the request record. (timestamp upon select, release timestamp when admin moves on to another transaction.)
In my travels, I’ve not really run into situations where this would have
been useful. Can you give me some examples of how this feature can help
a team get stuff done?
Thanks,
Jesse
Keith
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
I think co-ordinating 1000 prima donnas living all over the world will be as
easy as herding cats…" – Andy Tanenbaum on the linux development model, 1992
| A+ for Effort, but You should really get the HTML out the code… put
| the HTML in templates like you did with the mail templates.
±–>8
See the RT2 development stuff.
| Also, you should really keep track of which “admin user” is displaying
| which “request”, and notify any other admin users that "such and such
| admin’ is currently accessing the request record. (timestamp upon select,
| release timestamp when admin moves on to another transaction.)
±–>8
I’ve run into that one myself, but I don’t see any good way to deal —
timestamps aren’t sufficient, true persistent database locks are needed.
RT2 may make this possible, it’s a lost cause with RT1.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
| | Also, you should really keep track of which “admin user” is displaying
| | which “request”, and notify any other admin users that "such and such
| | admin’ is currently accessing the request record. (timestamp upon
| | select, release timestamp when admin moves on to another transaction.)
|
| I’ve run into that one myself, but I don’t see any good way to deal —
| timestamps aren’t sufficient, true persistent database locks are needed.
| RT2 may make this possible, it’s a lost cause with RT1.
±–>8
Expanding on this for Jesse’s benefit: we usually have several admins
monitoring the queue. The problem is that multiple admins can decide to
take an action on a new request; this can be frustrating if the admins
didn’t decide on the same action.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
Expanding on this for Jesse’s benefit: we usually have several admins
monitoring the queue. The problem is that multiple admins can decide to
take an action on a new request; this can be frustrating if the admins
didn’t decide on the same action.
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.”
The first thing a tech would do when touching a ticket was to click
‘take’. Either the take would succeed and the tech would be the ticket’s
owner OR the take would fail because someone had already taken the ticket.
-j
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
Emacs is a pretty good operating system, but Unix has a better editor.
| 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.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
±----
| 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
Right, but with proper database transactions, you have a wider choice at
the policy layer, like the example below.
IIRC MySQL has some sort of transactions, if you use Sleepycat DB tables.
It might even be ACIDic.
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.–
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
meow
_ivan
From: “Brandon S. Allbery KF8NH” allbery@ece.cmu.edu
To: Jesse jesse@fsck.com
Cc: rt-devel@lists.fsck.com
Subject: Re: [rt-devel] You should really get the HTML out the code…
±----
| 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.”
±–>8Random 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@math.uwaterloo.ca
Fraser Gunn, Math Faculty Computing Facility, University of Waterloo, Canada
Also, you should really keep track of which “admin user” is displaying
which “request”, and notify any other admin users that "such and such admin’
is currently accessing the request record. (timestamp upon select, release
timestamp when admin moves on to another transaction.)In my travels, I’ve not really run into situations where this would have
been useful. Can you give me some examples of how this feature can help
a team get stuff done?Thanks, Jesse
What I am suggesting is basic database ACID compliance. Admittedly, it is
not very easy to achieve in a 3 tier web environment where connections are
stateless, BUT never-the-less I think your application MUST incorporate it
to be taken seriously. Checking a row’s timestamp, and updating it
appropriately as each web page is fetched/updated is a common way to take a
“step towards” ACID …
It is very important to achieve ACID in an application such as yours,
because you will have a "queue’ that can potentially be accessed at the same
time by multiple people - you must co-ordinate access to updates of the
queue.
Also I think you are not handling “multiple duplicate” requests, where the
user quickly clicks form same button multiple times -you should not execute
the action on the server multiple times…
I might suggest abandoning CGI and go with JSP and the J2EE platform… I
think much of this could be taken care of in the J2EE environment (JSP HTML
templates, applications sessions, EJB transactions)… CGI is old news…
“Go Java, Young Man”…
just my two cents… However, I do appreciate the work you have put into
your application…it shows a great deal of effort… I certainly have not
found another open source project that does what you do -and I really need
to look at your version 2…BUT actually there is a SUN J2EE specification
for an API that is being worked on for “ticket systems”… this would
standardize and open source “ticket tracking” api for flexible
configuration…
Hip, Hip,
Keith Kwiatek
| I might suggest abandoning CGI and go with JSP and the J2EE platform…
±–>8
That isn’t necessary, actually; Apache::Session and HTML::Mason give RT2
everything it needs to do this, from what I’ve seen.
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]
I have used both of the modules, -and a good servlet and JSP engine is a far
better “general” solution… your application will be of much more value,
and be far easier for the open source community to use -IF you go with
J2EE…
I say again… "go java, young man"From: “Brandon S. Allbery KF8NH” allbery@ece.cmu.edu
To: “Keith Kwiatek” kkwiatek@nist.gov; “Jesse” jesse@fsck.com
Cc: rt-devel@lists.fsck.com
Sent: Saturday, February 17, 2001 8:19 PM
Subject: Re: [rt-devel] You should really get the HTML out the code…
±----
| I might suggest abandoning CGI and go with JSP and the J2EE
platform…
±–>8That isn’t necessary, actually; Apache::Session and HTML::Mason give RT2
everything it needs to do this, from what I’ve seen.–
brandon s. allbery [os/2][linux][solaris][japh]
allbery@kf8nh.apk.net
system administrator [WAY too many hats]
allbery@ece.cmu.edu
electrical and computer engineering
KF8NH
carnegie mellon university [“better check the oblivious
first” -ke6sls]
At this point in its lifecycle, java doesn’t have nearly the write-once
run-everywhere portability that perl does. And the likelyhood of your average
RT user to know enough perl to customize it for their local site is much
higher than the likelyhood of a local administrator to know enough java to
do the same. At this point in its lifecycle, perl really makes the most
sense as RT’s implementation language. As java matures and stabilizes
(and the freely available language implementations do the same) it’s certainly
something I’m going to revisit.
Oh. I couldn’t find a pointer to the Java Trouble Ticketing API you mentioned.
if you have a url, I’d appreciate it. Thanks,
-jOn Wed, Feb 21, 2001 at 07:45:17AM -0800, Keith Kwiatek wrote:
I have used both of the modules, -and a good servlet and JSP engine is a far
better “general” solution… your application will be of much more value,
and be far easier for the open source community to use -IF you go with
J2EE…I say again… “go java, young man”
----- Original Message -----
From: “Brandon S. Allbery KF8NH” allbery@ece.cmu.edu
To: “Keith Kwiatek” kkwiatek@nist.gov; “Jesse” jesse@fsck.com
Cc: rt-devel@lists.fsck.com
Sent: Saturday, February 17, 2001 8:19 PM
Subject: Re: [rt-devel] You should really get the HTML out the code…On Monday, February 12, 2001 08:44:50 -0800, Keith Kwiatek kkwiatek@nist.gov wrote:
±----
| I might suggest abandoning CGI and go with JSP and the J2EE
platform…
±–>8That isn’t necessary, actually; Apache::Session and HTML::Mason give RT2
everything it needs to do this, from what I’ve seen.–
brandon s. allbery [os/2][linux][solaris][japh]
allbery@kf8nh.apk.net
system administrator [WAY too many hats]
allbery@ece.cmu.edu
electrical and computer engineering
KF8NH
carnegie mellon university [“better check the oblivious
first” -ke6sls]
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
. . . when not in doubt, get in doubt. – Old Discordian Proveb
Okok… enough with ACID. If we really wanted ACID, there wouldn’t be MySQL
support out there. 
That, and, honestly, if the direction of development turned towards Java, I can
honestly say that a fair amount of people (myself included) would not follow.
Handling the issue of having multiple people have access to the same contents,
and potentially have actions overlap, is entirely an implementation issue.
Sure, you have policy here and preventitive code there, but it really boils
down to the basic priority: You want to have the end customer’s issue
addressed.
If you have situations where a ticket is locked while another admin is working
on it, you introduce the new problem of having to deal with situations were the
ticket needs to be forcefully unlocked: Admin left for the day, but left the
ticket in a “view” state, app crashed (can we smell the Java in this one?) and
left the ticket in a locked state, etc.
HTML/CGI is fantastic for limiting the impact on the administrative clients (it
doesn’t take a hefty CPU to use RT) as well as the server (Apache + RT =
lightweight).
The problems that were immediately pointed out are all in the back-end… in
most setups, the end customer does not see them, and there are better ways of
dealing with the issues than falling for the “Java can do everything” line…
A Java implementation might work well in an environment where everything is
on a nice fast LAN, all of the administrative clients & customer machines (if
they connect into RT) are of the same platform, everything is beefy, and you
don’t want to customize it. Java is still so touchy that it scares the crap
out of most people… who wants their browser to hang?
Another thing to remember is that RT is a bit more than a “ticketing system”.
It’s a helpdesk system…
-Rich
PS: The whole “java” push is one that just drives me nuts. Java has yet to
live up to what has been promised. It’s far from lightweight (take 4 lines of
java, and you’ve got to load the entire interperter/compiler on the client,
within the browser, and pray to whomever that the browser doesn’t crap out on
you).
PPS: Way back at an old company I was working at, we developed an in-house
java-based helpdesk system which would do the ticket locking and hierachial
(sp?) views of the tickets, and more. It took us (4 SA’s) over a year to
write, with the help of some of the company developers. The end result was
something extremely customized to our environment and, although it worked well,
it wasn’t fun running it from home over a 128k ISDN line. The benefits of Java
certainly don’t outwiegh the expense of the implementation (client side
limitations, poor JITs, and fragile code, etc.)