Hi,
We would like to know if it is possible to have a user that can login and view all the tickets related to their domain.
user : superuser@domain.xyz
can sell and query all tickets opened by someone@domain.xyz
These tickets are opened in by example “General”
They might move to another queue “Develpment” or “Testing”, etc
They would be an unprivileged user that would only see correspondance and not user comments, user actions and/or anything else.
Thanks in advance.
G.
Not directly.
I’ve seen one or two solutions where you can add users to groups. You’d need some scripting/scrip perhaps to add new users to particular groups based on domains. (Or just manually set it when you create the user.)
There’s some new group stuff in RT5’s Self Service pages which might help.
As far as I can tell, RT’s permission structure doesn’t allow for groups to be set as Requestors or Roles within tickets. Groups only apply to other things like Queues and not tickets. (So if each customer had their own queue, that could work, but that’s maybe not how you want to organise things.)
Some time ago Craig_Ringer created an extension RT::Extension::CustomerGroups which might do what you need. I could not get this to install on my Debian+RT (I think it’s probably a path issue as Debian doesn’t install RT into the location it is expecting, and the install script doesn’t seem to be able to find RT.pm etc in the expected locations.)
Perhaps this is fixable or if you have installed into the default (not debian package) locations, maybe it’ll install okay for you.
R.
RT definetly allows groups to be a requestor or any other role on a ticket ( Except owner )
Hmm. Interesting! I tried to do it in the web interface, and it seems to want an email address in that field, when adding someone as a role, so it doesn’t find the group.
Now I looked again, and there is another part called “Find groups whose” which allows the group to be added. I had thought that this just finds users within the groups to be added as watchers, not add the group itself as a role.
So it would seem the solution is to script something that adds users to the appropriate group by domain, (or just manually set the group when the user is added) and then add a scrip or similar so that when a new ticket is created / correspondence arrives, find the appropriate customer group and set this as a role (e.g. Requestor) in the ticket, if it is not already set.
Not sure how that works in the Self Service pages. Presumably users need to be granted rights and the appropriate group set so it’ll show all tickets for their group?
Auto-created users are not privileged by default in our system at least, but would they need to be allowed to be granted rights in order for this to work?
Emails can be easily spoofed, so you’d have to be a bit careful depending on the setup, that users were not just free to send an email from the domain, and then login to RT and see all the tickets, but presumably the process to set the password involves admin anyway (or I think there’s an extension to allow users to recover the password?)
R.
I think a scrip makes sense or just some manual workflow.
For self service being able to see their group tickets, RT 5 now has this feature:
https://docs.bestpractical.com/rt/5.0.1/RT_Config.html#SelfServiceShowGroupTickets
The extension for allowing users to reset a their password is this one:
Thank you for the suggestion.
I’m understanding no one else really has this as a need?
This extension looks like it’s from 2013 - not sure if it will work with RT5.
Yes. If you are using RT5 which has the new groups functionality in the self-service pages, then I would look to use that instead, and either manually put users into the appropriate customer group, or some script which looks up the domain somewhere and determines which group the user should belong to.
You may have to be careful with shared domains e.g. “gmail.com” where you cannot tell which customer by domain. (I had thought that you could script this - if you determine that “fred@example.com” had group “Customer-Example” set in RT, then “alice@example.com” could automatically also get set the same group as “fred@example.com”, but that won’t work for shared domains.)
I did something a while ago where I just had a flat text file which listed
domain:customer_tag and then before the ticketer, stuck customer tag in the subject if it’s not already present. This leads to more useful subject lines, so it’s easier to see in ticket lists:
Subject: Network Issues
Subject: (CUSTOMER) Network issues
Especially where it’s not obvious which customer it is by domain.
In our case, some customers are also suppliers, and so their domain shows up frequently in other tickets relating to other customers (think telecoms or data centre provider where they are both a customer and a supplier.) So it would be inappropriate for them to have access to other customer tickets. So I had to make sure the automation didn’t do something like:
Ticket 1: Order for connection for Customer Y from (example.com)
Ticket 2: Request from customer example.com (Customer X)
example.com = customer Y.
All tickets with “example.com” = Customer Y