Re: [rt-users] Blank in default preference / search options ?
It's a wrong path. Correct path is: /opt/rt3/local/html/Callbacks/MyCallbacks/Search/Elements/BuildFormatString/SetFieldsOnce yes - sorry about this )-: You are right. A reference to array is passed, so you should use reference: ... That's it. Not tested. Great, the following works like a charm: %INIT push @$Fields, 'NBSP'; /%INIT %ARGS $Fields = [] /%ARGS Now, a I can insert a 'NBSP' which will be displayed as a Blank. Best regards Danny
[rt-users] Adding/Removing/Rename Fields under Basics
Hi All, Under a given Ticket's Basic page there are a few fields such as Status, Queue, Owner, Time Worked, Time Estimated Time Left. Is it possible to add more fields to the Basic page or rename the Time Worked/Time Estimated/Time Left? Regards Ronald
Re: [rt-users] RT::Extension::LDAPImport install fails
Hi Kevin, thanks for your reply. Comments inline. On 26/05/11 16:55, Kevin Falcone wrote: On Thu, May 26, 2011 at 02:59:05PM +0100, Giuseppe Sollazzo wrote: The reason I answered n is that if I try and install the test package I get the following output (even if I try the install separately): Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/00-load.t ... 1/1 # Testing Net::LDAP::Server::Test 0.10, Perl 5.008008, /usr/bin/perl t/00-load.t ... ok t/01-ldap.t ... 1/12 Creating new LDAP server on port 10636 ... Accepted connection from: 127.0.0.1 Creating new LDAP server on port 10636 ... Unable to listen on port 10636: Address already in use at /root/.cpan/build/Net-LDAP-Server-Test-0.10/blib/lib/Net/LDAP/Server/Test.pm line 844. ... shutting down server This is a random port, so either you have a conflict on the random port it chose, or some other restriction from your OS. Uhm... weird as running from root. Also, what do you mean by random? Every time I run the install the port is the same, do I have any way of altering the seed? You do understand that the test suite will need to create an rt3test database and put data in it? It gets to that point actually. But this is RT4, so rt4test, which was created without issues specifying the DBA user/pass as an environment variable. I suspect that you really do not want to run the test suite, and we'll release an update that moves them to author tests. I still suggest a manual installation since it will make it easier for you to review the README Ok - I'll have a look at the README and experiment with the manual install, although I'd prefer a packaged release for the live server. Please let me know about your release plans. Many thanks, Giuseppe -- Giuseppe Sollazzo Senior Systems Analyst Computing Services Information Services St. George's, University Of London Cranmer Terrace London SW17 0RE Email: gsoll...@sgul.ac.uk Direct Dial: +44 20 8725 5160 Fax: +44 20 8725 3583
[rt-users] Blacklist and Bugzilla
We're seeing bugzilla-internal@[redacted].com was blacklisted for outbound mail on this transaction We want to send mail to this address, and this used to work with 3.6 (now running 3.8.8). How can we change the behaviour so that mail is sent to that Bugzilla address? Thanks, Keith -- You can have everything in life you want if you help enough other people get what they want - Zig Ziglar. Who did you help today?
Re: [rt-users] Blacklist and Bugzilla
Hi, RTAddressRegexp, this option may be matches more addresses. Check squelching, may be somebody manually marked this address to stop mails. On Tue, May 31, 2011 at 3:32 PM, Keith Edmunds k...@midnighthax.com wrote: We're seeing bugzilla-internal@[redacted].com was blacklisted for outbound mail on this transaction We want to send mail to this address, and this used to work with 3.6 (now running 3.8.8). How can we change the behaviour so that mail is sent to that Bugzilla address? Thanks, Keith -- You can have everything in life you want if you help enough other people get what they want - Zig Ziglar. Who did you help today? -- Best regards, Ruslan.
[rt-users] RT4 slowness
Hi, I'm testing RT4 and I have slowness problems. I tried these environments: - RHEL6 64bits/ RedHat httpd-2.2.15 / RedHat perl 5.10 / RedHat mod_perl 2.0.4 / RT 4.0 - RHEL6 64bits/ RedHat httpd-2.2.15 / own compiled perl 5.14 / own compiled mod_perl 2.0.5 / RT 4.0 - RHEL6 64bits/ RedHat httpd-2.2.15 / own compiled perl 5.14 / own compiled mod_perl 2.0.5 / RT 4.1rc1 - RHEL6 64bits/ RedHat httpd-2.2.15 / own compiled perl 5.14 / own compiled mod_perl 2.0.6-devel / RT 4.1rc1 All perl dependencies have been installed using CPAN with the make fixdeps. (in system perl directories in the first case, and my local perl diretories in the others). My compiled Perl has roughly the same options as the RedHat perl (ithread included). All are slow. The machine is quite fast, I don't think it's the problem. I tried with a local postgresql database and a remote one, no change. Clean new empty database. My Apache configuration follows the web-deployment.pod documentation, basically it has: Location / Order allow,deny Allow from all SetHandler perl-script PerlResponseHandler Plack::Handler::Apache2 PerlSetVar psgi_app /opt/rt4/sbin/rt-server /Location Perl use Plack::Handler::Apache2; Plack::Handler::Apache2-preload(/opt/rt4-CSAHUT/sbin/rt-server); /Perl Note: the Perl/Perl section slows down a lot Apache service restart but I guess it's normal if it preloads rt-server I added this to use my own perl: PerlSwitches -I/opt/perl-5.14.0/lib/5.14.0/ -I/opt/perl-5.14.0/lib/site_perl/5.14.0/x86_64-linux/ -I/opt/perl-5.14.0/lib/site_perl/5.14.0/ I tried also /opt/rt4/sbin/rt-server --port 8080 and /opt/rt4/sbin/rt-server --server Starman --port 8080 Same slowness. What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. I created one ticket, and displaying it takes several seconds. Browsing in RT is not fast. Even accessing the same pages is not that fast (maybe a little bit faster than the first access, but not much). I tried to turn on debugging in Apache and RT, but I see nothing wrong. Any idea what I can try now ? Many thanks, -- L.B.
Re: [rt-users] custom field position and layout design
On Sat, May 28, 2011 at 09:56:59PM +0400, Ruslan Zakirov wrote: Order controlled in UI. Order is global setting. Use latest 3.8.x releses where functionality was improved. To expand a little - you can control this from Configuration - Queues - Queue Name - Ticket Custom Fields I believe you need at least 3.8.8 for the features Ruz added -kevin Layout is not configurable through UI, you can try CSS, but I'm not sure how far you can go with it. On Sat, May 28, 2011 at 7:34 PM, Gilbert Rebeiro gilb...@dido.ca wrote: Hi, We would like to know if it is possible to control the order and layout of custom fields. Specifically we have 2 different groups of users that should fill out 2 groups of custom fields. It would be nice to group them separately have control over the order and layout. Any suggestions? pgpINbgaJMBkh.pgp Description: PGP signature
Re: [rt-users] rt4.0: anonymous hash error on apache startup
On Sun, May 29, 2011 at 12:21:10PM -0400, Bill Cole wrote:
Ruslan Zakirov wrote, On 5/28/11 1:46 PM:
Hello,
Problem is in your config file. Somewhere you set a hash option
(key-value pairs), but misses key or value and number of elements in
assignment is odd.
A very likely cause of this is the ChartFont setting. It changed
from a scalar in RT3 to a hash in RT4, so the config 'Set' command
for RT3 will generate that specific error.
This actually changed between 3.8.7 and 3.8.8
There are notes about it in docs/UPGRADING-3.8
As Ruslan notes later in the thread, if you aren't customizing the
setting, you really shouldn't copy settings from RT_Config.pm to
RT_SiteConfig.pm. You especially shouldn't just copy everything over.
-kevin
On Sat, May 28, 2011 at 2:15 PM, Daniel G. Rohan
d-ro...@northwestern.edu wrote:
Hello everyone,
We've recently upgraded to 4.0.0 and whenever we start up our apache (using
mod_perl), we get the following errors:
Starting httpd: Odd number of elements in anonymous hash at
/opt/rt4/sbin/../lib/RT/Config.pm line 861.
Use of uninitialized value in anonymous hash ({}) at
/opt/rt4/sbin/../lib/RT/Config.pm line 861.
Odd number of elements in hash assignment at
/opt/rt4/sbin/../lib/RT/Config.pm line 862.
Use of uninitialized value in list assignment at
/opt/rt4/sbin/../lib/RT/Config.pm line 862.
This seems to reference this subroutine in /opt/rt4//lib/RT/Config.pm
sub Set {
my ( $self, $name ) = ( shift, shift );
my $old = $OPTIONS{$name};
my $type = $META{$name}-{'Type'} || 'SCALAR';
if ( $type eq 'ARRAY' ) {
$OPTIONS{$name} = [@_];
{ no warnings 'once'; no strict 'refs'; @{RT::$name} = (@_); }
} elsif ( $type eq 'HASH' ) {
$OPTIONS{$name} = {@_};
{ no warnings 'once'; no strict 'refs'; %{RT::$name} = (@_); }
} else {
$OPTIONS{$name} = shift;
{no warnings 'once'; no strict 'refs'; ${RT::$name} =
$OPTIONS{$name}; }
}
$META{$name}-{'Type'} = $type;
return $self-_ReturnValue( $old, $type );
}
Apache starts up fine, and RT seems to be working, but this is concerning
to us. Any suggestions or insight into what might be the issue?
Thanks,
Dan Rohan
pgpBoCbdqQX5T.pgp
Description: PGP signature
Re: [rt-users] RT 3.6 to RT4 upgrade with Oracle
On Mon, May 30, 2011 at 04:21:11PM -0400, Jean-Philippe Houde wrote: My client is currently using RT 3.6.4 on Oracle 11g. We are looking into upgrading to RT 4.0.0. According to the documentation, a fresh install should be pretty simple. However, there is no instruction on upgrading when using Oracle. Does that mean nothing special needs to be done? From the README, we can see the following: If you are using MySQL, please read the instructions in docs/UPGRADING.mysql as well to ensure that you do not corrupt existing data. We would expect the same kind of document for Oracle. There is none. There also isn't a separate document for Postgres. MySQL has a number of special steps required that aren't needed for Oracle or Pg. You should review docs/UPGRADING-3.6 3.8 and 4.0 along with the README. All the upgrading instructions are there. You may also want to test 4.0.1rc1 since it includes a number of bugfixes for issues discovered in 4.0.0. -kevin pgpST9RiKQRTg.pgp Description: PGP signature
Re: [rt-users] Adding/Removing/Rename Fields under Basics
On Tue, May 31, 2011 at 11:26:38AM +0200, ronald higgins wrote: Under a given Ticket's Basic page there are a few fields such as Status, Queue, Owner, Time Worked, Time Estimated Time Left. Is it possible to add more fields to the Basic page or rename the Time Worked/Time Estimated/Time Left? It sounds like you want Custom Fields. -kevin pgpoZLe01MwVF.pgp Description: PGP signature
Re: [rt-users] RT::Extension::LDAPImport install fails
On Tue, May 31, 2011 at 10:52:43AM +0100, Giuseppe Sollazzo wrote: t/00-load.t ... ok t/01-ldap.t ... 1/12 Creating new LDAP server on port 10636 ... Accepted connection from: 127.0.0.1 Creating new LDAP server on port 10636 ... Unable to listen on port 10636: Address already in use at /root/.cpan/build/Net-LDAP-Server-Test-0.10/blib/lib/Net/LDAP/Server/Test.pm line 844. ... shutting down server This is a random port, so either you have a conflict on the random port it chose, or some other restriction from your OS. Uhm... weird as running from root. Also, what do you mean by random? Every time I run the install the port is the same, do I have any way of altering the seed? Oh, this is you being unable to install Net::LDAP::Server::Test If it hardcodes a port, you'll either need to tweak the test suite or file a bug with the author. We have no control over that. I suspect that you really do not want to run the test suite, and we'll release an update that moves them to author tests. I still suggest a manual installation since it will make it easier for you to review the README Ok - I'll have a look at the README and experiment with the manual install, although I'd prefer a packaged release for the live server. Please let me know about your release plans. You realize that the manual install is simply replicating what the cpan shell does? The cpan shell downloads, untars it, runs perl Makefile.PL, runs tests, installs. What you would do is download the tarball, untar it, read the README, follow the instructions to run Makefile.PL and install it. The CPAN client will not configure the extension or add it to your RT_SiteConfig.pm so you're still going to need to read the README and do some manual things. I'm not actually aware of any packages of this extension. -kevin pgpRT8YNJ12SL.pgp Description: PGP signature
Re: [rt-users] RT4 slowness
On Tue, May 31, 2011 at 03:21:17PM +0200, L B wrote: What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. You should only see this for the first request while things are squished. If you're seeing it for subsequent requests on a standalone server, then something is quite wrong. If you would like to use something faster than JavaScript::Minifier, you can check out JSMinPath in RT_Config.pm -kevin pgpmWvAyjyL9j.pgp Description: PGP signature
Re: [rt-users] RT::Extension::LDAPImport install fails
Hi Kevin, thanks for the clarification. I'm not practical with perl/cpan in general and trying to find my way trough. I'm surprised no other users have experienced a similar problem when installing Net::LDAP::Server::Test, but I'll give a look - it seems to try using that port even upon rebooting. Thanks, G On 31/05/11 15:32, Kevin Falcone wrote: On Tue, May 31, 2011 at 10:52:43AM +0100, Giuseppe Sollazzo wrote: t/00-load.t ... ok t/01-ldap.t ... 1/12 Creating new LDAP server on port 10636 ... Accepted connection from: 127.0.0.1 Creating new LDAP server on port 10636 ... Unable to listen on port 10636: Address already in use at /root/.cpan/build/Net-LDAP-Server-Test-0.10/blib/lib/Net/LDAP/Server/Test.pm line 844. ... shutting down server This is a random port, so either you have a conflict on the random port it chose, or some other restriction from your OS. Uhm... weird as running from root. Also, what do you mean by random? Every time I run the install the port is the same, do I have any way of altering the seed? Oh, this is you being unable to install Net::LDAP::Server::Test If it hardcodes a port, you'll either need to tweak the test suite or file a bug with the author. We have no control over that. I suspect that you really do not want to run the test suite, and we'll release an update that moves them to author tests. I still suggest a manual installation since it will make it easier for you to review the README Ok - I'll have a look at the README and experiment with the manual install, although I'd prefer a packaged release for the live server. Please let me know about your release plans. You realize that the manual install is simply replicating what the cpan shell does? The cpan shell downloads, untars it, runs perl Makefile.PL, runs tests, installs. What you would do is download the tarball, untar it, read the README, follow the instructions to run Makefile.PL and install it. The CPAN client will not configure the extension or add it to your RT_SiteConfig.pm so you're still going to need to read the README and do some manual things. I'm not actually aware of any packages of this extension. -kevin -- Giuseppe Sollazzo Senior Systems Analyst Computing Services Information Services St. George's, University Of London Cranmer Terrace London SW17 0RE Email: gsoll...@sgul.ac.uk Direct Dial: +44 20 8725 5160 Fax: +44 20 8725 3583
Re: [rt-users] RT4 - mod_perl problem with apache2
On Mon, May 30, 2011 at 12:09:11PM +0200, Robert Wysocki wrote:
Hi guys,
I've googled it, some people also have this problem, but no solutions
were provided by anyone.
The problem is:
testrt:/opt/rt4/etc# apache2ctl restart
/usr/sbin/apache2ctl: line 107: 11712 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t 2 /dev/null
Syntax OK
/usr/sbin/apache2ctl: line 107: 11715 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t
Action 'restart' failed.
The Apache error log may have more information.
testrt:/opt/rt4/etc# /etc/init.d/apache2 reload
Syntax OK
/usr/sbin/apache2ctl: line 107: 11729 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t
Action 'configtest' failed.
The Apache error log may have more information.
failed!
The way of restarting apache which doesn't cause error to be thrown is
just:
/etc/init.d/apache2 stop; /etc/init.d/apache2 start
but it's, well, inelegant.
The issue is probably related to Plack.
Unfortunately, it's difficult to try replicating without a
perl/apache/mod_perl2/plack version list
-kevin
pgpuSBCg2cSBO.pgp
Description: PGP signature
Re: [rt-users] RT4 - mod_perl problem with apache2
On 05/30/2011 3:09 AM, Robert Wysocki wrote:
Hi guys,
I've googled it, some people also have this problem, but no solutions
were provided by anyone.
The problem is:
testrt:/opt/rt4/etc# apache2ctl restart
/usr/sbin/apache2ctl: line 107: 11712 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t 2 /dev/null
Syntax OK
/usr/sbin/apache2ctl: line 107: 11715 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t
Action 'restart' failed.
The Apache error log may have more information.
testrt:/opt/rt4/etc# /etc/init.d/apache2 reload
Syntax OK
/usr/sbin/apache2ctl: line 107: 11729 Segmentation fault $HTTPD
${APACHE_ARGUMENTS} -t
Action 'configtest' failed.
The Apache error log may have more information.
failed!
The way of restarting apache which doesn't cause error to be thrown is
just:
/etc/init.d/apache2 stop; /etc/init.d/apache2 start
but it's, well, inelegant.
The issue is probably related to Plack.
Any suggestions?
Regards,
Looks like its cause you have your $APACHE_ARGUMENTS set with a -t by
default. On my system, apache2ctl wont restart my server with a -t
argument. It does, however, restart it perfectly fine without the -t
argument. Looking into the /usr/sbin/apache2ctl file, line 107 is
where it takes in the command line arguments. Try clearing the
$APACHE_ARGUMENTS variable and try again.
And Kevin makes a valid point. Version and distro information would be
very helpful.
Good luck,
Matt
[rt-users] Setting the Requestor to be the CurrentUser in a created ticket
Hello
I am creating tickets automatically when a CF is set to a specific value
I would like to to put the name of the User that changes the CF value in
the Content.
I would also like to set the Requestor of the new ticket to be the User
that changes the CF value
I have been unable to find a way to do that (I searched the wiki)
The (simplified) template to create that new ticket is below
(for the moment I am just trying to get the name of the CurrentUser in
the Content part
I will set the Requestor once I get that part right)
I have tried
* new RT::CurrentUser( $session{'CurrentUser'} );
* new RT::CurrentUser;
* $session{'CurrentUser'}
* $Tickets{'TOP'}-CurrentUser
none of them seems to give me the expected result
(the first three return nothing, the last returns the SystemUser)
Can someone help me out ?
Thanks
Gerard
===Create-Ticket: new_patch_request
Queue: Patch Request
Subject: patch for RT { $Tickets{'TOP'}-Id() }
RefersTo: { $Tickets{'TOP'}-Id() }
CustomField-4: { $Tickets{'TOP'}-FirstCustomFieldValue( 'SW' ) ||
Unknown ; }
Content:
{ my $current_user = ? ;
$current_user-RealName if $current_user }
is requesting an official patch for ticket { $Tickets{'TOP'}-Id() }
(Subject: { $Tickets{'TOP'}-Subject }).
ENDOFCONTENT
Re: [rt-users] Setting the Requestor to be the CurrentUser in a created ticket
On Tue, May 31, 2011 at 05:32:35PM +0200, Gerard FENELON wrote:
Hello
I am creating tickets automatically when a CF is set to a specific value
I would like to to put the name of the User that changes the CF value in
the Content.
I would also like to set the Requestor of the new ticket to be the User
that changes the CF
value
I have been unable to find a way to do that (I searched the wiki)
Assuming a new enough RT (3.8.9 I think) you can use $TransactionObj
to get the CreatorObj of the transaction that triggered your Scrip.
That is the correct way to figure out who caused something.
-kevin
The (simplified) template to create that new ticket is below
(for the moment I am just trying to get the name of the CurrentUser in the
Content part
I will set the Requestor once I get that part right)
I have tried
* new RT::CurrentUser( $session{'CurrentUser'} );
* new RT::CurrentUser;
* $session{'CurrentUser'}
* $Tickets{'TOP'}-CurrentUser
none of them seems to give me the expected result
(the first three return nothing, the last returns the SystemUser)
Can someone help me out ?
Thanks
Gerard
===Create-Ticket: new_patch_request
Queue: Patch Request
Subject: patch for RT { $Tickets{'TOP'}-Id() }
RefersTo: { $Tickets{'TOP'}-Id() }
CustomField-4: { $Tickets{'TOP'}-FirstCustomFieldValue( 'SW' ) ||
Unknown ; }
Content:
{ my $current_user = ? ;
$current_user-RealName if $current_user }
is requesting an official patch for ticket { $Tickets{'TOP'}-Id() }
(Subject: {
$Tickets{'TOP'}-Subject }).
ENDOFCONTENT
pgpupYvXsxLiz.pgp
Description: PGP signature
Re: [rt-users] Setting the Requestor to be the CurrentUser in a created ticket
Thanks
One more reason to switch to 3.8.9 then
Gerard
On 2011-05-31 17:39, Kevin Falcone wrote:
On Tue, May 31, 2011 at 05:32:35PM +0200, Gerard FENELON wrote:
Hello
I am creating tickets automatically when a CF is set to a specific value
I would like to to put the name of the User that changes the CF value in
the Content.
I would also like to set the Requestor of the new ticket to be the User
that changes the CF
value
I have been unable to find a way to do that (I searched the wiki)
Assuming a new enough RT (3.8.9 I think) you can use $TransactionObj
to get the CreatorObj of the transaction that triggered your Scrip.
That is the correct way to figure out who caused something.
-kevin
The (simplified) template to create that new ticket is below
(for the moment I am just trying to get the name of the CurrentUser in the
Content part
I will set the Requestor once I get that part right)
I have tried
* new RT::CurrentUser( $session{'CurrentUser'} );
* new RT::CurrentUser;
* $session{'CurrentUser'}
* $Tickets{'TOP'}-CurrentUser
none of them seems to give me the expected result
(the first three return nothing, the last returns the SystemUser)
Can someone help me out ?
Thanks
Gerard
===Create-Ticket: new_patch_request
Queue: Patch Request
Subject: patch for RT { $Tickets{'TOP'}-Id() }
RefersTo: { $Tickets{'TOP'}-Id() }
CustomField-4: { $Tickets{'TOP'}-FirstCustomFieldValue( 'SW' ) ||
Unknown ; }
Content:
{ my $current_user = ? ;
$current_user-RealName if $current_user }
is requesting an official patch for ticket { $Tickets{'TOP'}-Id() }
(Subject: {
$Tickets{'TOP'}-Subject }).
ENDOFCONTENT
Re: [rt-users] Adding/Removing/Rename Fields under Basics
Ronald, What is it you want to do? Kenn LBNL On Tue, May 31, 2011 at 2:26 AM, ronald higgins ronald.higg...@gmail.comwrote: Hi All, Under a given Ticket's Basic page there are a few fields such as Status, Queue, Owner, Time Worked, Time Estimated Time Left. Is it possible to add more fields to the Basic page or rename the Time Worked/Time Estimated/Time Left? Regards Ronald
Re: [rt-users] RT4 slowness
Just for the record I'm having the same issues as L.B. I attempted loading jsmin, and for a time it appeared that this was going to be a bigtime home run. In fact, it did fix the issues I was having with speed! However, jsmin seemed to also break several aspects of the RT interface. Immediately I noticed the javascript dropdowns were gone.. no big deal, switched to the ballard interface as the default. However, opening a new ticket.. everything was jumbled around... dropdowns were permanently opened, the minimize links for the different zones wouldn't work anymore.. it was generally a bad day. :( So I've turned it back off. This does however shed some light on what may be the cause of.. at least.. my speed issues. The search continues... On Tue, May 31, 2011 at 10:34 AM, Kevin Falcone falc...@bestpractical.comwrote: On Tue, May 31, 2011 at 03:21:17PM +0200, L B wrote: What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. You should only see this for the first request while things are squished. If you're seeing it for subsequent requests on a standalone server, then something is quite wrong. If you would like to use something faster than JavaScript::Minifier, you can check out JSMinPath in RT_Config.pm -kevin
Re: [rt-users] RT4 slowness
On Tue, May 31, 2011 at 12:56:46PM -0400, Chris Hall wrote: Just for the record I'm having the same issues as L.B. I attempted loading jsmin, and for a time it appeared that this was going to be a bigtime home run. In fact, it did fix the issues I was having with speed! However, jsmin seemed to also break several aspects of the RT interface. Immediately I noticed the javascript dropdowns were gone.. no big deal, switched to the ballard interface as the default. However, opening a new ticket.. everything was jumbled around... dropdowns were permanently opened, the minimize links for the different zones wouldn't work anymore.. it was generally a bad day. :( So I've turned it back off. This does however shed some light on what may be the cause of.. at least.. my speed issues. The search continues... RT only builds the squished css/js once per child process. If you're actually seeing it built on each request, something is horribly wrong and isn't something we've seen or been able to replicate. Also, if jsmin is breaking the UI, that's the first report I've seen of it. Can you file a bug report with more details? -kevin On Tue, May 31, 2011 at 10:34 AM, Kevin Falcone [1]falc...@bestpractical.com wrote: On Tue, May 31, 2011 at 03:21:17PM +0200, L B wrote: What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. You should only see this for the first request while things are squished. If you're seeing it for subsequent requests on a standalone server, then something is quite wrong. If you would like to use something faster than JavaScript::Minifier, you can check out JSMinPath in RT_Config.pm -kevin pgpQow8EBEEko.pgp Description: PGP signature
Re: [rt-users] RT4 slowness
Could you point me in the direction of where to file the bug report? I've just replicated this on another box I have set up as a test server.. so one was Debian, the other Ubuntu. In both cases, I downloaded jsmin from http://www.crockford.com/javascript/jsmin.c ran: gcc -o jsmin jsmin.c and copied the binary over to /usr/bin, and chmod +x /usr/bin/jsmin I then added the following line to RT_SiteConfig.pm Set( $JSMinPath, /usr/bin/jsmin); which resulted in no errors generated, BUT breaks the interface in the following way: (note the absence of menu at the top, and the always open dropdowns) http://i44.photobucket.com/albums/f45/nodaitsu25/jsmin.png On firefox you get the bonus of getting Links and Basics stacked together as well http://i44.photobucket.com/albums/f45/nodaitsu25/jsmin2.png On Tue, May 31, 2011 at 12:59 PM, Kevin Falcone falc...@bestpractical.comwrote: On Tue, May 31, 2011 at 12:56:46PM -0400, Chris Hall wrote: Just for the record I'm having the same issues as L.B. I attempted loading jsmin, and for a time it appeared that this was going to be a bigtime home run. In fact, it did fix the issues I was having with speed! However, jsmin seemed to also break several aspects of the RT interface. Immediately I noticed the javascript dropdowns were gone.. no big deal, switched to the ballard interface as the default. However, opening a new ticket.. everything was jumbled around... dropdowns were permanently opened, the minimize links for the different zones wouldn't work anymore.. it was generally a bad day. :( So I've turned it back off. This does however shed some light on what may be the cause of.. at least.. my speed issues. The search continues... RT only builds the squished css/js once per child process. If you're actually seeing it built on each request, something is horribly wrong and isn't something we've seen or been able to replicate. Also, if jsmin is breaking the UI, that's the first report I've seen of it. Can you file a bug report with more details? -kevin On Tue, May 31, 2011 at 10:34 AM, Kevin Falcone [1] falc...@bestpractical.com wrote: On Tue, May 31, 2011 at 03:21:17PM +0200, L B wrote: What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. You should only see this for the first request while things are squished. If you're seeing it for subsequent requests on a standalone server, then something is quite wrong. If you would like to use something faster than JavaScript::Minifier, you can check out JSMinPath in RT_Config.pm -kevin
Re: [rt-users] RT4 slowness
On Tue, May 31, 2011 at 01:24:07PM -0400, Chris Hall wrote: Could you point me in the direction of where to file the bug report? http://www.bestpractical.com/rt/issues.html has instructions for filing bug reports. -kevin I've just replicated this on another box I have set up as a test server.. so one was Debian, the other Ubuntu. In both cases, I downloaded jsmin from http://www.crockford.com/javascript/jsmin.c ran: gcc -o jsmin jsmin.c and copied the binary over to /usr/bin, and chmod +x /usr/bin/jsmin I then added the following line to RT_SiteConfig.pm Set( $JSMinPath, /usr/bin/jsmin); which resulted in no errors generated, BUT breaks the interface in the following way: (note the absence of menu at the top, and the always open dropdowns) http://i44.photobucket.com/albums/f45/nodaitsu25/jsmin.png On firefox you get the bonus of getting Links and Basics stacked together as well http://i44.photobucket.com/albums/f45/nodaitsu25/jsmin2.png On Tue, May 31, 2011 at 12:59 PM, Kevin Falcone falc...@bestpractical.comwrote: On Tue, May 31, 2011 at 12:56:46PM -0400, Chris Hall wrote: Just for the record I'm having the same issues as L.B. I attempted loading jsmin, and for a time it appeared that this was going to be a bigtime home run. In fact, it did fix the issues I was having with speed! However, jsmin seemed to also break several aspects of the RT interface. Immediately I noticed the javascript dropdowns were gone.. no big deal, switched to the ballard interface as the default. However, opening a new ticket.. everything was jumbled around... dropdowns were permanently opened, the minimize links for the different zones wouldn't work anymore.. it was generally a bad day. :( So I've turned it back off. This does however shed some light on what may be the cause of.. at least.. my speed issues. The search continues... RT only builds the squished css/js once per child process. If you're actually seeing it built on each request, something is horribly wrong and isn't something we've seen or been able to replicate. Also, if jsmin is breaking the UI, that's the first report I've seen of it. Can you file a bug report with more details? -kevin On Tue, May 31, 2011 at 10:34 AM, Kevin Falcone [1] falc...@bestpractical.com wrote: On Tue, May 31, 2011 at 03:21:17PM +0200, L B wrote: What I mean by slowness is that after sending the GET / request, it takes 7 seconds before seeing the second request /NoAuth/css/aileron-squished-30dddb4c81e92207bd3fe516099c0477.css. I don't have any network traffic during this 7secs on RT server network interface, so I guess something is processed. Httpd process is running at 100% at this time. You should only see this for the first request while things are squished. If you're seeing it for subsequent requests on a standalone server, then something is quite wrong. If you would like to use something faster than JavaScript::Minifier, you can check out JSMinPath in RT_Config.pm -kevin pgpIUVknoPkKm.pgp Description: PGP signature
[rt-users] Queries Sql
How can I tell how many comments had every ticket via sql queries? thanks in advance, Felipe BR -- A dúvida é o principio da sabedoria
Re: [rt-users] Queries Sql
On Tue, May 31, 2011 at 10:02 PM, Felipe Agnelli Barbosa
no.mo...@gmail.com wrote:
How can I tell how many comments had every ticket via sql queries?
SELECT t.id AS id, txn.Type AS type, COUNT(txn.id) AS counter
FROM Tickets t
LEFT JOIN Transactions txn
ON txn.ObjectType = 'RT::Ticket'
AND txn.ObjectId = t.id
AND txn.Type IN ('Create', 'Comment', 'Correspond')
GROUP BY t.id, txn.Type;
thanks in advance,
Felipe
BR
--
A dúvida é o principio da sabedoria
--
Best regards, Ruslan.
[rt-users] Errors from RT-Authen-ExternalAuth
Hello all, I'm getting errors from the LDAP connector every time someone logs in to RT from the Active Directory instance I'm plugged into. I have included a section here. The user authenticates and logs in but the server logs are filling up with this. Is this a sign of a larger problem? I'm running RT4 with the 0.09 version of the plug in. May 26 17:29:09 HOST RT: Use of uninitialized value in string eq at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm line 236. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:236) May 26 17:29:09 HOST RT: Use of uninitialized value in string eq at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm line 236. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:236) May 26 17:29:09 HOST RT: Use of uninitialized value in sprintf at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm line 534. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536) May 26 17:29:09 HOST RT: Use of uninitialized value in sprintf at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm line 534. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536) Thanks much.
Re: [rt-users] Errors from RT-Authen-ExternalAuth
On Tue, May 31, 2011 at 04:26:13PM -0700, Paul Muther wrote: I'm getting errors from the LDAP connector every time someone logs in to RT from the Active Directory instance I'm plugged into. I have included a section here. The user authenticates and logs in but the server logs are filling up with this. Is this a sign of a larger problem? I'm running RT4 with the 0.09 version of the plug in. These are warnings, not errors. I believe there has been a patch submitted to quiet some of them, but I'm not sure if it is in the repo yet. It is not in a release. -kevin May 26 17:29:09 HOST RT: Use of uninitialized value in string eq at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm line 236. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:236) May 26 17:29:09 HOST RT: Use of uninitialized value in string eq at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm line 236. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:236) May 26 17:29:09 HOST RT: Use of uninitialized value in sprintf at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm line 534. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536) May 26 17:29:09 HOST RT: Use of uninitialized value in sprintf at /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm line 534. (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536) Thanks much. pgphf2NWyPH1F.pgp Description: PGP signature
[rt-users] Ticket random creation error
Hi, My client have a strange problem on his 3.6.4 RT using Oracle 11g (on a separate server). Tickets fail to create randomly. It is not related to a specific queue, e-mail address or e-mail format. Not related to a specific user as well. The following errors show in rt.log: May 18 10:20:38 rt RT: Couldn't create a ticket: Object could not be created (/opt/rt3/lib/RT/Ticket_Overlay.pm:602) May 18 10:20:38 rt RT: Ticket could not be created due to an internal error (/opt/rt3/lib/RT/Interface/Email.pm:243) May 18 10:20:38 rt RT: Could not record email: Ticket creation failed: Ticket could not be created due to an internal error (/opt/rt3/share/html/REST/1.0/NoAuth/mail-gateway:75) The following shows in the Apache error log: [Mon May 16 13:24:53 2011] [error] [client 127.0.0.1] FastCGI: server /opt/rt3/bin/mason_handler.fcgi stderr: DBD::Oracle::st execute failed: ORA-01400: cannot insert NULL into (RT.TICKETS.OWNER) (DBD ERROR: error possibly near * indicator at char 225 in 'INSERT INTO Tickets (Status, Queue, Type, Started, Starts, id, LastUpdated, Subject, FinalPriority, Creator, Owner, LastUpdatedBy, Resolved, Created, Priority, Due) VALUES (:p1, :p2, :p3, :p4, :p5, :p6, :p7, :p8, :p9, :p10, :*p11, :p12, :p13, :p14, :p15, :p16)') [for Statement INSERT INTO Tickets (Status, Queue, Type, Started, Starts, id, LastUpdated, Subject, FinalPriority, Creator, Owner, LastUpdatedBy, Resolved, Created, Priority, Due) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) with ParamValues: :p5='1970-01-01 00:00:00', :p12='247803', :p8='FW: Testing tomorrow', :p14='2011-05-16 17:24:53', :p10='247803', :p13='1970-01-01 00:00:00', :p16='1970-01-01 00:00:00', :p2='21', :p3='ticket', :p6='93947', :p15=0, :p1='new', :p7='2011-05-16 17:24:53', :p4='1970-01-01 00:00:00', :p9='10', :p11=undef] at /usr/lib/perl5/site_perl/5.8.5/DBIx/SearchBu Note the ORA-01400: cannot insert NULL into (RT.TICKETS.OWNER) error. We found that RT seems to have problems getting the Nobody user ID from time to time. Using Wireshark to look at the communications between RT and Oracle, we see that sometimes the Nobody user ID is returned, sometimes not (most information are returned, except the user ID). We can also see that the query for that user ID is not always done, which makes me think there is some kind of caching. We were unable to find much more information regarding this problem. It seems to have gone away after a reboot... But for how long? I'd like to know if someone have seen that problem before? If so, did you find a solution, what was the problem? I'd like to have information about how RT works internally regarding getting the Nobody user ID and if there is some kind of caching. If so, for how long? Where? We appreciate all the help. Thanks! J-P
