Wednesday, 23 October 2013

How to set up RT part 7: Useful bits and bobs

If you've made it this far, good on you. Personally, I wanted to punch RT in the face by this point, but you'll be pleased to hear you're just about done.

I added spamassassin to exim, but I don't think I did anything particularly creative with it, so I'll leave you to go research that bit elsewhere.

As I finished my installation and started to implement RT for our users, I came across lots of little bits and pieces that were not immediately obvious to me. Maybe they'll be obvious to you, in which case skip this post and go revel in the glory of having a working ticketing systems. If not, here's a brain dump of them.


Clearing the test database

You filled your database with users called "Ivor Bigun"? No worries, just drop the data and start again. 

# mysql -u root -p
# DROP DATABASE rtdb;
To remake it:
#rt-setup-database-4 --action init --dba root

List all users

The user list by default only shows priviledged users.
If you do “Find all users whose name matches %” this will list everyone who has “Let this user access RT” enabled.
If you do “Find all users whose name matches %” and tick “Include disabled users”, this will list all the users in the system, even those who have neither access nor rights granted.


Emailing tickets

When a ticket is created by email, the subject is set as the subject of the email.
When replying to a ticket by email, the subject must include a string along the lines of “[tickets.company.com #40]” but it doesn’t matter what else it contains, or which queue email address it is sent to, it will still be added to ticket #40.


Replying vs commenting

You can either reply to a ticket, or put a private comment on it. Just to make it extra obvious which of those you’re doing, the message box is RED for a public reply, and WHITE for a private comment.


Saved Searches

“RT System Saved Searches” are only available to super-users.


Deleting tickets

Only tickets that have ‘new’ status can be deleted - so if needs be, change the status first, and then delete.




Setting the default queue

In /usr/share/request-tracker4/html/Elements/SelectQueue , set the value $Default to the queue number (show in the UI).
NB the “New ticket in” quick create button on the homepage sets its own default as the first queue alphabetically that the user has rights to (via their group membership).


Using RT-crontool

Schedule automatic ticket actions using rt-crontool. For example, I want all of the tickets in the ‘projects@systems’ queue that have had no updates in two weeks (336 hours) to have their status changed to ‘stalled’.

rt-crontool   --search RT::Search::ActiveTicketsInQueue  --search-arg projects@systems  --condition RT::Condition::UntouchedInHours --condition-arg 336 --action RT::Action::SetStatus --action-arg stalled


Error: Message body not shown because it is too large

 
Edit /etc/request-tracker4/RT_SiteConfig.pm
Set($MaxInlineBody, 100000);


 Error: apache memory issues

 If a ticket is created by email but in the details of the ticket in the RT UI there is the error “Sending the previous mail has failed”, and in rt4.log there is the error “Could not send mail: Cannot allocate memory”, then make sure MaxRequestsPerChild in apache2.conf is not set to zero - this means processes never expire. I set this to a thousand.


Hacking the backend but don't see your changes implemented yet? 

Clear the cache with
rm -rf /var/cache/request-tracker4/mason_data/obj/*

That's it.
I hope some of that was useful to you. RT is probably too powerful for its own good, meaning it's quite hard to get off the ground, but is worth the effort.