You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We have a group that needs access to all projects in a view only way to review tickets open and historical.
Currently - they are all CUSTOMER ONLY roles - mistakenly/historically set to take up a license and effectively functioned as an agent. As we moved to datacenter and updated how this role aligned with licenses - their ability to navigate was removed to portal only.
They don't progress or work the tickets it's more of a research role - and then as customers they may open tickets in the applicable project as needed.
My thought is that the collaborator role may meet the need but it's not clear if collaborator needs to align with a specific project or can see all projects. (this would be ideal)
looking for ideas on how to maximize access without having to maintain multiple project access (agent or otherwise. Another wrinkle - CROWD has a nesting feature, but we are moving to OKTA - which that seems to be an issue - so multiple project access will result in multiple license use - which we want to avoid.
One option you can try is to have a group created in your JSM env containing all the users who need to access the issues via the project UI (browse project only - Non agents only without giving agent licenses) first.
Afterward - For each JSM project: Modify the project permission scheme and only grant "Browse project" right to the user group above. Lastly, ensure the group is assigned to the proper project role for the project. For non agents - who needs to access the issues via project UI, they should be added to the "Service Desk Team" project role. However you will need to evaluate project's permission configuration setup too.
You can reference the following link and review the section on Collaborators - https://support.atlassian.com/jira-service-management-cloud/docs/what-are-user-types-and-roles/
The above suggestion is project by project basis since each project can have different project permission configuration and role assignment independently.
Feel free to ask for more information as needed.
Hopefully, this give you a starting point.
Best, Joseph Chung Yin
Jira/JSM Functional Lead, Global Technology Applications Team
@Joseph Chung Yin Thank you for the response - I'll have my team review. One question I do have is - we are moving to OKTA (Currently on Crowd) - Crowd allows nesting, where our understanding is that OKTA does not.
Does your solution require that customer user group be created for each project?
JIRA_ABC-Customer, JIRA_EFG-Customer etc....
Lastly - how does that work with tickets they aren't assigned to or is that part of the solution to assign the group as a requested participant (to all tickets) to allow them to view? I feel like I'm missing something. Perhaps this creates an "expanded" customer access to view but can't access or comment unless RP?
I am not an expert or SME on Okta, so I cannot advise on that front. In regards to project question, it is up to your end if each project needs different groups or not. Essentially, you should decide if each group members should be able to access issues via the project UI among the many projects that you are managing or each project access should be locked down due to content security.
Not quite understanding your statement of "unassigned tickets". Requested Participant is assigned to each issue by default which means that those members can access the issues via the portal UI. All members of issue's requested participants can access the issues via the portal UI and are able to add public comments to the issues.
Hope this helps.
@Joseph Chung Yin Thank you as far as unassigned tickets...I wasn't following the process around this. I was thinking out of order - but restating what you've provided in a numbered list makes sense to me...group, update project permissions, assign project role...and users who are aligned with the process should be able to browse the project/tickets - basically a mass alignment - not specifically tickets but essentially to all to allow browsing and if they need they can comment.
I'm thinking there is an order of operations to setting this up.
I think the only wrinkle on our side is that not all users would fall under the service desk role and need individual access - which should be achieved through individual RP assignment.