Unordered Ticket histories and Add/Delete Watchers

Jesse,

I found that ticket histories are not ordered properly according to the date
and time. I am using ver. 1.3.94.

Also, DeleteWatchers() didn’t work for me as I wanted to be able to let the
user change the requestors during update/reply.

I am using 1.3.94 for testing and will be upgrading the production machine to
the new version. The problem is we are expecting at least 5000 requests per
day. If we selected to show 25 or 100 tickets per page, we will have to
press “next” lots of times. Do you have any suggestions in what platform,
system configs, etc that will greatly improve and speed up the load time?

Nobel

Jesse,

I found that ticket histories are not ordered properly according to the date
and time. I am using ver. 1.3.94.

Is this from newly created tickets and transactions? Or are they imported?
If so, what was the original source of those transactions?

Also, DeleteWatchers() didn’t work for me as I wanted to be able to let the
user change the requestors during update/reply.

In what way did the DeleteWatchers() function call not work for you?

The problem is we are expecting at least 5000 requests per
day. If we selected to show 25 or 100 tickets per page, we will have to
press “next” lots of times.

Um. I suspect that what you’re going to want for a load like that is
some custom designed UI to make displaying large numbers of tickets
feasable and and some custom scrips to auto-assign tickets, etc. If this is
for an abuse desk scenario, you might want scrips which automatically associate
or deal with tickets which match certain regexps, etc. I actually started
looking at this stuff for a large US-based free email provider who wanted
something to magically handle their abuse mail.

There are some things that can be done codewise to speed up the queue display
by prepopulating the DBIx::SearchBuilder caches for Watchers and Keywords,
but they’re not really something I’m planning at looking at in the near future
unless a client needs them.

As you build up ticket content it should also be a lot easier for us to see
just what indices are going to help you out at that kind of volume.

Do you have any suggestions in what platform,
system configs, etc that will greatly improve and speed up the load time?

Lots of ram. Lots of processor. 5000 tickets/day is rather higher than RT is
really designed to handle at this point. At some point, you’re going
to want to start looking into migrating ‘historical’ ticket content to a
seperate archival database.

Nobel


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

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

‘“As the company that brought users the Internet, Netscape is now inviting
the more than 60 million people who have used our client software to
‘tune up’ and upgrade to Netscape Communicator,” said Mike Homer,
senior vice president of marketing at Netscape.’ Sometimes I wonder.