Hi there, this is my first post here, so I’d like to say hello to everyone
I’m building a new RTIR instance (on-prem) and I’ve encountered an issue with configuring permissions on ticket based on custom field value (I guess). The case is that we have one big SOC team to handle security cases for 70+ smaller internal entities (let’s sat entities 01 to 70). Those entities might be in one of 4 segments let’s say (A, B, C and D). Each entity have a local security officer (LSO) who reports to segment security officer (SSO).
We really want to avoid creating 70+ queues for all entities. We would like to have all the Incidents in one queue but then it becomes a challenge to give local security officers permissions to see only tickets related to them so LSO 1 will have access to A-01, LSO2 who is from Segment D will have access to D-02 and appropriate segment security officers will have access e.g. SSO from segment A to all tickets for A-, SSO from segment B to tickets for B-.
It would be also nice if we would be able to generate reports based on Segment and Entity.
I think the only suitable role would be CC. Yet I don’t want all of them to receive mail notofication about all ticket updates. Also if LSO will change to someone else I should update CC field for all old tickets for new LSO to have visibility on them.
You can make a custom role that has no notification scrips associated, I think you could still have a custom field that has the access level A-01,D-02 etc and have a scrip that runs on custom field change and checks if it is this field. If so then it adds/removes the SO custom role memebers
It does sound to me like you’re trying to replicate what multiple queues give you directly, which may end up more complicated for you than just having the 70 queues (we have loads of queues here and it works well, especially as teams can move tickets over to other queues for other groups to work on).
Yeah, but having that under a queue rather than custom field forces me to have 70 queues for: Incident Reports, Incidents, Investigations and Countermeasures. which now gives me 280 queues to manage. So, I have to manage scrips, lifecycles for 280 queues. It will be about 20 users working on 280 queues, which looks at least not optimal
I don’t know - the queues still appear more optimal to me! But I guess there no harm in trying your alternate approach with roles and CFs because, if it does turn out to be too difficult, you know you can fall back on using multiple queues with groups assigned to them as normal. And if it does work for you, then win!
In this point I’m not with @GreenJimll and think you’re on the right way using custom role to assign to a LSO.
So create a CustomRole like “LSO” and configure the appropriate rights in the queue. For proof of concept the SOC team can assign the right LSO manually. If the count of ticket rises it’s recommendet to automate finding of the right LSO based on the chosen entity.
I’d try to find the entitiy on information from the user-data. For example put the entity in Extra Info, Address2 or Pager. Other way is to decide based on a department or like this. One can get this information via LDAP, too. So maybe you do not need to do it in source and use any existing user management instead.
So currently we have a CF, let’s call it “Team” (which can be populated by one of the groups we have in RTIR) and a CustomRole called “Org” which has same groups as Team (so there’s one-to-one relation there).
The setup is: Team is populated from the DB and is automatically assigned from incoming emails. Org, the role, is assigned to the Team’s group using a scrip.
Queue has all the groups added to Watchers (otherwise test user cannot view any of the tickets) and permissions set for Org role: comment, reply, showticket.
Test user “John” is a member of Team “ABC” and I would like him to only be able to see and work on the tickets that have Org “ABC” and not being able to see tickets assigned to Team (and Org by extension) “DEF”.
However, it doesn’t matter which team John is a member of, because the second he is a member of any Team he can see everything, all the tickets in the queue irregardless of the Team assigned. If I remove memberships from John, he then cannot see any tickets.
It is hard to get the structure from your description in my mind.
Can you give some screenshots please?
One with a ticket showing the assigned watchers and roles.
One with the GroupRights of the queue, just one screenshot as overview.
And ticket view from user’s perspective. Today I found a new behaviour - user stopped seeing the assigned Org_report even though it is there in Admin’s view as well as expanded people’s tab (when editing) - first time it happened.
The CustomRole Org_report has right to see queue and ticket’s content.
All employees are in the role Org_report at the queue
Result: All employees have rigth to see queue and ticket’s content.
You have to split up this two things: “See queue” and “Work with one ticket”
From here I use “LSO” for persons who should not see all tickets.
Step 1:
Remove all users from the watcher-role at queue-level.
Step 2:
I’d recomment to create a new Group specialy for this queue, lets say Q_Incident Reports_Right_SeeQueue.
Configure the required rights to see the queue and whatever you want all LSO to do at this queue.
Make all LSO members of this new group. (You can use the existing groups for segments of course and make them members of the new group, too. It reduces adminstirative work)
At this point every LSO has the right to see the queue.
Step 3:
I think you do already: Make the appropriate LSO (oder group of LSO) Watcher type Org reportat the ticket.
Result:
All users in the group Q_Incident Reports_Right_SeeQueue have rights to see the queue.
All users assignt to the CustomRole Org report has right to work on the ticket.
Anntotations:
You gave rights to Org reporter globally and on queue-level. That is not required by the system but makes administration more difficult. Decide for this CustomRole if it should have the same rights on all queues or not and choose the right place for the rights.
You can globally assing basic rights and extend them on queue-level.
We use one group for each set of rights separated by queue. We give never rights to users oder usergroups on several queues. The benefit is one can see with “Member of” wich rigths are assigned. On old versions of RT you couldn’t easily answer “whicht rights has this user?” if you give rights directly. On new versions there is the RightsInspector you can use.
Thats why I recomment a own group in step 2. Of course you can use LSO-user or exisitng LSO-groups at this step.
Thanks, at this moment I need to focus on basic user experience and I’m leaving LSOs out of the picture for now.
Also I seem to have stumbled upon too many redirects 302 error after removing groups from watchers from the queue. I’ll look into that and get back to you once that’s sorted.
So, the 302s I’m getting are:
If ACLs are correct - user in correct group, ticket has same group in the role added, privileges only applied to queue level for the role (org_report) - 302 redir loop.
If user is in incorrect group - permission denied, no 302 redir loop.
The problem is now my normal user can see all the tickets in the queue irregardless if they have the same watcher group assigned as the user’s membership or no watcher group assigned at all.
This is what I currently would like to achieve:
User John can only see tickets assigned to John_Group and nothing else. I’m trying different combinations of rights but it seems the perms are all or nothing?
You’re still stuck to the CustomRole “Org_report” and did not create a new Group to give the permission “SeeQueue”. And yes, this way all permissions are the same because all Users are in the same CustomRole.
The same steps as in my last post but more explicit.
Step 1: Remove watchers from CustomRole
Go to Admin-Queues-Select
Select Queue 4 Incident Reports
d. Go to “Watchers”
e. Remove all Users and Groups from Org_report
Step 2: New Group and fix permissions
Go to Amin-Groups-Create
Create a new group All_Group
put in all Users who should see the queue including User John
Go to Admin-Queues-Select
Select Queue 4 Incident Reports
a. Go to “GroupRights” of the queue
b. set permissons for the newly created group All_Group to “SeeQueue”
c. set permissons for the CustomRole Org_report to “ShowTicket”
at this point every User in All_Group sees the Queue, but no exisiting tickets.
Step 3: Assign Watchers on ticket-level
Select one ticket in the Queue Incident Reports
Go to “People”
Assign John_Group (or User John) to the CustomRole Org_report
At this point all Users in John_Group (or User John) see this ticket.
Result:
With Group All_group you decide, who is able to SeeQueue.
With CustomRole Org_report you decide on ticket-level who sees a ticket (ShowTicket)
You can use groups like John_group to assign many Users to the CustomRole in one step.
It was my mistake: turns out when I was debugging and restoring permissions I added the john group to watcher in the queue and forgot to remove it. As soon as I did that John was unable to see tickets outside of his john_group that was added as watcher in the ticket.
So far it looks promising and as intended. I’ll do some digging and clicking and if I run into any issues I’ll let you know.
So I am basically wondering is there a way I could customise the Incidents tickets to include the Roles? When I’m editing the queue I can see that Custom Roles option is available:
I didn’t know the People’s section is not availiable because we do not use RTIR, we use RT. RTIR is based on RT so the things are availiable on queue-level, of course.
What’s the reason to show the custom role? Just informational or is there any need to alter the value on incident’s lifecycle?
Obviously the People are not relevant in context of RTIR. So maybe the CustomRole itself, too.
If you just need the information who is responsible use a CustomField additionaly an set the proper department the same time you set the CustomRole. On change of the CF you can change the CutomRole, too. It is a bit like taking the back door. Not very nice.
You can use a Callback to show the CustomRole, maybe it is sufficient to alter the value.
Remember the alternative:
At this point maybe it is useful to think about different queues, as @GreenJimll mentioned already. Just think about and decide.
One does not have to do all things 280 times.
You have one incident’s lifecycle applying to 70 departments (4 queues each). You have one set of scrips applying to at least 70 queues each.
Only the access-rights per department has to be done on each queue. This is much more comfortable to do only for the role instead of every (new) group.
