Greg Evans wrote: > Hey Mike, > > We don't really use the requestors field because the tickets don't get viewed > or looked at by anyone but myself and my boss. We don't want the replies to > go out to the customer, so we don't put their name in it or anything so > everything is set up so that the only 'requestor' is our support account. > Maybe it would be better for me to just turn off the function of emailing on > reply (I think that is it) and put the customers email address in the > requestors field and then do as you suggest?
In my experience of using RT on a small scale and then ramping it up, there are two things you should take into account when starting: 1. The system was carefully designed to function in a specific way with a specific logical structure. While it is possible to change the way it works and use it differently, you should always try to work within the original design, or you will be working against yourself and it will be ultimately self-defeating. 2. Start like you're starting with a very large system, otherwise you can create major problems for yourself when you start to grow the system later. Just because you only have one or two users, use it as if you had 300. Our internal support system started with two users, me and the boss. Then we integrated the rest of the company via LDAP and a new tech. support guy and now we are running at over 100 users. The only reason it works so well is that we went back on decisions made at the start because it was only for us, to make sure it remained scalable. If I can now apply the two points above to what you said about what you actually want it to do: "We don't want the replies to go out to the customer, so we don't put their name in it or anything so everything is set up so that the only 'requestor' is our support account." With regards to point 1, you don't want replies to go out to the customer, RT is designed to allow you to turn off this functionality at the click of a button, so rather than change the whole nature of the requestor object by assigning it as yourself, stay within RT's original design and just turn off the global scrip "On Correspond Notify Requestors and Ccs with template Correspondence". This will prevent the requestor or any CCs from being notified by e-mail about the tickets, but will allow you to correctly assign requestors and work with them as proper user objects. If you then find that you are not receiving e-mail yourself about tickets that you've created in someone else's name, the simple solution is to add yourself as an AdminCC for either individual tickets, or the whole queue and you will then get e-mails about everything someone else does on the ticket. With regards to point 2, having the support account be the requestor for every ticket is fine for now - but should the time come that you need to deal with more users, or more tickets, or expand your staff.. it's going to become difficult to deal with it and, if at the same time, you have change the design structure so that tickets are keeping information about users, but ticket requestors aren't the users etc.. it's going to end up completely unmanageable. The whole reason that RT is used world-wide by very large companies and very small companies alike is that it's design is perfect. It works for tiny systems and it works for massive systems, all you have to do is work with it and not against it. So, in short: Turn off the global scrip: "On Correspond Notify Requestors and Ccs with template Correspondence" Add extra information about users in USER custom fields. Add the users as requestors and then set the OWNER to be the person dealing with the ticket. Anyone that should get e-mails about any action on a queue that they themselves have not made should be an AdminCC for the queue, or they should be set as AdminCCs for individual tickets. Good luck. -- Kind Regards, __________________________________________________ Mike Peachey, IT Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 - Registered In England http://www.jennic.com __________________________________________________ _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com