Braam,
You could create a custom field that indicates which client the ticket
is for and then (this is the labor part) create a different notification
scrip for each client by using said custom field and have different
addressing logic for each notification scrip/client/group. Something
like what Gene wrote earlier:
".... Have your NotifySysadmins template send the notification e-mail to
the RT SysAdmins group. Something like this:
To: {
my $group = RT::Group->new( $RT::SystemUser );
$group->LoadUserDefinedGroup("clientsupportgroupA");
$OUT = $group->MemberEmailAddressesAsString; }
{ $Transaction->Content() } ....".
Hope this helps.
Kenn
LBNL
On 8/29/2007 7:52 AM, Braam van Heerden wrote:
Greetings,
I am a new RT user, evaluating it for use in our scenario, and my questions may
have been answered before, but unfortunately the ht://dig interface and the
wiki doesn't return anything useful. The ht://dig interface doesn't return any
results for me at all.
We want to set up RT to be used for support at a sister company. I have downloaded and installed
the RPM version (3.4.5-2). I have created a queue named "support" and gave the address
"[EMAIL PROTECTED]" to it. I have disable the automatic creation of users, we will only
be working with named contacts at the specific clients. Only they are allowed to submit support
tickets, either via email or on the portal.
We have for example,
- Client A
- Contact A.A
- Contact A.B
- Contact A.C
- Client B
- Contact B.A
- Contact B.B
- Contact B.C
Now, what we would like to do is the following:
1) A contact can open a ticket for that specific client either via email or via
the web interface.
2) The ticket must have a severity field that indicates the SLA clauses that
gets activated by the incident.
3) We have set up a Trac database to track development tickets. Either the
helpdesk personnel or the system will create a Trac ticket if it is deemed
necessary. Only pure support tickets will go into RT.
4) A client's contacts may not see tickets from other clients.
5) Clients may only see replies, not comments.
6) We would like all the contacts for a client to be automatically CC'ed
whenever any of them opens a ticket, and also have them CC'ed on the replies
(not comments). Therefore if Contact A.A logs an incident, Contact A.B and
Contact A.C is immediately CC'ed on this. However, none of Client B's contacts
may see the tickets.
My thoughts so far:
1) and 2) I have working perfectly already.
3) will be done either manually (not an issue for us), or I could try to write
a scrip to do that when a certain button is selected (still looking at the
available options here).
4) and 5) The permissions system seems to do separation well.
6) This is the major stumbling block for me. It appears I can make all the contacts CC'ed on all
tickets, but that would inform client B of the issues at client A. I then thought of creating two
separate queues, naming them e.g. "Support (Client A)" and "Support (Client
B)", with email addresses [EMAIL PROTECTED] and [EMAIL PROTECTED], but the management insists
on using a single email address. Also, multiple queues involve a lot of management when a new
client is added, or an old client no longer has a support agreement.
Has anyone done something like this before, that can give me some configuration
tips on how to achieve this in the best way possible?
Thanks :)
Braam van Heerden
Conversant Systems (Pty) Ltd
_______________________________________________
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
_______________________________________________
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
