Lol.
At least this list allows itself some Monday morning's (for us) British
humour :-)
Giuseppe
On 06/12/10 21:17, Michael Finn wrote:
(sorry to stray off-topic, but...)
Obligatory xkcd comic ref:
http://xkcd.com/149/
-Original Message-
From:
Not to discourage you, but it is really better to not default to
search resolved tickets. That number will grow without bound and
eventually kill your performance. Also, how will you NOT search
the resolved tickets? My two cents.
Cheers,
Ken
On Tue, Dec 07, 2010 at 05:47:06PM +0300, alexander
Hi Bernard,
Thank you so much for your suggestion!!! I tried it and
worked. Now I have to set it up as a cron job. I will let you know how that
goes.
Many thanks again!!!
Bernard McCormack wrote:
I had a problem with this as well you have to create a template with :
Hello Kevin,
Thanks for your reply. Please how would I do it if I
wanted to avoid cluttering up history?
Regards
Imonike
Kevin Falcone-2 wrote:
On Mon, Dec 06, 2010 at 05:51:30PM -0500, Bernard McCormack wrote:
I had a problem with this as well you have to create a
I've used the following to make it transparent, also not updating last
update.
-action-arg RecordTransaction: 0 --action-arg UpdateLastUpdated: 0
On 10-12-07 11:08 AM, imonike wrote:
Hello Kevin,
Thanks for your reply. Please how would I do it if I
wanted to avoid
It would appear the action-arg is dependent on the action. I'm not sure
if they support the same features. You may need to check out the source
for them. Mine was for LinearEscalate.
On 10-12-07 11:17 AM, Curtis Bruneau wrote:
I've used the following to make it transparent, also not updating
I assume RTDEBUG is an environmental variable I can set in perl using
$ENV{RTDEBUG}, but I'm not sure what you mean by bin/rt. What is that
referring to? The CLI?
--
~Jonny Sweeny, GSEC, GCWN, GCIH, GWAS
Incident Response Manager, Lead Security Analyst
Office of the VP for Information
On Tue, Dec 07, 2010 at 04:48:21PM +, Sweeny, Jonny wrote:
I assume RTDEBUG is an environmental variable I can set in perl using
$ENV{RTDEBUG}, but I'm not sure what you mean by bin/rt. What is that
referring to? The CLI?
Yes, /opt/rt3/bin/rt, the command line client that uses REST
If
Guys,
Searching for ticket content takes forever. I've done a bit of digging and for
a single search in one of my queues over the last year, RT spawned 3 separate
queries.
2 are counts (which appear to be identical), and 1 gets the actual content.
Is there anyway round this? Losing loads of
You need to use a DB backend that supports fulltext indexing for
content searchs to be fast. The actual query that you stated runs
quickly, is only for the first 50 tickets. I do agree that running
the same count() query twice for the same search is sub-optimal. I
do not see how you could avoid
Hi Ken,
I was just thinking the same about the counts - it has to do that for
pagination. Though I guess it could have been written to run 1 query for all
the data, and just display the first 50 etc.
Which DB backend would work faster?
Thanks,
Justin
Hi Justin,
In the wiki, there are fulltext index modifications for Oracle and
PostgreSQL. I based the PostgreSQL version on the Oracle version
and we use it here. It works very well indeed. It looks like the
pre version rt-4, a.k.a rt-3.9.6 support Oracle and PostgreSQL
using their fulltext
07.12.2010 17:51, Kenneth Marshall пишет:
Not to discourage you, but it is really better to not default to
search resolved tickets. That number will grow without bound and
eventually kill your performance. Also, how will you NOT search
the resolved tickets? My two cents.
I _need_ to search
Здравствуйте товарищи.
Подскажите пжлста, начал осваивать продукт request-tracker
настроил по мануалу.
сейчас в логи валиться такой текст:
[Wed Dec 08 10:54:31 2010] [notice] caught SIGTERM, shutting down
[Wed Dec 8 07:54:46 2010] [error]: The RTAddressRegexp option is not set in
the config. Not
14 matches
Mail list logo
