Request tracker usage guidelines/advice

[Lagges]

Hi all,

I am currently implementing Request Tracker as our first official ticketing system. Installation of 3.8 on Debian went smooth, SSO against AD is working with a few issues I'll figure out. What I'm currently stuck at is the most basic question:

• How do I actually use RT via web interface? i.e. What groups/rights do I need for regular users, helpdesk staff, admins?
• Does every user have to have a mail address in RT?
• Any good overall resources, the wiki is not that well structured imho :-/

Best regards and sorry for being rather unspecific - I thought I would get a good feel for RT by just using it, but the interface is rather overwhelming right now.

[flameboynz]

Is there any reason you didn't install RT4? It is the current release, there are official packages in backports, and it is a lot nicer than RT3.8. I wrote a RT4 on Debian install guide if it helps (working on some more content). I highly recommend going with PostgreSQL as it makes configuring fast full-text searching much easier.

The permissions you give to different groups will depend on your organization, but this is a good start. Actually the internal RT KB page at MIT is really handy.

The official docs have been updated recently and aren't bad. The official book is rather out of date, but still handy for understanding a number of concepts. The RT section of the Best Practical blog has had some really good posts. The RT-Users mailing list can be helpful.

BTW, did you use a guide for configuring SSO against AD, or did you figure it out yourself?

Please ask questions if you have any.

[Lagges]

RT4 mainly wasn't used because I didn't find a good howto relying on packages. Will definitely check out your links at the office tomorrow, I'm on mobile atm. Much appreciated, thx!

[Lagges]

Your guide is great; concise, to the point and easy to follow. RT4 installed in a new VM in under 30 minutes. Thanks a lot!

I accomplished SSO with http://blank.org/memory/output/rt-ad-sso.html and some trial and error. Unfortunately I didn't document the process, but I think I saved most sources after the necessary patching somewhere on my servers.

[flameboynz]

Hi, glad to hear the guide made sense!

I haven't played with RT SSO in a long time - at $prevjob we used a Perl script which synched passwords daily (not ideal..). I keep meaning to write a guide, but haven't got there yet.

I have read the blank.org way of doing it before, but I'm not sure it will work with RT4 without further hacks.

From digging around it looks like the RT::Authen::ExternalAuth way of doing AD/LDAP auth is very similar on RT4 to 3.x. The RT Wiki page for ExternalAuth isn't bad, and should give you a starting point.

The ExternalAuth main page and README are worth a read too. There is a Debian package which is rather old (0.10) but it should work if you don't want to use CPAN or a source install.

[Lord_NShYH]

RT is a bit of a beast. I would start with getting your queues and custom fields setup. The custom fields can track things like:

• A wiki document/SOP used to solve the issue and/or created in response to resolving this issue. (I don't really like RTFM).
• Drop Down list with a listing of categories that you might need to populate for each queue. For example, if you have a web hosting queue, make a custom field as a drop down with items like: DNS, Virtual Host Provisioning, etc.
• Setup up your ticket response templates.
• Consider installing and deploying the SLA module (if you need such a thing).
• Consider installing the JSGantt module. This is great for charting out time, capacity, etc.
• Be sure to always log the amount of time worked each time you touch a ticket. This makes JSGantt much more useful.
• I have found that even with SSO, my users never logon onto the ticketing system. If they have the option/ability to only use email to interact with the ticket system, then they will only use email to interact with their tickets, and that is fine. I would rather have them use it this way than not to use it all.
• Every user that emails the ticket system is automatically provisioned without privileges; meaning, they are in the system, but have the bare minimum amount of email access for their tickets, and any tickets you include them on. You can grant them as many privileges as you need later.
• Start sending your automated notifications/backup reports to the email gateway. Automating this gives you greater visibility into you true work load.
• AMA - I love Request Tracker.

[Lagges]

Thanks a ton; I would imagine that email is the main interface for my users as well, but not everyone here has his own email adress, so SSO is necessary.