Suppose I have a client who wants to nominate a manager to have oversight of the tickets their company creates. We manage all client tickets through one queue.
I have a group that includes all the people who should be notified about a ticket so I add that group to the ticket as a CC Watcher, and make sure that the manager is a member of the group.
Through the Self Service interface, their manager can now see all the tickets associated with that group (having set $SelfServiceShowGroupTickets).
Now, the manager no longer wishes to receive email for all the tickets, but does want to be able to see them.
Is it possible to define a Group as access only, not to be sent email?
As far as I can tell, this issue would be the same for privileged users too.
Many thanks,
Simon
A couple of options to try spring to mind:
a) Make a new group that has access to just this client’s tickets, and move the manager user to be in that group. You’ll need to remember to add this group to the client’s tickets if your one queue has a mixture of multiple client tickets in it (and if it does, have you considered separating the clients out into separate queues, even if you keep one queue as the incoming default one for new tickets?).
b) Create a new custom role (“Client Acme manager” for example) and assign that role to this user. Then you can add this role to client tickets on the People page in the same way you do with the built in Cc/AdminCc roles. The custom role won’t have any scrips associated with it, so won’t be sending any notifications, but you can grant rights to it.
c) We’ve hacked some of our test RTs so that they will only send email to a limited number of people on a list in the RT config, to stop accidentally spamming folk when trying things out. If you’re comfy coding you could do something similar, but the exact opposite - a list of people to never send anything to.
We’ve the same issue. All technicians should see the company’s tickets but only the one who opened and the address ‘it-department@acme.com’ should receive emails.
solution a) @GreenJimll mentioned is very easy and valid if you do not have many teams and many queues. You have to handle the customer’s queue at all teams. So If you have a queue for the support-team, a queue for the backend-team and another queue for the infrastructure-team they all have to handle the one (or three?) additional queues. Depends on your workflows on tickets.
We used this solution a couple of years for a maximum of two customers at same time. It was fiddly but it works and did the job.
solution c) is hard because you have to block only CC: and not To:. There will be rt-emails addressed to this person you want to be send out.
Solution b) is the thing we’re working on, but we’re still on 4.4.2 and we need the update first. Steps to do after update:
- Create a group an put in the customer’s technicians
- Create a Custom Role (like @GreenJimll wrote)
- Configure appropiate rights to this role
- Write a scrip ‘On Create’ that adds the required users or groups to the Custom Role role if one user in the technician’s group is requestor when opening a ticket
- Customize the code for SelfService to show the tickets depending on the Custom Role in addition