[rt-users] Change RT @ A Glance selection criteria
Hi there RT Users List. Is it possible for us to change the SQL query that is run for the RT at a glance front page that shows the last 10 unowned new tickets? With our RT Ticket count hovering around 4million the current query performs a complete table scan to sort the show the last 10 (filtered) so we would like to customize it more for our needs. Any pointers where to look for and modify this query? (We're on RT3.8.7). Regards Danie Brink Engineer : Open Source Systems -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Change RT @ A Glance selection criteria
On Thu, May 30, 2013 at 09:55:11AM +0200, Danie Brink wrote: Hi there RT Users List. Hi, Is it possible for us to change the SQL query that is run for the RT at a glance front page that shows the last 10 unowned new tickets? With our RT Ticket count hovering around 4million the current query performs a complete table scan to sort the show the last 10 (filtered) so we would like to customize it more for our needs. Any pointers where to look for and modify this query? (We're on RT3.8.7). log in as a super user to your RT, click on the Modify button on top right of 10 unowned tickets, then click on Savedsearch in front of You can also edit the predefined search itself. Modify your search criteria, then click on the right in SavedSearch on Update. -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 43 35 00 76 mailto:elac...@easter-eggs.com - http://www.easter-eggs.com -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Change RT @ A Glance selection criteria
Thank you so much for your pointer. That was exactly what we were looking for ! Danie On Thu, May 30, 2013 at 10:04 AM, Emmanuel Lacour elac...@easter-eggs.comwrote: On Thu, May 30, 2013 at 09:55:11AM +0200, Danie Brink wrote: Hi there RT Users List. Hi, Is it possible for us to change the SQL query that is run for the RT at a glance front page that shows the last 10 unowned new tickets? With our RT Ticket count hovering around 4million the current query performs a complete table scan to sort the show the last 10 (filtered) so we would like to customize it more for our needs. Any pointers where to look for and modify this query? (We're on RT3.8.7). log in as a super user to your RT, click on the Modify button on top right of 10 unowned tickets, then click on Savedsearch in front of You can also edit the predefined search itself. Modify your search criteria, then click on the right in SavedSearch on Update. -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 43 35 00 76 mailto:elac...@easter-eggs.com - http://www.easter-eggs.com -- RT Training in Seattle, June 19-20: http://bestpractical.com/training -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
[rt-users] 1 email address to control tickets on 2 different RT Servers
We currently have 2 RT servers on site, one running RT3 (ticket numbers 1-11,000) and another running RT4 (ticket numbers 15000+). We are planning to phase out the RT3 machine but in the mean time I want both RT machines to be accessed via the same email address as to hide this phase out from our users when the RT4 machine goes live Ideally I would like RT to divert all emails relating to ticket numbers between 1-14999 to our RT3 machine and anything above that to our RT4 machine. I would also like any new tickets to be created on the RT4 machine also Does anyone know of a way to get RT to behave in this way when using fetchmail? Any help would be greatly appreciated -- View this message in context: http://requesttracker.8502.n7.nabble.com/1-email-address-to-control-tickets-on-2-different-RT-Servers-tp54116.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
[rt-users] RT behavior when CCs are present in a ticket
Hi all, I have received a few complaints from users about a feature of RT. After a little experimenting, I find that those complaints are partially reasonable, so I want to share them with you and get some feedback. When RT receives an email that is bound to an already existing ticket, it notifies everyone in that ticket (requestor, CCs...). So far everything is good. Now picture this situation: Bill wants to send an email to Tom, CCing John and Jenny and RT (because he wants this conversation to remain recorded in the ticket's history). The mail is linked to an already existing ticket (i.e. the subject contains the magical tag). Bill is not the ticket's original requestor. Here comes the problem: Tom, John and Jenny will receive one email from Bill and another identical mail from RT. Even Bill will receive his email back from RT. Even worse, all this emails will look like it was the ticket owner who sent them. I think RT is being overzealous here: since RT already parses the email header looking for CCs, it should know that those messages are not useful, since those persons are already receiving the original email. So it should only notify people who are CCs for the ticket but are NOT included in the email sent from Bill. What do you think? Bye Cris p.s. This is happening on our production RT, which is still at 3.8.10. I don't know if RT 4 changed something in this respect. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] 1 email address to control tickets on 2 different RT Servers
On Thu, May 30, 2013 at 05:06:36AM -0700, scott.dalzell wrote: We currently have 2 RT servers on site, one running RT3 (ticket numbers 1-11,000) and another running RT4 (ticket numbers 15000+). We are planning to phase out the RT3 machine but in the mean time I want both RT machines to be accessed via the same email address as to hide this phase out from our users when the RT4 machine goes live Ideally I would like RT to divert all emails relating to ticket numbers between 1-14999 to our RT3 machine and anything above that to our RT4 machine. I would also like any new tickets to be created on the RT4 machine also Does anyone know of a way to get RT to behave in this way when using fetchmail? make fetchmail send mails to an smtp server with header filtering capacity (postfix) or to a script. Then make the smtp or the script parse the email subject at least and pipe the mail to the right rt-mailgate. -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 43 35 00 76 mailto:elac...@easter-eggs.com - http://www.easter-eggs.com -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RT behavior when CCs are present in a ticket
On Thu, May 30, 2013 at 12:04:39PM +, Guadagnino Cristiano wrote: Hi all, I have received a few complaints from users about a feature of RT. After a little experimenting, I find that those complaints are partially reasonable, so I want to share them with you and get some feedback. When RT receives an email that is bound to an already existing ticket, it notifies everyone in that ticket (requestor, CCs...). So far everything is good. Now picture this situation: Bill wants to send an email to Tom, CCing John and Jenny and RT (because he wants this conversation to remain recorded in the ticket's history). The mail is linked to an already existing ticket (i.e. the subject contains the magical tag). Bill is not the ticket's original requestor. Here comes the problem: Tom, John and Jenny will receive one email from Bill and another identical mail from RT. Even Bill will receive his email back from RT. Even worse, all this emails will look like it was the ticket owner who sent them. I think RT is being overzealous here: since RT already parses the email header looking for CCs, it should know that those messages are not useful, since those persons are already receiving the original email. So it should only notify people who are CCs for the ticket but are NOT included in the email sent from Bill. What do you think? Bye Cris p.s. This is happening on our production RT, which is still at 3.8.10. I don't know if RT 4 changed something in this respect. Hi Chris, RT's basic premise is that it is the issue management system and handles notifications and updates. If out-of-band additional CC's are done, they will get the CC and the RT update. That being said, you can add these checks yourself to the scrips that send the extra Email to not send them in this case. If you do, please put them on the wiki since that seems like useful functionality. Having worked with people using the same workflow, it resulted in RT missing updates should the updater forget to reply to RT resulting in missing history. They did much better when all they remembered was to just reply to the RT message only and it would handle the needed additional notifications. Regards, Ken -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RT behavior when CCs are present in a ticket
Hi Ken! - Messaggio originale - Da: k...@rice.edu k...@rice.edu Inviato: Thu May 30 2013 14:56:22 GMT+0200 (CEST) A: Guadagnino Cristiano guadagnino.cristi...@creval.it Oggetto: Re: [rt-users] RT behavior when CCs are present in a ticket Hi Chris, RT's basic premise is that it is the issue management system and handles notifications and updates. If out-of-band additional CC's are done, they will get the CC and the RT update. That being said, you can add these checks yourself to the scrips that send the extra Email to not send them in this case. If you do, please put them on the wiki since that seems like useful functionality. Having worked with people using the same workflow, it resulted in RT missing updates should the updater forget to reply to RT resulting in missing history. They did much better when all they remembered was to just reply to the RT message only and it would handle the needed additional notifications. Regards, Ken Ken, you're absolutely right. What you describe is exactly the type of workflow I've always been using (and suggesting): just reply to RT and let it take care of the rest. Indeed, at first I was surprised by the complaint. But then I realized that the described behavior is quite common when you're dealing with someone who doesn't know about RT at all. Perhaps I oversimplified the example, let's rework it this way: Bill sends an email to another user (originally not in the ticket CCs) and to RT to keep the history updated. The other user knows nothing about a ticketing system being in place. When this user replies, he hits reply all just to be sure. Now Bill receives two emails (one from the user and one from RT), and the external user receives his email back from RT. On the other hand, if the external user does not hit reply all but only replies to Bill, this reply won't be recorded into the ticket's history. I think (and you seem to agree) that the kind of behavior I suggested implementing would be a gain for everyone. I'll see if I can code it in a scrip, given my less-than-stellar perl abilities. Thank you! Bye Cris -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RT at a Glance error after upgrade from 4.011 to 4.0.12
trs, Your reply trigged a thought that I didn’t clear the mason cache after the upgrades. I just cleared the cache and now it is functioning correctly. Thank you for taking a deeper look into this issue, please accept my apology for the the extra hoops I put you through, I can chalk this one up to not clearing the cache after the upgrade on both the .12 and .13 upgrades If you would still like to me to do the data dumper for the MyRT.html, lmk Thanks again for taking the time to look into this issue. -- View this message in context: http://requesttracker.8502.n7.nabble.com/RT-at-a-Glance-error-after-upgrade-from-4-011-to-4-0-12-tp53829p54122.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] RT at a Glance error after upgrade from 4.011 to 4.0.12
On 05/30/2013 10:52 AM, Kevin wrote: trs, Your reply trigged a thought that I didn’t clear the mason cache after the upgrades. I just cleared the cache and now it is functioning correctly. Thank you for taking a deeper look into this issue, please accept my apology for the the extra hoops I put you through, I can chalk this one up to not clearing the cache after the upgrade on both the .12 and .13 upgrades If you would still like to me to do the data dumper for the MyRT.html, lmk Thanks again for taking the time to look into this issue. Glad it's resolved. I don't need the data dumper output. That's a likely scenario, I guess I ruled it out since a number of people reported it. :) -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Change RT @ A Glance selection criteria
On 05/30/2013 12:55 AM, Danie Brink wrote: Is it possible for us to change the SQL query that is run for the RT at a glance front page that shows the last 10 unowned new tickets? With our RT Ticket count hovering around 4million the current query performs a complete table scan to sort the show the last 10 (filtered) so we would like to customize it more for our needs. Any pointers where to look for and modify this query? (We're on RT3.8.7). I suspect you want the $UseSQLForACLChecks option: http://bestpractical.com/rt/docs/latest/RT_Config#UseSQLForACLChecks -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
[rt-users] Adding ReplyToTicket right to Requestor on Help queue failing
Hi All I am trying this and I do not the right gets added. use strict; use lib '/opt/rt3/lib'; use RT; use RT::Interface::CLI; use Data::Dumper; RT::LoadConfig(); RT::Init(); my $queue = RT::Queue-new( $RT::SystemUser ); my $group = RT::Group-new( $RT::SystemUser ); $queue-Load( 'Help' ); $group-LoadSystemRoleGroup( 'Requestor' ); $group-PrincipalObj-GrantRight( Object = $queue, Right = 'ReplyToTicket' ); What am I doing wrong? -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Adding ReplyToTicket right to Requestor on Help queue failing
You don't check any return value. On Fri, May 31, 2013 at 1:05 AM, Asif Iqbal vad...@gmail.com wrote: Hi All I am trying this and I do not the right gets added. use strict; use lib '/opt/rt3/lib'; use RT; use RT::Interface::CLI; use Data::Dumper; RT::LoadConfig(); RT::Init(); my $queue = RT::Queue-new( $RT::SystemUser ); my $group = RT::Group-new( $RT::SystemUser ); $queue-Load( 'Help' ); $group-LoadSystemRoleGroup( 'Requestor' ); $group-PrincipalObj-GrantRight( Object = $queue, Right = 'ReplyToTicket' ); What am I doing wrong? -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- RT Training in Seattle, June 19-20: http://bestpractical.com/training -- Best regards, Ruslan. -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] Adding ReplyToTicket right to Requestor on Help queue failing
On Thu, May 30, 2013 at 5:51 PM, Ruslan Zakirov r...@bestpractical.comwrote:
You don't check any return value.
added the check return and did not disclose any error
if (!$queue-Load( 'Help' )) {
die $@;
};
if (!$group-LoadSystemRoleGroup( 'Requestor' )){
die $@;
};
if (!$group-PrincipalObj-GrantRight( Object = $queue, Right =
'ShowTicket' )){
die $@;
};
Help Queue Group Rights still not adding Role Requestor with Right
ShowTicket
But then I realized I am using the wrong method.
I changed it to LoadQueueRoleGroup and it is working now.
replaced this
$group-LoadSystemRoleGroup( 'Requestor' );
with this
$group-LoadQueueRoleGroup( Queue = $queue-id, Type = 'Requestor' );
On Fri, May 31, 2013 at 1:05 AM, Asif Iqbal vad...@gmail.com wrote:
Hi All
I am trying this and I do not the right gets added.
use strict;
use lib '/opt/rt3/lib';
use RT;
use RT::Interface::CLI;
use Data::Dumper;
RT::LoadConfig();
RT::Init();
my $queue = RT::Queue-new( $RT::SystemUser );
my $group = RT::Group-new( $RT::SystemUser );
$queue-Load( 'Help' );
$group-LoadSystemRoleGroup( 'Requestor' );
$group-PrincipalObj-GrantRight( Object = $queue, Right =
'ReplyToTicket' );
What am I doing wrong?
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
RT Training in Seattle, June 19-20: http://bestpractical.com/training
--
Best regards, Ruslan.
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
RT Training in Seattle, June 19-20: http://bestpractical.com/training
