[rt-users] Error on SetDue
Hi,
Please find below the Custom action clean up code for Seting DueDate based on a
condition:
use strict;
use warnings;
my $date1=$self-TicketObj-FirstCustomFieldValue('CI Valid Till');
my $date2=$self-TicketObj-FirstCustomFieldValue('Date In Gabriel');
my($mm1,$dd1,$1) = split /\//, $date1;
my($mm2,$dd2,$2) = split /\//, $date2;
my $duedate = $1.-.$mm1.-.$dd1. 00:00:00;
$self-TicketObj-SetDue( $duedate-ISO);
return 1;
Why is that the SetDue isnt working? Any help?
Regards,
Tony John
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
---
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@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] Error on SetDue
hi,
i don't know if it can help, but i don't use the -ISO on setDue.
$self-TicketObj-SetDue($duedate); // when $duedate = 2009--11-23
00:00:00;
maybe this can help,
regards,
On 23/11/2009 11:20, TONY JOHN - ERS, HCL Tech wrote:
Hi,
Please find below the Custom action clean up code for Seting DueDate
based on a condition:
use strict;
use warnings;
my $date1=$self-TicketObj-FirstCustomFieldValue('CI Valid Till');
my $date2=$self-TicketObj-FirstCustomFieldValue('Date In Gabriel');
my($mm1,$dd1,$1) = split /\//, $date1;
my($mm2,$dd2,$2) = split /\//, $date2;
my $duedate = $1.-.$mm1.-.$dd1. 00:00:00;
$self-TicketObj-SetDue( $duedate-ISO);
return 1;
Why is that the SetDue isnt working? Any help?
Regards,
Tony John
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
---
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] Speeding up CLI RT::Shredder
Hello, I'm in the same boat as many others I've seen post. We have 35k tickets in one of our queues that I'm trying to shred(shame on us for not automating this previously). I've found the web version of the Shredder to be god-awful slow. We're talking 10min+ just to shred ONE ticket. So I discovered the command-line /opt/rt3/sbin/rt-shredder utility. I was then able to shred ONE ticket in about 5 minutes. I found some optimization keys to add to the tables, which allowed me to them shred ONE ticket in about a minute. I then discovered(this really should be in the documentation!), that if you specify a timeframe with rt-shredder, you can get MUCH faster processing. I was able to get it down to 21seconds for the shredding of ONE ticket. I noticed it was spitting out warning messages each time it deletes something. I honestly do not care about the output as long as it is working as expected, so I hunted through the code and was able to disable the on-screen logging altogether. I'm now able to shred ONE ticket in about 8-10 seconds. For those who are interested in about a 50% reduction in processing time for the CLI Shredder, edit the file: /opt/rt3/lib/RT/Shredder/Rercord.pm Look for this line: $RT::Logger-warning( $msg ); Comment it so it looks like this: #$RT::Logger-warning( $msg ); a WORLD of difference from the 10 minutes per ticket I originally was getting. Now it looks like to shred the 35k might actually take a palatable amount of time. I wanted to share this useful information on the list so it is google searchable. I'm SURE others will find this helpful. BTW, the command I'm using to shred(again, documentation is kinda poor) is: ./rt-shredder --plugin Tickets=query,((status = 'deleted' OR status = 'rejected') AND LastUpdated='2008-10-03');limit,100;with_linked,FALSE;apply_query_to_linked,FALSE --force Max ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Error on SetDue
Tony,
We have a Custom Field called Need-By Date that we have the customer
fill out and we use that to set the Due Date of the ticket when they
create a ticket. It overrides the default due date timing set up for the
queue. This is the code we use:
#
# set new values for Due Date from CF Need-by-Date
#
my $trans = $self-TransactionObj;
my $ticket = $self-TicketObj;
my $cf_date = $ticket-FirstCustomFieldValue('Need-By Date');
# split up the date parts into a temporary array
my @parts = split(/[\/-]/, $cf_date);
# put date parts back together
my $new_date = sprintf(%d-%d-%d, $parts[2], $parts[0], $parts[1]);
# format new date based on RT
my $duedate = RT::Date-new($RT::SystemUser);
$duedate-Set(Format='unknown', Value=$new_date);
$ticket-SetDue($duedate-ISO);
return 1;
This works every time for us. Hope it helps.
Kenn
LBNL
On 11/23/2009 2:20 AM, TONY JOHN - ERS, HCL Tech wrote:
Hi,
Please find below the Custom action clean up code for Seting DueDate
based on a condition:
use strict;
use warnings;
my $date1=$self-TicketObj-FirstCustomFieldValue('CI Valid Till');
my $date2=$self-TicketObj-FirstCustomFieldValue('Date In Gabriel');
my($mm1,$dd1,$1) = split /\//, $date1;
my($mm2,$dd2,$2) = split /\//, $date2;
my $duedate = $1.-.$mm1.-.$dd1. 00:00:00;
$self-TicketObj-SetDue( $duedate-ISO);
return 1;
Why is that the SetDue isnt working? Any help?
Regards,
Tony John
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.
---
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@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] Speeding up CLI RT::Shredder
Oha, this sounds really useful. Any comment from ruslan if this is save? I have to shred several houndret thousend tickets from 2002-2007 and we need also around 2 minutes per ticket, will try it out tomorrow! Thanks for sharing this Torsten 2009/11/23 Maxwell A. Rathbone mrathb...@sagonet.com Hello, I'm in the same boat as many others I've seen post. We have 35k tickets in one of our queues that I'm trying to shred(shame on us for not automating this previously). I've found the web version of the Shredder to be god-awful slow. We're talking 10min+ just to shred ONE ticket. So I discovered the command-line /opt/rt3/sbin/rt-shredder utility. I was then able to shred ONE ticket in about 5 minutes. I found some optimization keys to add to the tables, which allowed me to them shred ONE ticket in about a minute. I then discovered(this really should be in the documentation!), that if you specify a timeframe with rt-shredder, you can get MUCH faster processing. I was able to get it down to 21seconds for the shredding of ONE ticket. I noticed it was spitting out warning messages each time it deletes something. I honestly do not care about the output as long as it is working as expected, so I hunted through the code and was able to disable the on-screen logging altogether. I'm now able to shred ONE ticket in about 8-10 seconds. For those who are interested in about a 50% reduction in processing time for the CLI Shredder, edit the file: /opt/rt3/lib/RT/Shredder/Rercord.pm Look for this line: $RT::Logger-warning( $msg ); Comment it so it looks like this: #$RT::Logger-warning( $msg ); a WORLD of difference from the 10 minutes per ticket I originally was getting. Now it looks like to shred the 35k might actually take a palatable amount of time. I wanted to share this useful information on the list so it is google searchable. I'm SURE others will find this helpful. BTW, the command I'm using to shred(again, documentation is kinda poor) is: ./rt-shredder --plugin Tickets=query,((status = 'deleted' OR status = 'rejected') AND LastUpdated='2008-10-03');limit,100;with_linked,FALSE;apply_query_to_linked,FALSE --force Max ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- MFG Torsten Brumm http://www.brumm.me http://www.elektrofeld.de ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Speeding up CLI RT::Shredder
I noticed a typo in probably the most important line in my message. The filename is actually: /opt/rt3/lib/RT/Shredder/Record.pm The line that I suggest to comment out, calls RT's built in Logger() function that basically just writes information either to the log or to the screen. As with anytime you modify defaults, I make no claims other than what it had for me. :) I'm actually seeing slightly better than 50% improvement with that line disabled/commented out. I hope others are able to confirm similar experiences. Look forward to reading about it. Max Torsten Brumm wrote: Oha, this sounds really useful. Any comment from ruslan if this is save? I have to shred several houndret thousend tickets from 2002-2007 and we need also around 2 minutes per ticket, will try it out tomorrow! Thanks for sharing this Torsten 2009/11/23 Maxwell A. Rathbone mrathb...@sagonet.com mailto:mrathb...@sagonet.com Hello, I'm in the same boat as many others I've seen post. We have 35k tickets in one of our queues that I'm trying to shred(shame on us for not automating this previously). I've found the web version of the Shredder to be god-awful slow. We're talking 10min+ just to shred ONE ticket. So I discovered the command-line /opt/rt3/sbin/rt-shredder utility. I was then able to shred ONE ticket in about 5 minutes. I found some optimization keys to add to the tables, which allowed me to them shred ONE ticket in about a minute. I then discovered(this really should be in the documentation!), that if you specify a timeframe with rt-shredder, you can get MUCH faster processing. I was able to get it down to 21seconds for the shredding of ONE ticket. I noticed it was spitting out warning messages each time it deletes something. I honestly do not care about the output as long as it is working as expected, so I hunted through the code and was able to disable the on-screen logging altogether. I'm now able to shred ONE ticket in about 8-10 seconds. For those who are interested in about a 50% reduction in processing time for the CLI Shredder, edit the file: /opt/rt3/lib/RT/Shredder/Rercord.pm Look for this line: $RT::Logger-warning( $msg ); Comment it so it looks like this: #$RT::Logger-warning( $msg ); a WORLD of difference from the 10 minutes per ticket I originally was getting. Now it looks like to shred the 35k might actually take a palatable amount of time. I wanted to share this useful information on the list so it is google searchable. I'm SURE others will find this helpful. BTW, the command I'm using to shred(again, documentation is kinda poor) is: ./rt-shredder --plugin Tickets=query,((status = 'deleted' OR status = 'rejected') AND LastUpdated='2008-10-03');limit,100;with_linked,FALSE;apply_query_to_linked,FALSE --force Max ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com mailto:sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- MFG Torsten Brumm http://www.brumm.me http://www.elektrofeld.de ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Scrip to remove requestors based on group membership
Hi,
have a look onto your code:
1. Condition:
==Condition==
my @exceptionGroups = ('no-reply');
my $principalobj = RT::Principal-new($RT::
SystemUser);
$principalobj-Load($self-TransactionObj-CreatorObj-Id);
my $transactionType = $self-TransactionObj-Type;
if ($transactionType eq 'Create') {
foreach (@exceptionGroups) {
my $groupobj = RT::Group-new($RT::SystemUser);
$groupobj-LoadUserDefinedGroup($_);
if ($groupobj-HasMemberRecursively($principalobj)) {
return 1;
}
}
}
return 0;
I think, if you use the default condition (OnCreate) and do the rest inside
a userdefined action, this will work.
Torsten
2009/11/20 darthmarth37 darthma...@gmail.com
I'm trying to write a scrip that removes the requestor of a new ticket
if the requestor's email address is in a specific no-reply group in
RT (for things like Nagios messages that don't need replies), and I
think I'm getting confused when trying to make it work. What I have
so far (below) doesn't have any effect on new tickets. Any ideas what
I'm messing up?
==Condition==
my @exceptionGroups = ('no-reply');
my $principalobj = RT::Principal-new($RT::SystemUser);
$principalobj-Load($self-TransactionObj-CreatorObj-Id);
my $transactionType = $self-TransactionObj-Type;
if ($transactionType eq 'Create') {
foreach (@exceptionGroups) {
my $groupobj = RT::Group-new($RT::SystemUser);
$groupobj-LoadUserDefinedGroup($_);
if ($groupobj-HasMemberRecursively($principalobj)) {
return 1;
}
}
}
return 0;
==Action==
my $principalobj = RT::Principal-new($RT::SystemUser);
$principalobj-Load($self-TransactionObj-CreatorObj-Id);
my ($status, $msg) = $self-TicketObj-DeleteWatcher(Type =
Requestor, PrincipalId = $principalobj);
return $status;
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
--
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sa...@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] Backup a queue question
Have a look onto RTx-Shredder at cpan, this will help you! Torsten 2009/11/9 PF phan...@gmail.com I need to backup everything in 2 queues but nothing else. I'm a database .. well I'm poor at it. I've looked through site:bestpractical.com (keywords) but not really found anything on single queues. Is this possible? If not I can take a full dump and delete all the queues but need assurances that the queues and tickets I delete are purged. Thanks for you help! ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- MFG Torsten Brumm http://www.brumm.me http://www.elektrofeld.de ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] [Rt-announce] 2010 RT Training Sessions
Best Practical Solutions provides unparalleled instruction in how to get the most out of RT. We've been teaching users and administrators how to get the most out of RT since 2001. Since 2003, we've offered intensive one-day RT administrator training sessions to the general public. 2010 will bring four different training sessions for RT, with training split across two days. The first day starts off with a tour of RT's web interface and continues with a detailed exploration and explanation of RT's functionality, workflows and configurability. We'll touch on basic administration, but concentrate largely on helping you and your team get the most out of your RT instance. The second day of training picks up with basic RT administration and covers everything from point-and-click configuration to installation of RT, development best practices and database tuning. It goes without saying that you'll get the most out of training if you attend both days of the course, but we've designed the material so that you can step out after the first day with a dramatically improved understanding of how to use RT or show up on the second day and get quickly up to speed on how to make RT do your bidding. A spot at either day costs $995 USD for US Training / 695 EUR for European Training. You can save 25% if you attend both days of training. That's just $1495 USD / 1042.50 EUR! If you reserve before January 20th for the San Francisco session, February 15th for the Dublin session, March 5th for the Boston session, or September 20th for the Washington DC session, you can save an additional 20% by mentioning the discount code ANNOUNCE10. If you buy online, we'll automatically apply the discount. Each class includes a morning snack, coffee/tea, and an afternoon snack, as well as all training materials. Day 1 - RT User Training This intensive day-long tutorial about RT starts with basic day-to-day use and continues with detailed training about advanced RT features including saved searches, dashboards, data analysis and options for automating your workflow. This session will cover: * The purpose and general use of RT * New features in RT 3.8 * Saved Searches and customizing searches * RT's Dashboards feature * Customizing RT's workflow to match your own * Automating common procedures * How to make simple custom reports based on RT's data * A short intro to RTFM, the RT FAQ Manager * General QA Session Day 2 - RT Administration and Development This intensive day-long session aimed at RT administrators and developers covers everything from installation to backups, interface and backend customizations. You'll learn how to customize RT to meet your organization's unique needs and how to make sure that RT stays fast, reliable and flexible. This session will cover: * New features in RT 3.8 RT's system architecture * A guided tour of the RT source code * Extension mechanisms you can use to customize RT * RT Installation, including the basics of Configuration * Examples of how to optimize RT for your organization * How to tie RT into your existing authentication infrastructure * Building your own tools that talk to the RT backend * Customizing RT's workflow to match your own * Automating common procedures * How to write custom reports based on RT's data * Custom coding, modifications, and callback creation * A brief preview of RT4 * General QA Session These sessions will be offered in: San Francisco, CA, USA - February 22 23 2010 Dublin, Ireland - March 15 16 2010 Boston, MA, USA - April 5 6 2010 Washington DC, USA - Oct 25 26 2010 If you can't make it to these cities, please drop us a line to request a public training in your area. We haven't yet scheduled training for 2011; your feedback will help us decide where to offer additional sessions. Private Training We also offer private training sessions tailored to your organization's needs. For more information about on-site training for your organization, please drop us a line at train...@bestpractical.com. Reservations We like to keep class sizes relatively intimate. Please register soon or we may not be able to guarantee you a seat. When you register, please tell us which date(s) you are registering for, and whether you'd like to register for the whole training session or for only a single day. If you'd like to pay via credit card, please visit Best Practical's online store at https://shop.bestpractical.com/ If you'd prefer to reserve a seat and have us bill you, please write to us at train...@bestpractical.com. Be sure to include the full names and email addresses of all attendees you'd like to register for training. -- Cassandra Phillips-Sears cassan...@bestpractical.com Office Manager Best Practical Solutions, LLC http://www.bestpractical.com ___
[rt-users] Tracking changes to queue structure
RT provides an excellent history log of all activities relating to a ticket. This provides an unchangeable record which auditors love when reviewing tickets. However we occasionally make changes to a queue such as adding a new custom field. This does not get filled in for historical tickets (too many) only new ones. When reviewing the old tickets auditors ask why the fields were not filled in correctly. We handle this by keeping a separate log of changes we make to queues and when they were made. My question is: does anyone else keep track of the changes they make to queues, and if so, how do you do it? Is there any way to do this within RT - I would love to do so but have no idea where to begin. thanks Gordon ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Tracking changes to queue structure
Gordon, RT has a Bulk Update feature which would allow you to add whatever value to specific Custom Fields on tickets in specific Queues as well as add comments to specific tickets in a queue. By specific, I mean whatever criteria you use for selecting the ticket you want to update. Kenn LBNL On 11/23/2009 3:01 PM, gor...@cryologic.com wrote: RT provides an excellent history log of all activities relating to a ticket. This provides an unchangeable record which auditors love when reviewing tickets. However we occasionally make changes to a queue such as adding a new custom field. This does not get filled in for historical tickets (too many) only new ones. When reviewing the old tickets auditors ask why the fields were not filled in correctly. We handle this by keeping a separate log of changes we make to queues and when they were made. My question is: does anyone else keep track of the changes they make to queues, and if so, how do you do it? Is there any way to do this within RT - I would love to do so but have no idea where to begin. thanks Gordon ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RT installed in a subdirectory (without a RT specific virtual host)
Hello all, this question appears in the archive but the suggested answer does not quite work; I am hoping some of you will be able to suggest solutions. My problem is that I am trying to install RT on an existing web server (Apache 2.x with mod_perl2 on Ubuntu8), in a sub-directory. I went through the configure/install steps, installing RT into /tools/pkgs/ rt-3.8.6. Now in trying to configure the web interface I hit various snags. Say my site is http://example.com; and I want RT to be at http://example.com/rt . I configured RT_SiteConfig and set WebPath to /rt. I changed /etc/ apache2/sites-enabled/000-default and added: Alias /rt /tools/pkg/rt/share/html Location /rt/ SetHandler perl-script PerlHandler RT::Mason /Location (where /tools/pkg/rt is a symlink to /tools/pkg/rt-3.8.6) The problem now is that I have to add: PerlRequire /tools/pkg/rt/bin/webmux.pl and according to some docs, also: PerlModule Apache::DBI These directives are permitted only at the global or server context, so given my sub-directory based RT setup (rather than a RT dedicated virtualhost) I have to add them to the top/global configuration. Or is there a way around? When I do add these to the global config, I still get errors: Can't locate /tools/pkg/rt/bin/webmux.pl in @INC (@INC contains: / tools/pkgs/rt/bin /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/ perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/ share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2) Apache/mod_perl config seems to restrict loading of PerlRequires from only @INC. I have started reading through the mod_perl docs to find out how to relax this, especially for an absolute path as above for webmux.pl. But perhaps someone here knows the way to fix this already? I would greatly appreciate any solutions or pointers to solutions for both issues above. Regards, --ravi ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Tracking changes to queue structure
Thanks Ken, I use this feature for some fields but others require information specific to a ticket (eg description of product design change). Also, reviewers of historical tickets can still ask the question: why wasn't the field filled in when the ticket was active? Gordon Ken Crocker wrote: Gordon, RT has a Bulk Update feature which would allow you to add whatever value to specific Custom Fields on tickets in specific Queues as well as add comments to specific tickets in a queue. By specific, I mean whatever criteria you use for selecting the ticket you want to update. Kenn LBNL On 11/23/2009 3:01 PM, gor...@cryologic.com wrote: RT provides an excellent history log of all activities relating to a ticket. This provides an unchangeable record which auditors love when reviewing tickets. However we occasionally make changes to a queue such as adding a new custom field. This does not get filled in for historical tickets (too many) only new ones. When reviewing the old tickets auditors ask why the fields were not filled in correctly. We handle this by keeping a separate log of changes we make to queues and when they were made. My question is: does anyone else keep track of the changes they make to queues, and if so, how do you do it? Is there any way to do this within RT - I would love to do so but have no idea where to begin. thanks Gordon ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Tracking changes to queue structure
On Tue, 24 Nov 2009 10:35:31 +1100, gor...@cryologic.com said: I use this feature for some fields but others require information specific to a ticket (eg description of product design change). Also, reviewers of historical tickets can still ask the question: why wasn't the field filled in when the ticket was active? I would do this: 1) Create the new custom field, and add any selection values to it that you'll need (if it's not a fill-in-the-blank type CF) 2) Also add a selection value of Field not available at time of ticket creation 3) Using Bulk Update, set that CF value to Field not available at time of ticket creation for all existing tickets 4) Go back to the custom field settings, delete the value Field not available at time of ticket creation as an option 5) Explain to the auditors that new fields are added every so often, and explain the procedure you went through to set that value, emphasizing that by removing that particular value as an option, users are unable to set any new ticket custom field to that value. That should hopefully be sufficient to satisfy everyone... ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Tracking changes to queue structure
Nice idea, I like it! thanks Gordon Nick Kartsioukas wrote: On Tue, 24 Nov 2009 10:35:31 +1100, gor...@cryologic.com said: I use this feature for some fields but others require information specific to a ticket (eg description of product design change). Also, reviewers of historical tickets can still ask the question: why wasn't the field filled in when the ticket was active? I would do this: 1) Create the new custom field, and add any selection values to it that you'll need (if it's not a fill-in-the-blank type CF) 2) Also add a selection value of Field not available at time of ticket creation 3) Using Bulk Update, set that CF value to Field not available at time of ticket creation for all existing tickets 4) Go back to the custom field settings, delete the value Field not available at time of ticket creation as an option 5) Explain to the auditors that new fields are added every so often, and explain the procedure you went through to set that value, emphasizing that by removing that particular value as an option, users are unable to set any new ticket custom field to that value. That should hopefully be sufficient to satisfy everyone... ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Is SQLite no longer supported?
I just checked RT out of git and ran: ./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite But the database type is set to 'mysql' in RT_Config.pm. What gives? The schema.SQLite file still exists. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Is SQLite no longer supported?
On Mon, Nov 23, 2009 at 10:33:16PM -0500, Todd Chapman wrote: I just checked RT out of git and ran: ./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite It helps if you don't misspell '--with-db-type' But the database type is set to 'mysql' in RT_Config.pm. What gives? The schema.SQLite file still exists. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] Is SQLite no longer supported?
On Mon, Nov 23, 2009 at 10:35 PM, Jesse Vincent je...@bestpractical.com wrote: On Mon, Nov 23, 2009 at 10:33:16PM -0500, Todd Chapman wrote: I just checked RT out of git and ran: ./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite It helps if you don't misspell '--with-db-type' Crap. Thanks Jesse! But the database type is set to 'mysql' in RT_Config.pm. What gives? The schema.SQLite file still exists. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Database upgrade failing 3.8.4 to 3.8.6
When upgrading from 3.8.4 to 3.8.6 I'm getting this error when running bin/rt-setup-database --dba rt_user --prompt-for-dba-password --action upgrade [Tue Nov 24 04:23:47 2009] [crit]: Can't locate RT/FM.pm in @INC (@INC contains: /root/rt-3.8.6/sbin/../local/lib /root/rt-3.8.6/sbin/../lib / usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/ site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/ 5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/ lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi / usr/lib/perl5/5.8.8 .) at /root/rt-3.8.6/sbin/../lib/RT.pm line 627, STDIN line 4. (/root/rt-3.8.6/sbin/../lib/RT.pm:377) Can't locate RT/FM.pm in @INC (@INC contains: /root/rt-3.8.6/sbin/../ local/lib /root/rt-3.8.6/sbin/../lib /usr/lib/perl5/site_perl/5.8.8/ i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/ site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi / usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/ perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /root/ rt-3.8.6/sbin/../lib/RT.pm line 627, STDIN line 4. I have an RT test system that is configured the same as this machine and the database upgrade went fine. I'm making sure to do this inside the rt-3.8.6 directory, and not in / opt/rt3 since /opt/rt3 does not have the necessary upgrade files inside etc. Any ideas? ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] QuickSearch Too Slow - rt-3.6.0
Hi, I am using RT v3.6.0 on RHEL AS 3 with Oracle 9i as the back-end database on a Pentium server with 1GB of RAM. This RT instance is hosting two business applications and there are close to 1200 queues on it. I am facing an issue with the QuickSearch widget on the RT web interface. It was too slow to load causing user login delays and sometimes it doesn't load at all. So I removed it from the RT at a glance page and made it available under a custom section I created on the left side menu. This addressed the login slowness issue much to the delight of most of the end users. However, some users who tend to use QuickSearch actively for getting an overview of ticket statistics on queues relevant to them complain that QuickSearch is too slow ;-) I am looking for some ways to quicken up (and to justify the nomenclature to the end users :) ) this widget. Any ideas/suggestions would be appreciated. Thanks. PS: I did a search in wiki and lists but didn't find a case matching the problem I am facing. That's why I am writing to this list. Regards, Umasankar P ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@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] QuickSearch Too Slow - rt-3.6.0
On Tue, Nov 24, 2009 at 01:01:39PM +0530, Umasankar Pandurangan wrote: Hi, I am using RT v3.6.0 on RHEL AS 3 with Oracle 9i as the back-end database on a Pentium server with 1GB of RAM. This RT instance is hosting two business applications and there are close to 1200 queues on it. I am facing an issue with the QuickSearch widget on the RT web interface. It was too slow to load causing user login delays and sometimes it doesn't load at all. So I removed it from the RT at a glance page and made it available under a custom section I created on the left side menu. This addressed the login slowness issue much to the delight of most of the end users. However, some users who tend to use QuickSearch actively for getting an overview of ticket statistics on queues relevant to them complain that QuickSearch is too slow ;-) I am looking for some ways to quicken up (and to justify the nomenclature to the end users :) ) this widget. Any ideas/suggestions would be appreciated. Thanks. PS: I did a search in wiki and lists but didn't find a case matching the problem I am facing. That's why I am writing to this list. Look here: http://www.gossamer-threads.com/lists/rt/users/75763?search_string=quicksearch%20slow;#75763 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
