Hi Alex, Comments inline.
On Tue, Sep 6, 2016 at 10:16 AM, Alex Hall <ah...@autodist.com> wrote: > 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 --------- RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training * Boston - October 24-26 * Los Angeles - Q1 2017
