group can view only one project and on this project only its issues

[Flavie Henry]

Hello, 

On a project, I have a new group. 

This group can see 1 project et he can see only issues they created : they can create, modifie issues and add comment on this. 

I understand I need to use atlassian-addons-project-access role, but my test does not work. 

[Trudy Claspill · Accepted solution]

Hello @Flavie Henry 

Welcome to the Atlassian community.

You should not be using the atlassian-addons-project-access role. That is not a role that is intended to be assigned to users. It is used only for granting access to the apps that you add to your Jira instance.

Is the project the new group needs to access a Company Managed project or a Team Managed project? Do you have both Company Managed projects and Team Managed projects in use on your Jira instance. Go to the Projects menu and select the View all projects option. Review the Type column shown for the projects to see which types of projects you have.

If you want a group of users to see only one project you need to

1. check the permissions used by projects

2. check the groups to which the users in your new group are assigned.

The users in you new group need to be assigned to a group that grants them Product Access to Jira. 

They need to be granted permissions to the one project they should see. 

The other projects in the system need to be reviewed to ensure that they don't grant access to that group and that they don't grant access to "Any logged in user" or "Public".

If you have Team Managed projects, each one has an overall Access setting of Public, Limited, or Private. To prevent the users from seeing Team Managed projects all of those projects need to have an Access setting of Private. And then for each of those projects the people of do need access have to be explicitly granted access.

If you also need to limit the new group's access to see only the issue they create within the one project they can access, you will also need to implement Issue Security. The implementation depends on whether that project is a Company Managed project or a Team Managed project.

[Flavie Henry]

Hello @Trudy Claspill

The project in question is a Company Managed project. I have both Company Managed projects and Team Managed projects use on my Jira instance.

Yes, is what I do. I put the group in Browse Projects (I don't know if is the good thing because it's write project and issues "Ability to browse projects and the issues within them.")  and I create a security : 
with the current assigned, the reporter and another group, they can see all.

I call this security in my workflow on the transition Create. 



But my group see all issues, 

[Trudy Claspill]

Helo @Flavie Henry 

The Browse Projects permission gives the specified users the ability to see the project in the "View all projects" screen and to see the issues within the project. It does that for only the projects where the user is granted that permission. If the user is not granted that permission in other projects, then those other projects and their issues should not be visible to that user.

For all the issues in that project that you don't want the users to see you also need to assign a Security Level to those issues and it needs to be a Security Level that does not include those users.

Security Levels are used to limit the visibility of an issue. If no Security Level is assigned to an issue, then it is visible to everybody that has the Browse Projects permission.

Additionally, as I said, do not use the atlassian-addons-project-access role. Users should not be assigned to that role. Create a different project role for this group of users.

[Flavie Henry]

Hello, 

Oh yes sorry, it was a mistake of inattention. 

For me, I followed all your recommendations but it still does not work as I want.

On the workflow at the transition create :

[Trudy Claspill]

For all the issues in that project that you don't want the users to see you also need to assign a Security Level to those issues and it needs to be a Security Level that does not include those users.

Security Levels are used to limit the visibility of an issue. If no Security Level is assigned to an issue, then it is visible to everybody that has the Browse Projects permission.

[Flavie Henry]

Thank you for your time, but I don't understand the problem. 

In my capture, is the security for my issues and I put the Security Level only for reporter, current assigne and the project role who must see everything. 
And after I assigned this Security Level in my workflow on the project role to whom I want who only sees theirs. 

So as you say I wouldn't need a Security Level for the other case. 

[Flavie Henry]

Finally, by adding a security level by default because I thought that maybe, I had misunderstood your last point, it works a little better.
I just have the problem that my SVL group doesn’t see anything even if it's create the issue, and it's reporter on the issue

[Trudy Claspill]

Let us define a specific example to ensure that the requirements are understood.

Let us say your project has two issues, ABC-1 and ABC-2.

Let us say the user Joe  and user Sally are the users who should not be able to see all issues.

Let us say that Bob is a user who should be able to see all issues in the project.

Let us say that Joe is the reporter of issue ABC-1

Let us say Bob is the reporter of issue ABC-2.

If I understand your requirements correctly:

Joe should be able to see ABC-1

Joe should not be able to see ABC-2

Bob should be able to see ABC-1 and ABC-2

Sally should not be able to see any issue, because they are not the reporter on any issue.

Is that an accurate representation of your requirements? If not, please provide corrections.

[Flavie Henry]

Yes, it's correct 

[Trudy Claspill]

Great!

Reviewing what you wrote, I think you have made the following changes to your project.

1. You created the Issue Security Scheme with the one Security Level and you associated that Issue Security Scheme to your project.

2. You set the Security Level on issue ABC-1.

3. You left the Security Level on issue ABC-2 blank.

4. You added Joe and Sally to the project role "IZIVIA - Realisation". Bob is not in that project role.

If that is not accurate, please provide corrections.

If that is accurate, then what are the actual results you are seeing for who can actually see issue ABC-1 and who can actually see issue ABC-2 in your project?

[Flavie Henry]

1. Now, I have 2 security level. one for Joe and Sally and one for Bob this is the default (I put all the people we can see). 

2 and 3. For me, it's in the workflow with my issues I say in the create transition, the level security for "IZIVIA - SVL" is Reporter, IZIVIA-Realisation and Current assignee


4.  I added Joe and Sally to the project role "IZIVIA - SVL". Bob is not in this project role, he is in "IZIVIA - Realisation". 

With this my results is Bob can see all and Joe or Sally see anything. 

[Trudy Claspill]

1. Can you please provide a current screen image of the Security Level configurations?

2. Can you show use the workflow details where you are setting the Security Level?

3. Do I understand correctly that all issues now have a Security Level set, and all issues going forward get a Security Level set during their creation?

4. Can you clarify for me who can see which issues? For example:

Issue ABC-1 has its Security Level set to level #1 (from step 1 above). The reporter of the issue is X (Joe or Sally or Bob or somebody else) and the Assignee of the issue is Y (Joe or Sally or Bob or somebody else or it is unassigned).

4a. Who can see this issue? 

4b. If 4a is not the result you want, then who do you want to be able to see the issue

Issue ABC-1 has its Security Level set to level #2 (from step 1 above). The reporter of the issue is X (Joe or Sally or Bob or somebody else) and the Assignee of the issue is Y (Joe or Sally or Bob or somebody else or it is unassigned). 

4c. Who can see this issue? 

4d. If 4a is not the result you want, then who do you want to be able to see the issue

I am sorry this it taking so long to work through. We need to clearly understand all the configurations, the values used in issues, and the impact of those on who can and cannot see the issues. With a clear understanding, we should be able to offer the right guidance to help you resolve the issue.

[Flavie Henry]

Hello @Trudy Claspill, 
My company expert on Jira came back from leave yesterday.
I was missing an automation to change the security level according to who creates the ticket.

Thank you for your time, 
Pleasant day