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.
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.
“RT System Saved Searches” are only available to super-users.
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).
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.pmSet($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/*
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.