Hi!
I’ve been nosing about the docs, but can’t find a solution to this:
We want to create a queue where a group of admins receive tickets. They then
assign those tickets to a group of sub-admins. The sub-admins should be
able to receive email notifying them of a new assigned ticket, work
on the ticket, be able to close/resolve (i.e. change status) the ticket
and make comments, BUT NOT be able to email the original requestor.
(we’ve had some incidents where overly-casual comments got back to the
customer)
I have created an admin group with the “normal” permissions:
ModifyTicket
OwnTicket
ShowTicket
ShowTicketComments
Watch
WatchAsAdminCc
(I also had to add these users to be watchers to receive mail)
And then a the sub-admin group with:
CommentOnTicket
Watch
ShowTicketComments
ShowTicket
OwnTicket
SeeQueue
CreateTicket
DeleteTicket
It looks like the sub-group can comment, and can’t reply to the requestor,
but
they DON’T receive email, and they can’t change the status of the ticket.
I have created an admin group with the “normal” permissions:
ModifyTicket
OwnTicket
ShowTicket
ShowTicketComments
Watch
WatchAsAdminCc
(I also had to add these users to be watchers to receive mail)
They probably want ReplyToTicket too.
And then a the sub-admin group with:
CommentOnTicket
Watch
ShowTicketComments
ShowTicket
OwnTicket
SeeQueue
CreateTicket
DeleteTicket
It looks like the sub-group can comment, and can’t reply to the requestor,
but
they DON’T receive email, and they can’t change the status of the ticket.
Give them ModifyTicket and assign them as queue watchers too.
Personally I’d probably set it up so that the Admin group only had
ReplyToTicket, and assign your “trusted” admins to both the admin
and sub-admin groups.
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
“…We want to create a queue where a group of admins receive tickets. They
then
assign those tickets to a group of sub-admins. The sub-admins should be
able to receive email notifying them of a new assigned ticket, work
on the ticket, be able to close/resolve (i.e. change status) the ticket
and make comments, BUT NOT be able to email the original requestor.
(we’ve had some incidents where overly-casual comments got back to the
customer)…”
Young, etc
What if you setup a queue with both of the mail aliases both pointing to
’queuename-comment’ rather than one pointing to ‘queuename’ and the other to
the corresponding ‘queuename-comment’ mail alias?
It would seem to me that unless a user/admin deliberately added a customer
email address to the CC: or adminCC: fields for a given ticket, that even
’Reply’ actions on a ticket would keep the email correspondence internal.
Moving resolved tickets to the higher-level queue, and scrubbing their history
thread of non-politically correct comments would then make it safe to use the
’Reply’ function.
I tried that, but I get a bounceback, as a comment requires a ticket-id to
work on.
It seems to me that there should be something other than simply
ModifyTicket…
it grants too many privileges. It would be nice to have ModifyTicketStatus
separate from ModifyTicket.-----Original Message-----
From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com]On Behalf Of Drew Mooney
Sent: Friday, September 27, 2002 1:14 PM
To: rt-users@lists.fsck.com
Subject: [rt-users] Permissions questions
Young Sul wrote:
“…We want to create a queue where a group of admins receive tickets. They
then
assign those tickets to a group of sub-admins. The sub-admins should be
able to receive email notifying them of a new assigned ticket, work
on the ticket, be able to close/resolve (i.e. change status) the ticket
and make comments, BUT NOT be able to email the original requestor.
(we’ve had some incidents where overly-casual comments got back to the
customer)…”
Young, etc
What if you setup a queue with both of the mail aliases both pointing to
‘queuename-comment’ rather than one pointing to ‘queuename’ and the other to
the corresponding ‘queuename-comment’ mail alias?
It would seem to me that unless a user/admin deliberately added a customer
email address to the CC: or adminCC: fields for a given ticket, that even
‘Reply’ actions on a ticket would keep the email correspondence internal.
Moving resolved tickets to the higher-level queue, and scrubbing their
history
thread of non-politically correct comments would then make it safe to use
the
‘Reply’ function.
setup email aliases admins and sub-admins and make them AdminCc
install OnOwnerChange script
setup AdminCc on comment use comment template
When the sub-admins converse and work on the ticket, just make sure
that the message is sent to the queue comment address only
(queuename-comment@aaa.com) ==> by default, it won’t email to the
requestors
This should do exactly what you describe below. The only thing is that
everyone (admins and sub-admins) will get the tickets. If you want only
admins to receive all the tickets and sub-admins only receive assigned
tickets, you can setup admins to AdminCc and instruct admins to add
sub-admins in AdminCc to the certain tickets when necessary.
Sherrill
[snip]
Young Sul wrote:
“…We want to create a queue where a group of admins receive tickets. They
then
assign those tickets to a group of sub-admins. The sub-admins should be
able to receive email notifying them of a new assigned ticket, work
on the ticket, be able to close/resolve (i.e. change status) the ticket
and make comments, BUT NOT be able to email the original requestor.
(we’ve had some incidents where overly-casual comments got back to the
customer)…”
[snip]
Sherrill (Pei-chih) Verbrugge
“The fear of the Lord is the beginning of knowledge” - Proverbs 1:7