Web UI - limit tickets/page ability?


#1

Folks,

Since moving from ReqNG to RT some time ago now, our support queue has been
effectively paralysed by the fact that RT’s WWW UI shows the complete list of
ALL open trouble tickets. Our queue is a large one, and the thousand+ entries
cause Nutscrape and Internet Destroyer to REALLY chug when trying to render the
table.

I note, with joy, that 1.3.x (soon to be 2.x) has the ability to limit results/
page. I note, with chagrin, the number of issues in that alpha-quality code.

Do I presently have any viable option here? I just slurped the CVS - is it
functional enough to manage a fairly simple queue, or is it still scary
monster time? If it’s not an option, does anyone have a hack I can wedge into
the current stable release?

Thanks in advance.

-Darren


#2

Folks,

Since moving from ReqNG to RT some time ago now, our support queue has been
effectively paralysed by the fact that RT’s WWW UI shows the complete list of
ALL open trouble tickets. Our queue is a large one, and the thousand+ entries
cause Nutscrape and Internet Destroyer to REALLY chug when trying to render the
table.

I note, with joy, that 1.3.x (soon to be 2.x) has the ability to limit results/
page. I note, with chagrin, the number of issues in that alpha-quality code.

Do I presently have any viable option here? I just slurped the CVS - is it
functional enough to manage a fairly simple queue, or is it still scary
monster time? If it’s not an option, does anyone have a hack I can wedge into
the current stable release?

Thanks in advance.

-Darren


#3

What I do is create the view I want, with the options at the bottom of the
full list. Once that list is created, book mark the resulting page.

At 01:05 AM 2/5/2001 -0500, Darren Nickerson wrote:

Since moving from ReqNG to RT some time ago now, our support queue has been
effectively paralysed by the fact that RT’s WWW UI shows the complete list of
ALL open trouble tickets. Our queue is a large one, and the thousand+ entries
cause Nutscrape and Internet Destroyer to REALLY chug when trying to
render the
table.

I note, with joy, that 1.3.x (soon to be 2.x) has the ability to limit
results/
page. I note, with chagrin, the number of issues in that alpha-quality code.

Do I presently have any viable option here? I just slurped the CVS - is it
functional enough to manage a fairly simple queue, or is it still scary
monster time? If it’s not an option, does anyone have a hack I can wedge into
the current stable release?

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685


#4

Russ> What I do is create the view I want, with the options at the bottom of
Russ> the full list. Once that list is created, book mark the resulting page.

Sorry, I don’t understand . . . why would bookmarking that html page (which in
our case is nearly 2MB of html) help anything?

Sorry if I’m being dense :wink:

-d


#5

We have a similar problem, but its not with open tickets (thank goodness),
its with resolved tickets.

Many times we need to pull up history of specific requests, but we don’t
know the request number. Selecting status of resolved gives us everything
that has ever been resolved in that queue.

What we really need is a date range option (display all {status} requests
within the following {created|last action} date range).

Another useful feature would be the ability to search the text of the
transactions as we tend to remember part of the text of the transaction more
than we remember the subject or e-mail address…

I haven’t checked the contrib section lately and perhaps something like
either of these two features is there. If not, has anyone made similar
mods?

Your idea about paging would be nice, but for us, the ability to narrow the
number of requests by date and/or transaction text would be wonderful.

-Bill


#6

| Russ> What I do is create the view I want, with the options at the
| bottom of Russ> the full list. Once that list is created, book mark
| the resulting page.
|
| Sorry, I don’t understand . . . why would bookmarking that html page
| (which in our case is nearly 2MB of html) help anything?
±–>8

The bookmark isn’t placed on the selected items, but instead on the query
options.

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]


#7

Folks,

Since moving from ReqNG to RT some time ago now, our support queue has been
effectively paralysed by the fact that RT’s WWW UI shows the complete list of
ALL open trouble tickets. Our queue is a large one, and the thousand+ entries
cause Nutscrape and Internet Destroyer to REALLY chug when trying to render the
table.

I note, with joy, that 1.3.x (soon to be 2.x) has the ability to limit results/
page. I note, with chagrin, the number of issues in that alpha-quality code.

Do I presently have any viable option here? I just slurped the CVS - is it
functional enough to manage a fairly simple queue, or is it still scary
monster time? If it’s not an option, does anyone have a hack I can wedge into
the current stable release?

I’ve finaly found it…it was sent by Rich West on 25 May 1999 to
rt-users… working pretty well with 0.99.8pre4, but there were no
problems getting into the current 1.0.7 stable version.
I just make some modifications to correct work of his links (Next xx,
Previos xx) to preserve actual setting of sort criteria…
Both are in attachments.

Thanks in advance.

-Darren


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

Jan Okrouhly
-----------------------------------------±----okrouhly@civ.zcu.cz—
Laboratory for Computer Science | phone: (420 19) 7491588
University of West Bohemia | location: Univerzitni 22
Americka 42, 306 14 Pilsen, Czech Republic | room: UI404
------------------------------------------73!-de-OK1INC@OK0PPL.#BOH.CZE.EU-

limits_and_area.patch (5.96 KB)

patch (8.55 KB)


#8

Hello

Hi,

I’ve finaly found it…it was sent by Rich West on 25 May 1999 to
rt-users… working pretty well with 0.99.8pre4, but there were no
problems getting into the current 1.0.7 stable version.
I just make some modifications to correct work of his links (Next xx,
Previos xx) to preserve actual setting of sort criteria…
Both are in attachments.

so, both patches are needed, in order to have this feature? so
your ones depend on the other patch?

Needed is just the one mine. I’ve added the old message just if somebody
would to see it.

BUT, there are some little problems - when you limit a view containing
merged tickets then you (of course?) don’t see them. I’ll look better on
it later and send all as a new complete patch for 1.0.7 (unified).
Be patient, I’m too busy now with other higher priority problems.

so long
othmar

Greets

Jan Okrouhly
-----------------------------------------±----okrouhly@civ.zcu.cz—
Laboratory for Computer Science | phone: (420 19) 7491588
University of West Bohemia | location: Univerzitni 22
Americka 42, 306 14 Pilsen, Czech Republic | room: UI404
------------------------------------------73!-de-OK1INC@OK0PPL.#BOH.CZE.EU-


#9

BTW, thanks for sending that back out again. I had lost that patch (along
with a number of others) that I made to RT at other employers somewhere along
the line.

-Rich


#10

I’ve currently finished up functionality cleaning of the old Rich’s patch

  • added two minor and one major bug corrections of rt-1.0.7 - all is
    prepared together for Jesse as a (patchable output of) unified diff which
    I hope make an rt-1.0.8pre1 from the rt-1.0.7…

Description of changes:
lib/rt/database.pm

  • major bug - merged tickets history is actually visible…
  • ‘Display Queue’ query corrected to work well with Rich’s LIMIT
    (it may not work well due the output was post-filtered [by perl code])
    lib/rt/ui/cli/query.pm
  • minor bug - rtq help describing ‘orderby’ function was mistyped
    lib/rt/ui/web/forms.pm
  • fixed Rich’s handling with ‘q_limit’ and ‘q_range’ to allow right
    functions of sorting buttons
  • changed bahavior of ‘Display Queue’ to allow to the ‘RT Admin’ user
    selection of all queues
  • fixed Rich’s handling of ‘Area’ to allow selection of all Areas
    accessible to given user from actually displayed queues
  • added Rich’s q_limits
    lib/rt/ui/web/manipulate.pm
  • changed Rich’s area testing to strict and fixed “None” option
  • added rest of Rich’s area a q_limis core implementation
    lib/rt/ui/web/support.pm
  • minor bug fix - when using external auth and no parse header CGI,
    there was missing print “HTTP/1.0 200 Ok\n”; code…

That should be all. Enjoy!On Fri, 2 Mar 2001, Othmar Pasteka wrote:

hi,

On Thu, Mar 01, 2001 at 03:47:44PM +0000, Jan Okrouhly wrote:

I’ve finaly found it…it was sent by Rich West on 25 May 1999 to
rt-users… working pretty well with 0.99.8pre4, but there were no
problems getting into the current 1.0.7 stable version.
I just make some modifications to correct work of his links (Next xx,
Previos xx) to preserve actual setting of sort criteria…
Both are in attachments.

cool, is it possible that oyu send me a unified diff? would be
great.

so long
Othmar

Greets

Jan Okrouhly
-----------------------------------------±----okrouhly@civ.zcu.cz—
Laboratory for Computer Science | phone: (420 19) 7491588
University of West Bohemia | location: Univerzitni 22
Americka 42, 306 14 Pilsen, Czech Republic | room: UI404
------------------------------------------73!-de-OK1INC@OK0PPL.#BOH.CZE.EU-

rt-1.0.8pre1.patch (10.5 KB)