So here is what I am trying to do. I have setup a Cloud Service Desk project for our payroll team. They have two tiers of support tier 1 and tier 2. I have two groups tier 1 and tier 2 of users. I have set the group tier 1 with access to security level tier 1 issues which is default and tier 2 group has access to both tier 1 and tier 2 security levels. I have set up queues for both tier 1 and tier 2 that only show tickets based off the level.
The idea was that issues come in as tier 1 then group tier 1 reviews any issues and if they need escalation to tier 2 then they change the security level to tier 2 and it then shows in queues for the tier 2 group. There is also some automation rules that change security level to tier 2 based off a custom category field. Sensitive issues created in certain categories are automatically tier 2.
However, tier 1 cannot change a security level to tier 2? After looking at the documentation I assume that it is not possible to set a group to only be able to change to a certain security level that is cannot see?
Workaround would be to create an issue type of tier 2 they can change it to which would then use automation to change the security level?
Hmm, strange. If they have the permission to set a security level I would assume they can change to any level.
of course if they are not part of the current level they cannot see it and thus change the level.
We use it in a similar way to have First line agents set it to an ISO security level after which it vanishes for themselves.
it is indeed not possible to restrict to setting only a specific level.
what are your ‘set issue security’ permissions set to?
also do you need to restrict the viewing? If you simply wish to escalate to another group of users, why not use a different custom field like ‘tier level’ and just work that in to your queue JQL?
or do you really want tier 1 to no longer see them after escalation?
Thank you for the response. Yes we did want any tier 2 issues to not be visible to tier 1 group members. The reason was some sensitive issues are created by default as tier 2. they can see the tier 1 level but not tier 2.
Tier 1 group view:
Tier 2 group view:
I checked my "set issue security permission" and all tier 1 and tier 2 roles have access to set it.
I did a workaround of making a custom field with tier 1 and tier 2 options and used automation (which has access to both security levels) to change the security level when that field is changed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I indeed tried this on my instance and this just seems backwards, I feel like a user should see all security levels when setting once set of course the issue should be gone unless you have the correct security level.
I've launched it as a support ticket and will see what they respond :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FYI @[deleted] you can always vote and watch the issue!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @[deleted]
I think you're correct about them not being able to see the Tier 2 because they're not part of it.
I also think your workaround would work. My advice though, rather than a new issue type, would be a new Custom Field with a Tier 2 tickbox, then if it is ticked the automation runs to set the Security Level to Tier 2.
Hope that helps
Regards, Liam
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Liam, I had the same thought actually. I did a workaround with a custom field and automation to check when that field was edited and change the security level to match.
It works but it seems odd that there is already a dropdown to change the security level of an issue but no way to set permissions to that dropdown that would allow people to see and set it but not see the tickets related to it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.