What does AdminCc mean, and how does it differ from Cc?
Well, it all depends on the scrips you set up.
Definitely. I think that should be emphasized in the docs – that
basically you can distinguish two groups of people and it’s up to you
in what distinction is useful to your organization.
We’re using it locally so that you’ve got the following types of
Cc: Other people who have some interest in seeing what the
requestor sees; maybe their VAR, maybe a coworker at their
site, or maybe the requestor said “Please reply to these two
addresses”. (Almost always a customer.)
For the latter case I just add the “these two addresses” as further
requestors, since from our point of view they don’t need distinguishing
from the first requestor and it ensures they get sent exactly the right
Oh, I just found what I wrote when someone within our organization
asked that. I said,
-------- cut here --------
There are three sorts of watchers:
CCs: People that aren’t the Requestor but who should see the
public part of the ticket by mail. Coworkers of partners,
partners who ask for replies to home and work addresses, etc.
AdminCCs: People inside the organization that should see the
public and private parts of the ticket (and in some queues every
-------- cut here --------
Anyone have any quibbles with that bit between "cut here"s?
Yes: I disagree with the public/private distinction being made in
general. I don’t disagree with the fact that you’ve made that
distinction in your case – it obviously works for you and no doubt will
for others – but I think it’s being overly prescriptive by suggesting
that the this is the purpose of the CC/AdminCC split.
When first browsing docs for investigating ‘RT’ several monthgs ago, I
got the impression that the ‘intention’ of the split was that all CCs
and AdminCCs are internal staff, and that they all receive copies of
both the public and private parts of tickets. The difference is that
that’s all CCs get (CCed stuff and can read it) and that only AdminCCs
can admin a ticket (make changes and the like). So the difference is on
permissions, not what who receives.
I suppose the above split would be useful in an organization where
managers or whoever feel the need to be kept informed of every thing
their team gets up to but shouldn’t actually have permission to change
We here use a different distinction again: for a public-facing queue we
have an entire team as CCs for the queue and only one person as AdminCC.
Our scrips are configured so that all CCs and AdminCCs get newly-created
tickets, but mail on existing tickets only goes to AdminCCs.
Basically this is so that we all get to see new enquiries (which since
we don’t know yet what they’re about, could be of interest to anybody)
but once a ticket is being dealt with, it only goes to interested
parties; if somebody other than the owner and the queue AdminCC needs to
know about a particular ticket, then he/she is added as an AdminCC of
(This means that being a CC of a ticket in our set-up is pointless; it
would never cause somebody to receive mail. Also we can’t use the
CC/AdminCC distinction for actually distinguishing people. But
fortunately we’re small enough for that not to matter. Possibly we
should achieve our current behaviour in some other way, but it works
I’m not trying to say that our way of doing things is right (or even
good), nor that my interpretation of the read-only/admin permission
difference is better than yours. Just that there are several ways of
using the difference, and that many of them don’t involve CCs not
getting internal-only mail, so I don’t think it’s helpful to describe
the distinction in that way.
Or at least, your wording may be a good way of describing an example
of a possible distinction but in a way that sounds less like it’s the
way that it’s ‘supposed’ to be done!
Hope that makes sense and I haven’t caused offence.