What is AdminCc?

What does AdminCc mean, and how does it differ from Cc?
I’m just curious - my RT installation does what I want it to, but I’d
like to know why.
(Yes, I did RTFM, but couldn’t find anything.)

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

What does AdminCc mean, and how does it differ from Cc?
I’m just curious - my RT installation does what I want it to, but I’d
like to know why.

Well, it all depends on the scrips you set up. With these scrips,

OnCreate AutoreplyToRequestors with template Autoreply
OnCreate NotifyAdminCcs with template Transaction
OnCorrespond NotifyAllWatchers with template Correspondence
OnCorrespond NotifyOtherRecipients with template Correspondence
OnComment NotifyAdminCcsAsComment with template AdminComment
OnComment NotifyOtherRecipientsAsComment with template Correspondence

then AdminCcs get comments, but Ccs only get correspondance. We’re
using it locally so that you’ve got the following types of watchers:

Requestor: The person that opened the ticket, or the person that
should have but had someone else do it for them. (Always
a customer, in other words.)

   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.)

AdminCc: Our employees who want to see not only what the
requestor sees, but the internal stuff too – transactions
and comments-not-sent-to-requestor and so forth. (Never
a customer.) Read “Admin” as “Internal” if it helps.

But really you can use them for anything you want if you set up scrips
to do what you desire – I think the above captures the intent, though.

Oh, I just found what I wrote when someone within our organization
asked that. I said,

-------- cut here --------

Watchers are (essentially) people that get email about tickets.
Watchers can be added globally (all queues), per-queue, or per-ticket.
Right now, watchers can only be individual users, not groups. I expect
this to change.

There are three sorts of watchers:

  1. Requestors: People making the request to support/sysadmin/whoever.
    Requestors traditionally see only correspondence.

  2. 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.

  3. AdminCCs: People inside the organization that should see the public
    and private parts of the ticket (and in some queues every
    transaction.)

-------- cut here --------

Anyone have any quibbles with that bit between "cut here"s? If not,
I’ll add to it a bit and stick it in the manual.

Hope this helps,

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Thanks in advance.

Brad Shelton On Line Exchange http://www.ole.net
Phone: 313-961-7100 Fax: 313-961-7101

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Forgot which password? (Database? ‘root’? Your user?)

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Forgot which password? (Database? ‘root’? Your user?)

RT user for access to the databases.

Brad Shelton On Line Exchange http://www.ole.net
Phone: 313-961-7100 Fax: 313-961-7101

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Forgot which password? (Database? ‘root’? Your user?)

RT user for access to the database

Try talk with you database admin, He could change your rt password.
Other option is read the database manual.

Regards,

Daniel
Intelideas

Doesn’t this work?
/path/to/rt2/bin/rtadmin --user=root --password=“”

regards-----Original Message-----
From: Brad Shelton [mailto:bshelton-rtuser@online-isp.com]
Sent: Monday, May 20, 2002 6:01 AM
To: RT Users mailing list
Subject: Re: [rt-users] What is AdminCc?

On Sun, May 19, 2002 at 08:21:52PM -0400, Rich Lafferty wrote:

On Sun, May 19, 2002 at 06:24:18PM -0400, Brad Shelton (bshelton-rtuser@online-isp.com) wrote:

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Forgot which password? (Database? ‘root’? Your user?)

RT user for access to the databases.

Brad Shelton On Line Exchange http://www.ole.net
Phone: 313-961-7100 Fax: 313-961-7101

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

At 20:30 Uhr -0400 19.5.2002, Brad Shelton wrote:

Forgot which password? (Database? ‘root’? Your user?)

RT user for access to the databases.

Shouldn’t that be in config.pm?

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

-------- cut here --------

Watchers are (essentially) people that get email about tickets.
Watchers can be added globally (all queues), per-queue, or per-ticket.
Right now, watchers can only be individual users, not groups. I expect
this to change.

There are three sorts of watchers:

  1. Requestors: People making the request to support/sysadmin/whoever.
    Requestors traditionally see only correspondence.

  2. 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.

  3. AdminCCs: People inside the organization that should see the public
    and private parts of the ticket (and in some queues every
    transaction.)

-------- cut here --------

Anyone have any quibbles with that bit between "cut here"s? If not,
I’ll add to it a bit and stick it in the manual.

Well, since you asked for quibbles, the use of the word ‘partners’ is
probably rather specific to your organization.

-Robin

Robin Powell's Old Home Page BTW, I’m male, honest.
le datni cu djica le nu zifre .iku’i .oi le so’e datni cu to’e te pilno
je xlali – RLP http://www.lojban.org/

“V S R A, Prasad (Prasad)” wrote:

Doesn’t this work?
/path/to/rt2/bin/rtadmin --user=root --password=“”

regards

No. This changes the root user’s password within the RT system. But not the
database user’s password within the database system.

Depending on Your database, there are various ways of recovery. For MySQL it
can be found in the manual (or ask google).

Regards,
Harald

Harald WagenerAn der Alster 4220099 Hamburg*http://www.fcb-wilkens.com

Oops!
Should have read that carefully.
Here’s the one for mysql from mysql manual.

shell> mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD(‘new_password’)
→ WHERE user=‘root’;
mysql> FLUSH PRIVILEGES;

This is for user=root.
regards
-PrasadFrom: Harald Wagener [mailto:hwagener@hamburg.fcb.com]
Sent: Tuesday, May 21, 2002 2:32 PM
To: V S R A Prasad (Prasad)
Cc: Brad Shelton; RT Users mailing list
Subject: Re: [rt-users] What is AdminCc?

“V S R A, Prasad (Prasad)” wrote:

Doesn’t this work?
/path/to/rt2/bin/rtadmin --user=root --password=“”

regards

No. This changes the root user’s password within the RT system. But not the
database user’s password within the database system.

Depending on Your database, there are various ways of recovery. For MySQL it
can be found in the manual (or ask google).

Regards,
Harald

Harald WagenerAn der Alster 4220099 Hamburg*http://www.fcb-wilkens.com

I’m still running an old rt 1.07 and want to convert it to 2.x.

Forgot the password.

Anybody know how to help me off the hook?

I don’t want to lose the database of the old config.

Forgot which password? (Database? ‘root’? Your user?)

RT user for access to the databases.

Since you’re still running the old rt, I suspect the username and
password are stored in its configuration file. (I didn’t run 1.x,
so I’m not sure of the file’s name.)

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

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
watchers:

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
stuff.

Oh, I just found what I wrote when someone within our organization
asked that. I said,

-------- cut here --------

There are three sorts of watchers:

  1. 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.

  2. AdminCCs: People inside the organization that should see the
    public and private parts of the ticket (and in some queues every
    transaction.)

-------- 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
things.

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
that ticket.

(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
well enough.)

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.

Cheers.

Smylers
GBdirect