[rt-users] RT Reporting / Charting

[Andrew Gray]

Has anyone worked on getting Top 'n' Reports out of RT or can point me in
the right direction?

It would be helpful to chart things like the top 10 or 20 Requestors of
tickets

Thanks,
Andrew
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] combine Correspond and Resolve scrips?

[Hubbard, Jason]

Hi Alex, I’m not sure how to resolve the first issue (probably some logic in 
the Correspondence scrip) but below will get rid of the “no content” message.

 

Replace $Transaction->Content() with the below in your templates to remove the 
no content message in emails.

 

 

 

{$Transaction->Content() eq 'This transaction appears to have no content' ?

'' :

$Transaction->Content();

}

 

 

 

From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Alex Peters
Sent: Wednesday, June 04, 2014 10:38 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] combine Correspond and Resolve scrips?

 

A default RT installation has scrips to send correspondence to requestors, and 
to send an email to requestors indicating that their ticket has been resolved.

 

I'd like to combine the two in a way such that the "resolution" email also 
includes the correspondence entered as part of the resolving transaction.

 

To achieve this, I have modified the "Resolved" template to also contain the 
transaction's content.

 

This works as desired with two exceptions:

1.  Hitting Resolve in the RT web interface, changing Comment to 
Correspond, typing a message and submitting results in two emails being sent to 
the requestor: one with just the correspondence, and another with the 
"resolved" message and the same correspondence.  I'd prefer only one email to 
be sent.
 
2.  When resolving a ticket without comment, the "resolved" email is sent 
containing the message "this transaction appears to have no content," which I'd 
like to avoid.

Essentially I guess I want to do these two things:

1.  Make the Correspond scrip only fire if the transaction (or transaction 
batch?) isn't also resolving or rejecting the ticket.
 
2.  Modify the Resolved template to not output the "appears to have no 
content" message if the transaction (batch?) doesn't include a correspondence 
element.

What is the most appropriate way to do these?  Can it all be achieved using 
scrips and templates alone?

 

I suppose one option might be to place a conditional "does transaction (batch?) 
include ticket resolution" element into the Correspondence template and remove 
the Resolved template altogether, but if it is, I'm not entirely sure how to 
implement this.

 

Clarification on whether corresponding and resolving at the same time is 
considered a single transaction or a batch would also be gratefully received.


--This
 message contains information that may be confidential and proprietary.  Unless 
you are the intended recipient (or authorized to receive this message for the 
intended recipient), you may not use, copy, disseminate or disclose to anyone 
the message or any information contained in the message.  If you have received 
the message in error, please advise the sender by reply e-mail, and delete the 
message immediately.
==
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT Database pruning before moving to new server

[Lists]

Thanks Kevin, this may do the trick.  Still being new to RT, I missed this.


On 6/5/2014 11:27 AM, Kevin Falcone wrote:

I'm interested to hear from everyone too, as one of these days I hope to drop 
out some unnecessary attachments from the database.
One thing that I found in our environment is that the sessions table was 
absolutely huge and accounted for more than 80% of our database size.

Standard response:
http://bestpractical.com/docs/rt/latest/rt-shredder.html


You can use the sbin/rt-clean-sessions script to help prune that if you find 
that your sessions table is also very large.

This should be a daily cron job on every production RT server,
otherwise your session table just grows without bounds.


Our current RT3 database is over 18 gigs and I was told that our
admins have never pruned or purged any of the old data. Are there
any utilities or scripts in RT that I can use to purge old data
cleanly or is all of that done directly through the database, ie
mysql in my case?

Look at the shredder docs above.

Make sure you apply the documented indexes.  You may find that
shredder performs better on 4.2 than on 3.8, test.

-kevin




--
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT Database pruning before moving to new server

[Lists]

On my current production system it looks like the majority of the space 
is being taken up by the attachments table and then the sessions table.


+---+---++---++-+
| CONCAT(table_schema, '.', table_name) | rows  | DATA   | idx   | 
total_size | idxfrac |

+---+---++---++-+
| rt3.Attachments   | 3.91M | 14.32G | 0.10G | 
14.42G |0.01 |
| rt3.sessions  | 0.16M | 2.26G  | 0.01G | 
2.27G  |0.00 |


So I guess I need a query to delete any attachments that I no longer 
need.  I am guessing it would be any attachments (and associated 
resolved tickets) past a certain date.


Unfortunately we do not have a data retention policy in place so we have 
at least 6 or 7 years worth of closed tickets in the database.


On 6/5/2014 10:04 AM, Parish, Brent wrote:

I'm interested to hear from everyone too, as one of these days I hope to drop 
out some unnecessary attachments from the database.

One thing that I found in our environment is that the sessions table was 
absolutely huge and accounted for more than 80% of our database size.

You can use the sbin/rt-clean-sessions script to help prune that if you find 
that your sessions table is also very large.

If you are migrating to another database server, you can also leave out the 
sessions table.
For example, with MySQL:
mysqldump -u$RootDBuser -p$RootDBpassword -h$DBhost rt4 --ignore-table 
rt4.sessions > db_backup.sql
(or just truncate it after importing into the new server)

- Brent



-Original Message-
From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Lists
Sent: Wednesday, June 04, 2014 8:21 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT Database pruning before moving to new server

Hi,

I am new to the RT lists as well as new to the administration of the RT 
product.  My company has used RT for many years but was maintained by another 
admin.

I have been asked to upgrade our RT system from version 3.8.1 running on CentOS 
5.9 to version 4.2.4 running on CentOS 6.5.

Our current RT3 database is over 18 gigs and I was told that our admins have 
never pruned or purged any of the old data.  Are there any utilities or scripts 
in RT that I can use to purge old data cleanly or is all of that done directly 
through the database, ie mysql in my case?

Thanks,

Dave
--
RT Training - Boston, September 9-10
http://bestpractical.com/training





--
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT Database pruning before moving to new server

[Kevin Falcone]

> I'm interested to hear from everyone too, as one of these days I hope to drop 
> out some unnecessary attachments from the database.
> One thing that I found in our environment is that the sessions table was 
> absolutely huge and accounted for more than 80% of our database size.

Standard response:
http://bestpractical.com/docs/rt/latest/rt-shredder.html

> You can use the sbin/rt-clean-sessions script to help prune that if you find 
> that your sessions table is also very large.

This should be a daily cron job on every production RT server,
otherwise your session table just grows without bounds.

> Our current RT3 database is over 18 gigs and I was told that our
> admins have never pruned or purged any of the old data. Are there
> any utilities or scripts in RT that I can use to purge old data
> cleanly or is all of that done directly through the database, ie
> mysql in my case?

Look at the shredder docs above.

Make sure you apply the documented indexes.  You may find that
shredder performs better on 4.2 than on 3.8, test.

-kevin


pgpemzE_49Xw9.pgp
Description: PGP signature
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] RT Database pruning before moving to new server

[Parish, Brent]

I'm interested to hear from everyone too, as one of these days I hope to drop 
out some unnecessary attachments from the database.

One thing that I found in our environment is that the sessions table was 
absolutely huge and accounted for more than 80% of our database size.

You can use the sbin/rt-clean-sessions script to help prune that if you find 
that your sessions table is also very large.

If you are migrating to another database server, you can also leave out the 
sessions table.  
For example, with MySQL:
mysqldump -u$RootDBuser -p$RootDBpassword -h$DBhost rt4 --ignore-table 
rt4.sessions > db_backup.sql
(or just truncate it after importing into the new server)

- Brent



-Original Message-
From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Lists
Sent: Wednesday, June 04, 2014 8:21 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT Database pruning before moving to new server

Hi,

I am new to the RT lists as well as new to the administration of the RT 
product.  My company has used RT for many years but was maintained by another 
admin.

I have been asked to upgrade our RT system from version 3.8.1 running on CentOS 
5.9 to version 4.2.4 running on CentOS 6.5.

Our current RT3 database is over 18 gigs and I was told that our admins have 
never pruned or purged any of the old data.  Are there any utilities or scripts 
in RT that I can use to purge old data cleanly or is all of that done directly 
through the database, ie mysql in my case?

Thanks,

Dave
--
RT Training - Boston, September 9-10
http://bestpractical.com/training
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Why are Asset #'s so naked?

[Gustavo Gasparrini]

Hi, Al.

We made some changes to the Create Ticket form, where you can search assets by 
name or description, filtered by a Status (you have to put which Status to 
filter in a variable in RT_SiteConfig.pm file) and a Catalog that have to have 
the same name than the queue.
If you want, I can send it to you, but without any warranty, because we need to 
normalize the development.
I can send you the files that you have to replace for a specific RT version. 
They are only 3 files.

Regards,
Gustavo


Gustavo Gasparrini | NIXE S.R.L. 
IT Systems General Manager 
+54(11)4383-7831 
http://www.nixe.com 

- Mensaje original -
De: "Kevin Falcone" 
Para: rt-users@lists.bestpractical.com
Enviados: Jueves, 22 de Mayo 2014 17:29:50
Asunto: Re: [rt-users] Why are Asset #'s so naked?

On Sun, May 18, 2014 at 11:47:43PM -0400, Al Joslin wrote:
>   Why in the world am I required to know an Asset's Number in
>   order to use/link it ? Why are there no searching options that
>   result in linkage ? Why do I have to find the Asset, write it's
>   number on a sticky note and then go to another screen where I
>   then enter that number ? I would love to get the FindAsset
>   portlet into the Ticket/Create.html -- but there seems to be no
>   option for that in the RT_Config.

I believe most people using it are navigating to the Asset and then
using Action -> Create linked ticket.

I suspect you also want to set AssetQueues
http://bestpractical.com/docs/assets/1.01/Assets_Config.html#AssetQueues

-kevin

-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training

Re: [rt-users] Problems with ! in html format emails

[Kevin Curtis]

Hi Jason,
Thanks for the response.  The "!" characters are being inserted (with a 
space as well) by sendmail.  Is that the MTA that you are using?

I kind of agree that that it could be a configuration issue somewhere, but the 
"where" is difficult to track down.  Everything looks ok.

We have two other problems that I haven't seen any reference to either in the 
mailing list:

1)  Inline images not displayed in emails sent out by rt, because they had 
been converted to text

2)  Not being able to make an attachment when replying to correspondence 
through the GUI

All of these things are pretty noticeable, so it must be something unique with 
our installation.

It has been quite a frustrating few weeks.


Regards

Kevin

From: Hubbard, Jason [mailto:jason.hubb...@circles.com]
Sent: 04 June 2014 19:38
To: Kevin Curtis; rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Problems with ! in html format emails

Hi Kevin, it sounds like you have an issue with your Outlook client 
configuration, maybe a standard signature your company uses or some 
configuration pushed by GP or your build is causing it.  We use Outlook as our 
mail client and HTML is our standard format.  We have never seen any issues 
like this.


From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Kevin Curtis
Sent: Wednesday, June 04, 2014 11:54 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Problems with ! in html format emails

Hi,
In case anyone else comes across this same problem (and I can't see why we 
should be the only users affected, I am sure that other RT installations must 
be processing emails from MS Office Outlook clients!), I have solved the issue 
for out particular case.

If this is a real problem it would be nice to have the fix in a future release 
of RT, so should I report it as a bug?

In the end I incorporated the solution into RescueOutlook as follows:

sub RescueOutlook {
my $self = shift;
my $mime = $self->Entity();

return unless $mime && $self->LooksLikeMSEmail($mime);

my $text_part;
my $html_part;
my $retval = 0;

my $tmp = $mime->head->get('Content-Type');
$RT::Logger->debug("Header content type $tmp");

if ( $mime->head->get('Content-Type') =~ m{multipart/related} ) {
$RT::Logger->debug("processing multipart/related");
my $first = $mime->parts(0);
  $tmp = $first->head->get('Content-Type');
$RT::Logger->debug($tmp);

if ( $first->head->get('Content-Type') =~ m{multipart/alternative} )
{
$RT::Logger->debug("processing related/alternative");
my $inner_first = $first->parts(0);
if ( $inner_first->head->get('Content-Type') =~ m{text/plain} )
{
$RT::Logger->debug("releated/alternative/plain");
$text_part = $inner_first;
}
$inner_first = $first->parts(1);
if ( $inner_first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("releated/alternative/html");
$html_part = $inner_first;
}
}
}
elsif ( $mime->head->get('Content-Type') =~ m{multipart/mixed} ) {
$RT::Logger->debug("processing multipart/mixed");
my $first = $mime->parts(0);
if ( $first->head->get('Content-Type') =~ m{multipart/alternative} )
{
$RT::Logger->debug("processing multipart/alternative");
my $inner_first = $first->parts(0);
if ( $inner_first->head->get('Content-Type') =~ m{text/plain} )
{
$RT::Logger->debug("mixex/alternative/plain");
$text_part = $inner_first;
}
$inner_first = $first->parts(1);
if ( $inner_first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("multipart/alternative/html");
$html_part = $inner_first;
}
}
}
elsif ( $mime->head->get('Content-Type') =~ m{multipart/alternative} ) {
my $first = $mime->parts(0);
if ( $first->head->get('Content-Type') =~ m{text/plain} ) {
$RT::Logger->debug("alternative/plain");
$text_part = $first;
}
  $first = $mime->parts(1);
if ( $first->head->get('Content-Type') =~ m{text/html} )
{
$RT::Logger->debug("alternative/html");
$html_part = $first;
}
}

# Add base64 since we've seen examples of double newlines with
# this type too. Need an example of a multi-part base64 to
# handle that permutation if it exists.
elsif ( $mime->head->get('Content-Transfer-Encoding') =~ m{base64} ) {
$text_part = $mime;# Assuming single part, already decoded.
}

if ($text_part) {
# use the unencoded string
my $content = $text_part->bodyhandle->as_string