User Permissions on Team Managed Project

[Alisa Collins]

We have clients invited to our project board. I would like to restrict visibility for them ONLY see issues they created, are assigned, or are tagged in. 

I have GROUP setup for them - I also have a specific ROLE for them. Again, this is a TEAM managed project. 

Do I have any options? 
Permissions at the role level are not clear - but testing we haven't found the right combo (if there is one). 

If not this, on at TEAM managed project, is there a way to set an ISSUE type permission that would only allow them to create and SEE issues of that type? 

Many thanks.

[Mikael Sandberg]

Hi @Alisa Collins,

Welcome to Atlassian Community!

No, team-managed project cannot set the view level on individual issues, you can only restrict who can view different issue types. In order to restrict issues to just the ones that they created, are assigned to or watching you have to use a company-managed project and security levels. 

[Trudy Claspill]

Actually @Mikael Sandberg that is not true.

You can set restrictions on individual issues as well in Team Managed project. Through the UI you do so by clicking on the padlock icon.

@Alisa Collins You can set visibility of issues based on their Type, giving specified project Roles visibility to all issues of specified issue type(s). That does not give you the granularity to restrict visibility to "issues they created, are assigned, or are tagged in"

It should also be noted that there was a Sept. 2023 post where I and others were trying to explore setting issue restrictions in a Team Managed project via Automation Rules, and we were unsuccessful.

https://community.atlassian.com/t5/Jira-questions/team-managed-project-set-security-level-when-transit-to-certain/qaq-p/2468632

Also, since restrictions are based on Project Roles you would have to basically have a unique Role for each user. If User A and B shared role XYZ, and only user A was the Creator, current Assignee, or Mentioned in an issue, if you restricted the issue to Role XYZ then that would enable User B to see it also. That doesn't match your requirement.

You would have to have a unique Role per user for the users for whom you needed to restrict issue visibility, plus a Role for the users who need to be able to see all issues. Each issue would have to be checked to see which of the client users was the Creator, current Assignee, or mentioned in the issue so that their Role could be added to the Restrictions, along with the Internal Team's Roles being added. And each time the Assignee changed or a new Mention happened, the checks would have to be done again.

And you would have to set restrictions on every issue. If an issue did not have any restrictions set, then it would be visible to all the clients.

In conclusion, I don't believe there is a solution to your requirement as long as you are using a Team Managed project.

[Alisa Collins]

Thank you both for this information. At least I know that I'm not missing something.

I'm not sure the restriction of issue type will work--but may be better than nothing. 

[Alisa Collins]

@Trudy Claspill 

I've attempted to set a role with limit to only see BUG tickets. 
I asked this user to log out and back in - and provided him with a link to the Board. 
He is still seeing other types of tickets. 
Am I doing something wrong?

[Trudy Claspill]

Hello @Alisa Collins 

What you have done is restricted the Bug type issues to be visible only to people in the OLC Client Copy role.

That affects only who sees the Bug issues. It has no affect on the other issues.

To prevent the users from seeing the other issues types, you have to restrict those other issue types to Roles in which the user is not a member.

By default all issues types are visible to all roles - when no restrictions are set.

You add restrictions to limit who can see the issue type.

For the issue type the clients can see, if you want the clients plus all other project members to see those issues, then don't set any restrictions on that issue type.

Then you need to define role(s) that encompass all the members of your project except the clients.

Set restrictions on all the other issue types the clients should not be able to see. Add all the role(s) that do not include clients. That will make those issue types visible only to the people in the specific roles. If the clients are not in those roles, they can't see those issue types.

[Alisa Collins]

@Trudy Claspill 
Thank you -- I've tried again. 

I modified the restrictions on "Task" and does not include "OLC CLIENT" role.

I have a user with role "OLC CLIENT" only. 


I created a new TASK -- 
I impersonated this user via Admin Controls. 
But I am still seeing the newly created TASK when I view the board as this user. 


Last one in the column on left.

Am I still doing something wrong?

[Trudy Claspill]

Hello @Alisa Collins 

Were those tasks created after you set the restriction on the Task issue type, or before?

If you open one of those Tasks, does the Restrictions icon (the padlock) show unlocked or locked?

Setting a restriction on an issue type will affect only issues created after that. Pre-existing issues remain unrestricted. You have to manually edit each of the pre-existing issues of that issue type to set the restrictions on it.

[Alisa Collins]

@Trudy Claspill 

It shows locked.

[Trudy Claspill]

Can you show us the user icon for the logged in user on that tab with locked issue, to confirm it is LC for the user who should not be able to see the issue?

If the padlock icon is clicked by that user in that view, what do they see?

[Alisa Collins]

@Trudy Claspill  Thank you for your help with this.  Below is screen shots.  The last 'task' in the left column was created after changing his role - so would expect not to see it. 

[Alisa Collins]

Here's his user profile - in case it is helpful:

[Alisa Collins]

Would his 'admin' check marks be throwing off the view?

[Trudy Claspill]

Indeed it could be.

Can you show us the permissions that you allocated to the OLC Client role? Did you intend for the users in that role to have administrator access for the project, or more restrictive permissions?

Did you create the OLC Client role by copying another existing role? Did you modify the permissions in the OLC Client role after you initially created it?

[Alisa Collins]

@Trudy Claspill 

Answers...

Did you intend for the users in that role to have administrator access for the project, or more restrictive permissions?
More restrictive.  

Did you create the OLC Overview role by copying another existing role?
No

Did you modify the permissions in the OLC Overview role after you initially created it?
Yes, but never admin

[Trudy Claspill]

Sorry for my "typo" in my last message. I should've been saying the OLC Client role but instead typed OLC Overview role.

In the screen where you see the user has Administrator role, that is specific to the OLC Overview and Lotteries Solution projects. That should not have any impact to the OLC Eapp Maintenance project. Also that page will show you only their role associations in Company Managed projects. It does not show role associations for Team Managed projects.

Does the OLC Client role in the OLC Eapp Maintenance project have the Administer Project permission?

If the user is assigned to a role that does have that permission in that project then they will be able to see all issues in that project. You would need to revoke that permission from the OLC Client role

[Alisa Collins]

@Trudy Claspill 
The OLC Client role does NOT have Administrator rights.
The test user (Leon) is assigned to that role in this project, and does NOT have Administrator rights -----HOWEVER, he was previously an administrator on this project (I changed his role for purposes of testing).  But currently he only has the one role - OLC Client - with no admin rights. 

Should I attempt to remove him from the project and then add back fresh without that history of Admin rights?  Would that even matter?

[Trudy Claspill]

So far I have not been able to replicate your experience.

I added a user to a custom rule that did not include the Administer Project permissions, but had all other permissions granted.

I manually set an existing issue to be restricted to on the Administrator role.

As an Organization Admin I logged in as the other user and tried to access the restricted issue. I got a message that the issue couldn't be found or the user didn't have access.

I even tried giving the user Jira Product Administrator access. They still couldn't see the issue.

Unfortunately I'm out of ideas. At this point I recommend that you open a support case directly with Atlassian. With your permission they can access your instance and examine the configurations directly. They may be able to find the discrepancy which we have not been able to uncover with our dialog here.

You can open a support case at https://support.atlassian.com/contact/#/

It would be great if you report back here what you learn.

[Alisa Collins]

@Trudy Claspill   Will do.
Thank you so much for all your help. It is greatly appreciated.