This must be doable: give an external vendor access to specific work items in one project. Nothing m

[Tim Kersjes]

I'm at my wits' end here. This must be f'ing doable but I can't for the life of me figure out how. So, please let me know if I'm asking for something impossible or unreasonable.

The title says it all: I have one specific project (my company's JIRA has many projects like, but this is mine). I'm getting a third party vendor to help out with some of the tickets (or work items as they're called now). All I want is to be able to have these vendor people sign in, and then only have access to very specific work items. Either I assign these to them, or I set up some work item security, etc.

But here's the thing: I can't get it to work. All the work item security/project settings/group access settings/whathaveyounot have been fiddled with, and I can't get it done. My external guest account (hotmail account) can still access all the tickets and browse all the projects. I've tried setting up a very specific group for the vendor users, I've tried removing the test account from all sorts of groups that are listed under permissions to browse etc.

Sure I can't be the first person in the history of JIRA to have this use case?! Wtf am I doing wrong here? Which setting am I missing, what obvious thing is going right over my head?

TL;dr: I just need to be able to give access to external vendor accounts on very specific tickets in one specific project. That's it. Please help!

[John Funk]

Hi Tim - Welcome to the Atlassian Community!

You will need to use issue level security. Here is a link to the guidance:

https://support.atlassian.com/jira-service-management-cloud/docs/create-security-levels-for-issues/

Now, having said that, if it is a JSM project and you want the person to do work in that project, they will need to have an Agent license if they don't already. 

[Tim Kersjes]

Thanks John.  I've already tried this, but it doesn't stop the vendor agents from being to able to browse other projects etc. 

[David Nickell]

hello John F... I admire your approach on this but Ticket Level Security is some true Altassian Jira PHD level stuff.   I assume with Autmation it is easier now to set the security level upon ticket creation.   But then there is the pesky comment security too.

Around 2010 I worked for a company that had over 100 clients sharing the same Support Project.  (no such thing as JSM back then).   It was a nightmare :-).

@Tim Kersjes Can you create a new project for the vendor then bulk move just the tickets you want them to use into it?  There some considerations of course like possibly needing a combined view for their tickets and others in your org,   We can talk through the mechanics.  No charge.  would take an hour on zoom...

[John Funk]

@Tim Kersjes  - Sorry, didn't understand the part that they already had access to other projects. So, first thing you have to do is change the Permission Schemes used by every project to not grant any permissions to "Any Logged In User". I suggest you don't use groups either in the Permission Schemes but just use Project Roles. Then in the project settings of each project, you would need to grant users access to particular roles that apply to them for that project. If a user is not granted access to a project role, then they would not have access to that project. 

The simplest version would be to create a Project Role called Team Member or Team or Member or something like that. Then grant that Project Role permission to anything you currently grant to Any Logged In User or the jira-software group or other groups added at a very high level. 

That would be the first step. 

@David Nickell  - I have used issue level security with no problems in Jira for years.  :-)

[David Nickell]

@John Funk I agree with your steps and your recommendation of ROLE BASED permissions.

So at this point it sounds like "vendor" is strictly helping to work on tickets, not adminster or adjust the configuration.

And as you indicated (and I will paraphrase) - this is PROJECT LEVEL management.  If the vendor is working in a project where they can only see a subset of tickets, then we are back to ISSUE LEVEL security, or spearating the Vendor into their own project.

One final comment -- @Tim Kersjes could also create the ROLES of PROJECT VIEWER and PROJECT EDIT.  This allows him to give more users  READ ONLY access if he wants to open up the view to more users, but limit who can make updates

Good luck guys! 

[David Nickell]

I think I can help you;  Having had my clients add me to THEIR instance as a user always has challenges for the reasons you mentioned -- the security has already been set up by gosh only knows who.....

---

A> Access like an employee

• To let them in find a USER (or create one temporarily) that has the access your vendor needs.  
• Then go to USER Administration and be certain your vendor has the same roles as the "working" user.

This document doesn't make it much easier, but will give you context. if they need any sort of admin access:

https://support.atlassian.com/user-management/docs/what-are-the-different-types-of-admin-roles/

---

B> Or do they just need the work items for a specific portal or organization?  

In this case, lets create a filter for that use case and then I can show you how to output the records seemlessly to Excel.

Obviously this represents 2 ends of the spectrum.  -- add them like a contractor employee or just give them an Excel Extract they can run whenever they want.  You could probably do that without adding a user license.

Hit me up directly if you prefer.... 

[Trudy Claspill]

Hello @Tim Kersjes 

What is the Type of the project to which the users need access?

There are several things to check/set to limit access for specified users to just one project.

First, are Team Managed projects in use on your site? Each TM project has its own project level Access setting. There are 3 levels; Public, Limited, and Private. Public and Limited access levels enable everybody to see the project contents. Only the Private Access Level will enable TM projects to be hidden from view. Every TM project must have its Access Level set to Private if you don't want those users to see the project contents. Refer to

https://support.atlassian.com/jira-software-cloud/docs/next-gen-permissions/

Company Managed projects use Permission Schemes and the Browse Projects permission to control project visibility.  The permission can be granted to a Project Role, specific individual users, User Groups, to users specified in fields in the issue, to Public, to all users with Product Access. You need to review all the Permission Schemes used by projects to confirm that none are set to grant access to Public or Application/Product Access. You then have to look and any User Groups to whom the permission has been granted and ensure the users are not members of any of those groups. Create a User Group just for those users and add that group to the permissions in the scheme used by the target project if the target project is a CM project. Make sure that scheme is not used by any other project.

Those are the steps to take to limit the users to seeing the content of only one project.

If you think you have done that and users can still see projects that they should not, we need to dig into the details of access/permissions for one of those projects.

After confirming the project access is set correctly, the Issue Security is used to impulse additional visibility restrictions on the issues in the project.