I’m following along on “ItsFinallyInstalledNowWhat” and “Rights” wiki
entries and while the “Rights” has described something similar to what
we want to achieve, I’m not sure if it’s going to provide the kind of
client separation we want.
We provide IT support for a few dozen small businesses. Most of our
customers have a “point of contact” whom is responsible for handling
requests/issues internally before contacting us. This isn’t always
the case though: there’s a chance that a new employee or client may
need assistance before someone gets around to creating a user in RT.
Because of this, I’ve allowed Everyone to CreateTickets and
ReplyToTickets in my only queue I’ve created so far: Support.
I’d also like to implement SelfService, and allow Requestors to view
their own tickets; I don’t want them to be able to view any other
Requestor’s tickets. The SeeQueue permission is required for UI
options/actions, but would that also let them see the subject line
and/or Requestor of tickets in the queue that do not belong to them?
Secondly, I see through the AutogeneratedPassword wiki item that
there’s a method of generating a password and email it to them.
However, if I give them the ModifySelf permissions, would they then be
able to change their password? I’m also seeing that auto-created
users are done so as “Unprivileged”: 1) can I change this to
Privileged 2) is that bad thing, assuming I’m setting up permissions
as described herein?
For my company, I’m creating users for each technician and have
created/assigned them to a group called SupportTeam with TakeTickets,
StealTickets, DeleteTickets; I’m almost tempted to give all
technicians full control over it as there’s no trust issues between us
and I’m not concerned about foul play. Bad idea?
Finally, has anyone done any domain suffix matching for ticket viewing
permissions? i.e. firstname.lastname@example.org and email@example.com have ShowTicket and
ReplyToTicket rights for any ticket created by a Requestor’s email
Thanks in advance.