Unique role question -Collaborator?

[David Conifer Healthcare Solutions]

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.

[Joseph Chung Yin]

@David Conifer Healthcare Solutions -

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

Viasat Inc.

[David Conifer Healthcare Solutions]

@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?

[Joseph Chung Yin]

@David Conifer Healthcare Solutions -

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.

Best, Joseph

[David Conifer Healthcare Solutions]

@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.

1. Create the groups from the "customers" that can/will be assigned as participants to applicable projects
2. Modify project permissions to allow browse project for the assigned group
3.  As I'm not the actual admin I'm not following the Service Desk Team role.. but my dev may be. - but assign this role to the users.

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.