Hi Alex,
Comments inline.
Hi all,
RT is working well, sending and receiving email, which is wonderful
news–thanks again for all the help. What I’m wondering is how emailed
tickets work in terms of users.
If I email in a ticket from the address I have registered with my RT
account, that works fine. I just had a coworker do the same, and it again
worked. This coworker, though, has no account at all on RT. What is he now?
Email that comes into RT that has no previously created user
associated with the email address is from the special group Everyone.
Once they
A user?
Sort of. They exist in the users table, but do not have a username -
the field in the table is called, “name”.
A ticket holder, but with no permanence in RT aside from that email
address?
They would be the requestor of the ticket. There really isn’t a
“ticket holder” - just the different roles that are associated with
tickets. Requestors, Ccs, AdminCcs, Owner, etc.
He’s not in the list of users, so he must not “officially” exist,
but where is he?
There are different config settings to control what users get
displayed with autocomplete.
If I were to go in right now and add him, with that same
email address, as a user, would his ticket show as being on behalf of him,
the new user?
I don’t see evidence in the DB schema, but I believe the email address
is unique per user.
The way our company works, my boss won’t want any old user submitting
tickets. He wants this to be internal for the most part, so I imagine he’ll
want me to make it so only registered users can send emails that open
tickets. Is there a way to do this?
Grant rights. There are a few different ways to attack this.
Don’t grant create ticket (or reply to ticket, or etc.) to Everybody.
This will close the loop of unknown users being able to send email to
the system and have tickets created and those email addresses show up
in the users table.
Create users in your system that you want to be able to “do stuff”.
These would be the employees of the company. Then grant rights to
those users. You could make those users privileged and then use the
special group Privileged to make life easier.
Or leave the users as unprivileged and grant rights to the
Unprivileged group. Priv vs Unpriv will dictate what interface (Full
UI vs SelfService UI) the users will see via the web interface.
Depending on what level of interaction you want the general audience
to have will drive whether you make them priv or unpriv.
That is, a way to only accept emails
where the sender’s address is already attached to an active user?
Explained above.
-m