But why he sees all projects in the create project screen?

[Roberto Soto Alvarez, MBA]

I want to have a user to create an issue in only one project.

The user can see only one project in the projects list

But why he sees all projects in the create project screen 

I created a group to hold the users I want to work on the project.

I tried to modify the permissions, Roles, fields, screens and issue types but I still get the list of all my projects on the Create Issue Screen. But still, I got the same list of all projects when creating an issue for this project.

Can you help?

[Andy Heinzer]

Given the screenshots you have provided, it looks like this user has the correct Browse permission.  Which appears to be set to that one project.   However if they can see the other projects in the create issue screen, then this is likely because the user still has the permission to create issues in those other projects.

Without the browse permission they can't actually see the issues they create in those projects, but they can likely still create them.

Check out Managing project permissions.  Specifically I would focus on the permission scheme in use by these other projects and then determine what role/group is granted access to the Create Issues permission.  By default with Jira this tends to be 'Any logged in user' or something alike.   If you change this for these other projects you can likely resolve this, however you need to make sure that you grant some other group/role access to create issue there, otherwise no one will be able to create new issues there.

You can also use the Jira permission helper to determine if this user is being granted access to create issues in these other projects by some unexpected group membership/role.

[Roberto Soto Alvarez, MBA]

Thanks a lot Andrew for your fast response. I'm going to take a look at the links you provided and come back later on.

[Roberto Soto Alvarez, MBA]

I went all over the permissions documentation and cannot make just to show only the authorized projects for a user. It shows all the projects. In fact there is a document mentioning that any user will see all projects while creating an issue . Too sad.

[Andy Heinzer]

Please let me know what documentation you are referring to.

I just walked through this process in my own test instance and I was able to create a custom permissions scheme that does not grant the Create Issue or Browse Issue permissions to the "Any logged in user" role. 

Instead I set those permissions to only allow for the project role of Administrator.   When I then assigned this permission scheme to my other project, my account that is not an admin in that project does not have the ability see that project at all, including in the issue create screen.

My Jira version I did this in was 7.7.0, but I believe this still is valid for many older versions of Jira as well.

[Roberto Soto Alvarez, MBA]

Well, I will come back with the document I found.

I will give another shot to the procedure and get back to you. My Jira version is 7.2.6 

What I want to achieve is to create a project, a group of users and roles that will have access to ONLY that project, By which I mean creating, modifying and accessing all the info on the project but not able to see other projects.

Do you have a step by step guide to do this? Or can you share your permissions scheme?

Thanks for your time on this issue.

[Andy Heinzer]

There is not an easy way to share permission schemes in Jira.  But I can understand why this can be difficult to achieve in Jira.  By default Jira ships all new projects in the default permission scheme, which is very open to any user with a login.  And yes, you are correct that you would need to change the permission scheme on all the other projects that you do not want this user to be able to see.

Here is a screenshot of part of my permission scheme I set on my BIZ project:

What I had to do here was create a new permission scheme.  In my case, I copied the existing default scheme, and then edited that copy.  I had to first add a permission for almost all of these entries.  In my case I kept picking the "Project Role = Administrator" as my default add.  However you might want to grant other project roles, or possibly groups into specific permissions.  It really depends on who needs access to what.

Only after I added all those permissions, was I then able to use the Remove link on each entry that had the "Any Logged in user" listed for it.   This is particular important in your case to the browse and create permissions, but I would recommend going through all the permissions here since it sounds like you want to make sure this set of users only has access to this project.

In my case, I was not editing a live scheme, so after I made all these changed, I then had to go back to this project settings, choose permission schemes, and then in the top right corner under Actions -> Use a different scheme.  Once I selected this new scheme for this project, users outside the project role of Administrators or developers or the group jira-administrators can't browse this project.

In that case, you would then likely need to repeat the last step of Actions -> Use a different scheme on each project that you want to keep away from these users.

The thing about this is that I would really recommend that you use project roles to define permissions here.  Using explicit groups can work, but it's not always appropriate.  The other thing is to make sure that your users in these projects that need access to this are already members of the project's Developer role or project Admin role.   Managing project roles memberships will likely help with this if you have not done this before.   This part is important to make sure that you other users that are expected to have access to these projects can still do so after you make these permission changes.

[Roberto Soto Alvarez, MBA]

Wow! that was a really excellent explanation. I will try again, but I think this answers my question very well. Thanks a lot Andrew for your time! 

[Andy Heinzer]

Awesome, I hope it helps.  Let me know how it goes.