Html is request subjects breaking webrt.cgi, and a queestion

RT Users
1

Hiya. I’ve been dealing with the strangest problem I’ve ever seen, and so I
figured since I finally cracked it, I need to share the story with someone :wink:

So I’m migrating from ReqNG to RT . . . I install RT, put req2rt to work
feeding req tickets into RT, and go for coffee. Good thing too - took ages.
Actually, it never completed, halfway through the loading of resolved tickets
it finally exhausted my machine’s available memory. But that’s another story!

So I setup a new apache, virtually hosting support.tpc.int and cgi.tpc.int,
both setup to deal with VERY different tasks. For the first time, I also setup
the WWW interface to RT, webrt.cgi.

GREAT!

So I decide to try it out . . . the admin interface works fine, and for the
most part so too does the frames version of webrt.cgi. Only when I press the
button to “UPDATE QUEUE FILTERS” it sends me off to a shocking URL -
http://cgi.tpc.int/cgi-bin/tpcfax.pl. WHAT??? boggle

So I’m flummoxed. That script does exist on the other vhost, and I’d been
playing with it today, so I spent a lot of time looking for a mistaken edit,
or misconfig which might have included this URL in the RT stuff. I also spent
a long time learning how webrt.cgi works . . .all to no avail.

I ended up dumping the source of the page webrt was giving me, and initially
the construction of the form looked fine, and should have sent me to the webrt
script again, not tpcfax.pl.

SOLUTION? One of my tickets looks like this:

[root@hewes sniffit-0.3.7.beta]# rt -show 6403
Welcome to Request Tracker 1.0.2
Serial Number:6403
Queue:TPC.INT Support
Area:
Requestors:rayhan@pimail.com.pk
Owner:
Final Priority:50
Current Priority:50
Status:open
Created:Fri Dec 3 21:51:04 1999
Last User Contact:Sun May 7 15:10:57 2000
Last Contact:6 day
Due:Wed Dec 31 19:00:00 1969
Age:5 mth

That subject line is the culprit. It changed/redirected the entire action of
the form. DOH!!!

Finally, a question . . . as you can see our queue is very backlogged . . . as
a consequence there are about 7000 open tickets. Is there any way to tell the
web interface to only display the last 100 requests? Without such a feature
the entire WWW interface is ridiculously slow and resource-intensive.

Thanks for any info!

-Darren

2

Nothing. Hmmmm. Okay, I’ll let the "broken pages dues to html in subject"
slide. But the second issue I’d like to try once more on.

The web interface seems to only allow me to view the entire queue. The
resulting table is so big it hammers netscape. Essentially, the web interface
becomes useless.

Is it not possible to view only (for instance) the last 100 requests? Has
nobody implemented anything like this? I must be way behind the hardware curve
if you can use this on a large queue in anything approaching realtime.

-Darren

3

Nothing. Hmmmm. Okay, I’ll let the “broken pages dues to html in subject”
slide. But the second issue I’d like to try once more on.

The web interface seems to only allow me to view the entire queue. The
resulting table is so big it hammers netscape. Essentially, the web interface
becomes useless.

You can apply ohter filters.

Is it not possible to view only (for instance) the last 100 requests? Has
nobody implemented anything like this? I must be way behind the hardware curve
if you can use this on a large queue in anything approaching realtime.

Generally, at sites I’ve been at, if you have more than 100 open tickets in
a single queue and can’t filter on owner, it’s time to split the queue for
administrative reasons greater than “RT can’t deal”

A page-by-page viewer has been hacked together by various people at various times, though I’ve never used one. 2.0 will have something like this.

-Darren

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

4

Thanks for the reply Jesse!>>>>> On Tue, 16 May 2000, “Jesse” == Jesse wrote:

Jesse> On Tue, May 16, 2000 at 10:45:40PM +0100, Darren Nickerson wrote:

+> Nothing. Hmmmm. Okay, I’ll let the “broken pages dues to html in subject”
+> slide. But the second issue I’d like to try once more on.

+> The web interface seems to only allow me to view the entire queue. The
+> resulting table is so big it hammers netscape. Essentially, the web
+> interface becomes useless.

Jesse> You can apply ohter filters.

Ermph, you mean with the existing toolset? Status is open for all of these
requests, only one queue, for picking requests we are interested in ones which
are not owned, requestor = any. Still MASSIVE numbers.

+> Is it not possible to view only (for instance) the last 100 requests? Has
+> nobody implemented anything like this? I must be way behind the hardware
+> curve if you can use this on a large queue in anything approaching
+> realtime.

Jesse> Generally, at sites I’ve been at, if you have more than 100 open
Jesse> tickets in a single queue and can’t filter on owner, it’s time to
Jesse> split the queue for administrative reasons greater than “RT can’t
Jesse> deal”

This is for a massively overloaded support line for a free service. We do what
we can, when we can. Every once in awhile I’ll resolve a few hundred, as will
my colleagues.

Jesse> A page-by-page viewer has been hacked together by various people at
Jesse> various times, though I’ve never used one. 2.0 will have something
Jesse> like this.

Since rtq itself does not even have a -limit 100 type of option, this looks
like pretty hard work. Damn, wish I had thought this through a bit better, the
ReqNG WWW interface had this (IMHO essential) feature, and I just took it for
granted that so would webrt.cgi. My upgrade has completely crippled my support
line! :frowning:

-Darren

5

It’d actually not be too bad to add. SQL has a LIMIT To statement.

if you comb through the CVS archives versions tagged at ~ 1-1-1 or 1-1-2 should
have this functionality that you might be able to backport into 1.0.On Tue, May 16, 2000 at 11:13:01PM +0100, Darren Nickerson wrote:

Thanks for the reply Jesse!

On Tue, 16 May 2000, “Jesse” == Jesse wrote:

Jesse> On Tue, May 16, 2000 at 10:45:40PM +0100, Darren Nickerson wrote:

+> Nothing. Hmmmm. Okay, I’ll let the “broken pages dues to html in subject”
+> slide. But the second issue I’d like to try once more on.

+> The web interface seems to only allow me to view the entire queue. The
+> resulting table is so big it hammers netscape. Essentially, the web
+> interface becomes useless.

Jesse> You can apply ohter filters.

Ermph, you mean with the existing toolset? Status is open for all of these
requests, only one queue, for picking requests we are interested in ones which
are not owned, requestor = any. Still MASSIVE numbers.

+> Is it not possible to view only (for instance) the last 100 requests? Has
+> nobody implemented anything like this? I must be way behind the hardware
+> curve if you can use this on a large queue in anything approaching
+> realtime.

Jesse> Generally, at sites I’ve been at, if you have more than 100 open
Jesse> tickets in a single queue and can’t filter on owner, it’s time to
Jesse> split the queue for administrative reasons greater than “RT can’t
Jesse> deal”

This is for a massively overloaded support line for a free service. We do what
we can, when we can. Every once in awhile I’ll resolve a few hundred, as will
my colleagues.

Jesse> A page-by-page viewer has been hacked together by various people at
Jesse> various times, though I’ve never used one. 2.0 will have something
Jesse> like this.

Since rtq itself does not even have a -limit 100 type of option, this looks
like pretty hard work. Damn, wish I had thought this through a bit better, the
ReqNG WWW interface had this (IMHO essential) feature, and I just took it for
granted that so would webrt.cgi. My upgrade has completely crippled my support
line! :frowning:

-Darren

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Emacs is a pretty good operating system, but Unix has a better editor.