Re: [rt-users] Additional status in Quicksearch results but not in Quicksearch box
Hi Kevin,
thanks a lot for your hint. I changed QueueSummary and it works!
I'm not sure if it is the right way but this is what I did.
local/html/Elements/QueueSummary:
--- % my $all_q = $queue_cond . (.join( OR , map $_-{cond},
@$conditions).);
+++ % my $all_q = $queue_cond . (.join( OR , map $_-{cond},{cond =
Status = 'accepted', name = loc ('accepted') },{cond = Status = 'fixed',
name = loc ('fixed') },{cond = Status = 'verified', name = loc
('verified') },{cond = Status = 'new', name = loc ('new') },{cond =
Status = 'open', name = loc ('open') } ).);
Best regards,
Markus
-Ursprüngliche Nachricht-
Von: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von Kevin Falcone
Gesendet: Donnerstag, 3. Juni 2010 17:34
An: rt-users@lists.bestpractical.com
Betreff: Re: [rt-users] Additional status in Quicksearch results but not in
Quicksearch box
On Wed, Jun 02, 2010 at 01:27:06PM +0200, markus.kum...@t-systems.com wrote:
Hi Everybody,
I upgraded from RT 3.4.6 to RT 3.8.8.
In 3.4.6 it was possible to extend the default Quicksearch results to include
other status than new and open without showing them in the Quicksearch box
as a new column on the RT at a glance page.
I added the following to etc/RT_SiteConfig.pm
@ActiveStatus = qw(new open accepted fixed verified) unless
@ActiveStatus; @InactiveStatus = qw(resolved rejected deleted) unless
@InactiveStatus;
That created the new status accepted fixed verified and rejected.
I changed local/html/Elements/Quicksearch
--- my $all_q = Queue = '$qid' AND (Status = 'open' OR Status =
'new');
+++ my $all_q = Queue = '$qid' AND ( Status = 'new' OR Status =
+++ 'open' OR Status = 'accepted' OR Status = 'fixed' OR Status =
+++ 'verified');
and the new status showed up on the Quicksearch results page but not in the
QuickSearch box itself.
In RT 3.8.8 this doesn't work anymore:
Adding the new status accepted fixed and verified to
Set(@ActiveStatus, qw(new open stalled));
the status appear as expected in the ticket creation form but additionally as
a new column in the Quick Search Box also.
Adding them to
Set(@InactiveStatus, qw(accepted fixed verified resolved rejected
deleted));
gives me the new status for ticket creation. They don't show up in the Quick
Search box but in the Qicksearch results neither.
After searching the mailing list archives (e.g.
http://www.gossamer-threads.com/lists/rt/users/86368?search_string=Qui
cksearch;#86368) I edited the html/Elements/Quicksearch file as
follows
--- my @conditions = ();
+++ my @conditions = ( {cond = Status = 'accepted', name = loc
+++ ('accepted') }, {cond = Status = 'fixed', name = loc ('fixed')
+++ }, {cond = Status = 'verified', name = loc ('verified') },
+++ {cond = Status = 'requested', name = loc ('rejected') } );
The result is the same as setting them in the ActiveStatus in
RT_SiteConfig.pm.
The status show up in the Quicksearch box as a new column AND on the
Quicksearch results page.
Is it possible to configure RT to exclude the extra status in the Quicksearch
box but still see them in the results?
I assume see them in the results means see them when you click on the queue
name. Sounds like you want to hack the definition of $all_q in an overlay of
QueueSummary rather than touching Quicksearch
-kevin
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] case insensitive searching in Content?
... 3rd try to mail ... On Sun, Jun 06, 2010 at 02:34:58PM -0500, Kenneth Marshall wrote: Hi Zito, You can look in the mailing list archives for several similar discoveries on how MySQL works with content searches and the longblob data type. I would definitely recommend using PostgreSQL for its full-text indexing available in the wiki. Of course, I am partial... :) Hi Ken, thanks for the suggestion. I red the wiki page http://wiki.bestpractical.com/view/PostgreSQLFullText already. I'm definitely going to try this way, also patching DBIx::SearchBuilder is a bit hack, but ILIKE is too slow on Pg. Regards -- Zito Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Time taken to open ticket history
Hi, just try out my extension: http://github.com/cloos/rt-extension-historyfilter Chris Am 08.06.2010 01:31, schrieb Brian D: Ken, Is there a patch out there that does this? Hiding some of the extraneous txns is something I was thinking of doing as well. Thanks, Brian On Jun 7, 2010 4:53 PM, Kenneth Marshall k...@rice.edu mailto:k...@rice.edu wrote: Hi Justin, The last time I looked at this problem, the slow step is simply preparing all of the transactions for the web. The biggest gains were made by pruning the list of displayed transactions to the bare minimum, by default. Then have a button to allow seeing all of the transactions, if needed. Regards, Ken On Thu, Jun 03, 2010 at 09:27:45AM +0100, Justin Hayes wrote: RT 3.8.4 Does anyone have any ... Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bes... Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Time taken to open ticket history
You'd want to prune at the DB query level though I'd have thought? Otherwise it still has to loop over everything to decide whether or not to show things. I'm already doing this (my Display doesnt show quite a lot compared to History) but there's not much speed difference. Perhaps I'm pruning at too high a level in the code? Thanks, Justin - Justin Hayes Orbis Support Manager justin.ha...@orbisuk.com On 7 Jun 2010, at 21:53, Kenneth Marshall wrote: Hi Justin, The last time I looked at this problem, the slow step is simply preparing all of the transactions for the web. The biggest gains were made by pruning the list of displayed transactions to the bare minimum, by default. Then have a button to allow seeing all of the transactions, if needed. Regards, Ken On Thu, Jun 03, 2010 at 09:27:45AM +0100, Justin Hayes wrote: RT 3.8.4 Does anyone have any suggestions on how to improve the time taken for RT to display ticket history. Depending on the number of entries on the ticket it can take 6-30seconds to render the ticket. I've had a look in the mysql logs for slow queries and can't see any (though it's only logging ones that take longer than 1s so maybe it's doing lots and lots of faster ones that can still be optimised). I've put some debug logging in and all the time is going in ShowHistory, so I guess in the loop that loops over all the various transactions and things to display for that ticket. Any suggestions or tweaks that people have done would be great, before I start investigating what's going on at a lower level. Thanks, Justin Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Time taken to open ticket history
I'm using a SkipTransation callback in ShowHistory that does something like
%init
my $ttype;
$ttype = $Transaction-Type;
$$skip = 1 if (($_SkipSystemMessages) ((($Transaction-Creator eq
RT-Config-Get('SystemUserID'))
($Transaction-Type ne 'Status')
($Transaction-Type ne 'Comment')) || (($Transaction-Creator eq
RT-Config-Get('CronUserID'))
(($Transaction-Type ne 'Give')
($Transaction-Type ne 'Correspond'))) || ($Transaction-Type eq
'CustomField') || ($Transaction-Type eq 'Set'
$Transaction-Field eq 'TimeWorked')) );
my $type = $Transaction-Type;
/%init
But I guess it's too late at this point for performance reasons, as we're
already processing the entry?
Justin
-
Justin Hayes
Orbis Support Manager
justin.ha...@orbisuk.com
On 7 Jun 2010, at 21:53, Kenneth Marshall wrote:
Hi Justin,
The last time I looked at this problem, the slow step is simply
preparing all of the transactions for the web. The biggest gains
were made by pruning the list of displayed transactions to the
bare minimum, by default. Then have a button to allow seeing
all of the transactions, if needed.
Regards,
Ken
On Thu, Jun 03, 2010 at 09:27:45AM +0100, Justin Hayes wrote:
RT 3.8.4
Does anyone have any suggestions on how to improve the time taken for RT to
display ticket history. Depending on the number of entries on the ticket it
can take 6-30seconds to render the ticket.
I've had a look in the mysql logs for slow queries and can't see any (though
it's only logging ones that take longer than 1s so maybe it's doing lots and
lots of faster ones that can still be optimised).
I've put some debug logging in and all the time is going in ShowHistory, so
I guess in the loop that loops over all the various transactions and things
to display for that ticket.
Any suggestions or tweaks that people have done would be great, before I
start investigating what's going on at a lower level.
Thanks,
Justin
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] case insensitive searching in Content?
On Tue, Jun 08, 2010 at 09:10:23AM +0200, V?clav Ovs?k wrote: ... 3rd try to mail ... On Sun, Jun 06, 2010 at 02:34:58PM -0500, Kenneth Marshall wrote: Hi Zito, You can look in the mailing list archives for several similar discoveries on how MySQL works with content searches and the longblob data type. I would definitely recommend using PostgreSQL for its full-text indexing available in the wiki. Of course, I am partial... :) Hi Ken, thanks for the suggestion. I red the wiki page http://wiki.bestpractical.com/view/PostgreSQLFullText already. I'm definitely going to try this way, also patching DBIx::SearchBuilder is a bit hack, but ILIKE is too slow on Pg. Regards -- Zito Hi Zito, ILIKE is fine on PostgreSQL as long as the search is anchored on the left and there is an index. Otherwise it will do a sequential scan of the attachments table to find matching records. The wiki entries for full-text indexing with PostgreSQL and Oracle can avoid the sequential scan through the use of the database's full-text index support. I do agree that patching the actual DBIx::SearchBuilder is not preferable. Unfortunately, since that is the API that is used to provide a database abstraction layer and it does not yet include the ability to specify full-text indexing details, you have to patch it. If it is any consolation, the patch is much, much simpler (trivial) for the PostgreSQL support versus the version that is needed for OracleText. :) Regards, Ken Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Error when upgrading 3.8.6 - 3.8.8
On Fri, Jun 04, 2010 at 08:08:56PM -0700, Shannon Adams wrote: Running CentOS 5.5 - fully patched. Trying to upgrade from 3.8.6 to 3.8.8. # make upgrade The interesting part is probably your ./configure line and the output -kevin . . All dependencies have been found. /opt/local/bin/ginstall -c -m 0755 -o root -g www -d /opt/rt3/etc make: /opt/local/bin/ginstall: Command not found make: *** [config-install] Error 127 # I can't find anything in the README or UPGRADING doc that would indicate why I am getting this. Thanks for any help. pgp3W2jo6rSFS.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RTAddressRegexp and 3.8.8
On Mon, Jun 07, 2010 at 02:49:45PM -0500, John Arends wrote: Is there now more strict checking for RTAddressRegexp in 3.8.8? I don't remember getting this error in the past. Yes, it did [Mon Jun 7 19:42:01 2010] [error]: The RTAddressRegexp option is not set in the config. Not setting this option results in additional SQL queries to check whether each address belongs to RT or not. It is especially important to set this option if RT recieves emails on addresses that are not in the database or config. (/opt/rt3/bin/../lib/RT/Config.pm:343) pgpeJPf3z943a.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] case insensitive searching in Content?
Hi Ken, On Tue, Jun 08, 2010 at 07:48:15AM -0500, Kenneth Marshall wrote: ILIKE is fine on PostgreSQL as long as the search is anchored on the left and there is an index. Otherwise it will do a sequential scan of the attachments table to find matching records. The wiki entries for full-text indexing with PostgreSQL and Oracle can avoid the sequential scan through the use of the database's full-text thanks for your work on PostgreSQLFullText wiki page! Good starting point. I'm playing with the fulltext on one instance already. I must discuss the possibility to use the fulltext on Pg with my leader. The results are different from those get from ILIKE. I tried to find 'cisco' for example :). Normal search returned 25 tickets, but fulltext only 15. Fulltext parser did tokens from URL and www.cisco.com was a lexem as is (not broken further). I can't say this is fine or not, it is difference. Users must know this - how to write the query correctly. index support. I do agree that patching the actual DBIx::SearchBuilder is not preferable. Unfortunately, since that is the API that is used to provide a database abstraction layer and it does not yet include the ability to specify full-text indexing details, you have to patch it. If it is any consolation, the patch is much, much simpler (trivial) for the PostgreSQL support versus the version that is needed for OracleText. :) I completely understand. I put the package libdbix-searchbuilder-perl (Debian) on hold in aptitude, so sysadmin should remember, that this package needs a special handling. I did a copy of SearchBuilder.pm file into rt-prefix/local/lib/DBIx/ and did a modification. This perl path is searched first, so a modification is beside other RT code... I have prepared a script for converting data from Mysql to Pg and for adding/removing fulltext support based on your wiki page. Maybe it can be added to wiki for someone else to play with fulltext and Pg. I must to test it a bit and switch some fixed parts into conditional blocks controlled by command-line options. Regards -- Zito Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] case insensitive searching in Content?
On Tue, Jun 08, 2010 at 04:57:25PM +0200, V?clav Ovs?k wrote: Hi Ken, On Tue, Jun 08, 2010 at 07:48:15AM -0500, Kenneth Marshall wrote: ILIKE is fine on PostgreSQL as long as the search is anchored on the left and there is an index. Otherwise it will do a sequential scan of the attachments table to find matching records. The wiki entries for full-text indexing with PostgreSQL and Oracle can avoid the sequential scan through the use of the database's full-text thanks for your work on PostgreSQLFullText wiki page! Good starting point. I'm playing with the fulltext on one instance already. I must discuss the possibility to use the fulltext on Pg with my leader. The results are different from those get from ILIKE. I tried to find 'cisco' for example :). Normal search returned 25 tickets, but fulltext only 15. Fulltext parser did tokens from URL and www.cisco.com was a lexem as is (not broken further). I can't say this is fine or not, it is difference. Users must know this - how to write the query correctly. Correct, the results depend on the parsing rules that are used by the full-text configuration. These rules can be adapted to your needs, but I do agree that some explanation about common types of query problems would be worthwhile. Regards, Ken Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Odd custom fields category from field source
I've just been working with RT::CustomFieldValues::External, and having created one that pulls in a list from another database, I'm seeing it using what appears to be the name of one of our groups as a category heading. (Though when I change the name of the group, it's not changing. So I may well be wrong) I then tried the simple example in the docs (with no modification) and it's doing exactly the same thing. This is when it's set up as a 'select one value' custom field. Anyone seen anything similar with this? Steve Anderson BiP Solutions Limited is a company registered in Scotland with Company Number SC086146 and VAT number 383030966 and having its registered office at Medius, 60 Pacific Quay, Glasgow, G51 1DZ. This e-mail (and any attachment) is intended only for the attention of the addressee(s). Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return e-mail. This e-mail (whether you are the sender or the recipient) may be monitored, recorded and retained by BiP Solutions Ltd. E-mail monitoring/ blocking software may be used, and e-mail content may be read at any time.You have a responsibility to ensure laws are not broken when composing or forwarding e-mails and their contents. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] winmail.dat in Ticket Replies
Not having much luck thus far... Can anyone explain why none of the TNEF decoders seem to be able to decode the ticket replies? What is different about the reply than the original email? FYI - 1.)Initial Ticket creation attachments come through - no problem 2.)Emailing with the Ticket Subject line and attachment - no problem 3.)Replying to ticket result with an attachment results in winmail.dat - problem Disabling TNEF in Exchange is not an option since several of the mail servers are outside of our control TIA, Steve Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Odd custom fields category from field source
Evening all, Well, answered part of my own question, as I've found where it's coming from. It's in the Attributes table. Update the value there, and it shows up right. ++--+-+--+-+--+--+-+-+---+-+ | id | Name | Description | Content | ContentType | ObjectType | ObjectId | Creator | Created | LastUpdatedBy | LastUpdated | ++--+-+--+-+--+--+-+-+---+-+ | 5 | Category | 0 | Desktop Support1 | | RT::CustomFieldValue |1 | 12 | 2007-02-13 11:15:22 |12 | 2007-02-13 11:18:51 | ++--+-+--+-+--+--+-+-+---+-+ Anyone have an idea about what I can do about it? The ObjectId doesn't match the ID of the custom field (That's 5.) Using RT 3.8.8, (upgraded most recently from 3.8.2) Steve Anderson From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Steve Anderson Sent: 08 June 2010 6:39 PM To: rt-users@lists.bestpractical.com Subject: [rt-users] Odd custom fields category from field source I've just been working with RT::CustomFieldValues::External, and having created one that pulls in a list from another database, I'm seeing it using what appears to be the name of one of our groups as a category heading. (Though when I change the name of the group, it's not changing. So I may well be wrong) I then tried the simple example in the docs (with no modification) and it's doing exactly the same thing. This is when it's set up as a 'select one value' custom field. Anyone seen anything similar with this? Steve Anderson BiP Solutions Limited is a company registered in Scotland with Company Number SC086146 and VAT number 383030966 and having its registered office at Medius, 60 Pacific Quay, Glasgow, G51 1DZ. This e-mail (and any attachment) is intended only for the attention of the addressee(s). Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return e-mail. This e-mail (whether you are the sender or the recipient) may be monitored, recorded and retained by BiP Solutions Ltd. E-mail monitoring/ blocking software may be used, and e-mail content may be read at any time.You have a responsibility to ensure laws are not broken when composing or forwarding e-mails and their contents. This email has been scanned by Netintelligence http://www.netintelligence.com/email BiP Solutions Limited is a company registered in Scotland with Company Number SC086146 and VAT number 383030966 and having its registered office at Medius, 60 Pacific Quay, Glasgow, G51 1DZ. This e-mail (and any attachment) is intended only for the attention of the addressee(s). Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return e-mail. This e-mail (whether you are the sender or the recipient) may be monitored, recorded and retained by BiP Solutions Ltd. E-mail monitoring/ blocking software may be used, and e-mail content may be read at any time.You have a responsibility to ensure laws are not broken when composing or forwarding e-mails and their contents. Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] How to change the RT Self Service web interface for Unprivileged user?
Hi, Can anyone tell me how to change the default web interface for the Unprivileged users (RT Self Service) in RT. I would like to add the Date column in RT Self Service / Open tickets and Close tickets pages. Thanks in advance for your help! /Sumon Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] How to change the RT Self Service web interface for Unprivileged user?
On Wed, Jun 09, 2010 at 12:31:06AM +0200, Saiful Islam Sumon wrote: Can anyone tell me how to change the default web interface for the Unprivileged users (RT Self Service) in RT. I would like to add the Date column in RT Self Service / Open tickets and Close tickets pages. Assuming you're running 3.8.7 or higher, open RT_Config.pm and search for SelfService to find the appropriate config option -kevin pgpbX1WqYUOaT.pgp Description: PGP signature Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
