This article is a guest post
Chris Cooke has worked with a number of Atlassian Partners (Clearvision, Adaptavist, CodeBarrel) before founding Old Street Solutions. Their mission is to give all less technical Jira users intuitive and easy to use add-ons.
Every Atlassian Services project that started while I was at Clearvision and then Adaptavist got off to an awkward and unnecessarily slow start when we were forced to explain how to set-up complicated permission schemes before the client could give us access to their Jira.
Collaboration is crucial, especially with the neverending growth of partnerships, acquisitions, and mergers, and the increasing number of Contractors, and Consultants that successful teams want to collaborate with. Ideally, once you’ve chosen to share with external partners in the development process, they should be able to easily integrate with your teams, processes, and tools. To effectively expand the collaboration, both teams need real-time visibility into what’s being worked on, as well as the ability to comment on tickets, view, and add attachments.
If you want to give an external partner limited and secure access to your Jira (or Confluence) there are three options, depending on the length of the collaboration, the size of the instances, and the amount of access you’re willing to share.
Option A: Set up the permission schemes and give a full Jira license to everyone.
Option B: Use Exalate to clone part of your Jira instance within theirs.
Option C: Use External Share for Jira issues and their sub-tasks.
What it’s best for
|Jira with properly set up roles, permission schemes, and issue security schemes.||Whole Jira epics and projects for a year or more.|
|Exalate for Jira||Syncing Jira Projects with a small instance for a year or integrating with other tools (e.g. ServiceNow, Zendesk, and Github).|
|External Share for Jira||A few Issues and Sub-Tasks for a few days to a few months.|
Option A: Set up permission schemes in Jira
1. Know What You Need to Share in Jira (and what not to share)!
If you’ve got a full-time Jira admin with experience of permission schemes (and LDAP, Crowd, or active directory) then you can simply set up the appropriate permission scheme for the projects you want to share with external users, and ensure they won’t have access to the projects and epics you don’t. Users with big Jira instances will already be doing this for internal employees.
If you’re going to be onboarding a large number of external users, it may be time to consider setting up a separate directory structure using Crowd as a single sign-on server as outlined by Dan Radigan in Atlassian’s Blog, but for now, while you’re here, this is the TL;DR.
“Working from the top, the first layer indicates the directories you’ll need to connect to Jira. The red groups come from your corporate directory structure (Active Directory, LDAP, etc). The blue groups represent external users and can be in the same or a different directory provider.
The second layer are the groups provided by that directory. In each directory, you want one group that defines all of the users who have access to Jira. Everyone who accesses Jira needs to be a member of Jira_users. You want to identify users who are internal or external explicitly to delegate permissions… For example, email@example.com is a member of group ext-company1. I recommend using an email address as the username since it is universally identifiable… Once the base infrastructure is built, we can then add permissions and make it work for external users.”
Once that’s sorted, it’s time to...
2. Define Roles in Jira (while being clear how they differ from Jira groups).
If you’re consistently outsourcing a specific well-defined role to the same outsourced group, this process will work for you.
“Think about all of the job functions inside of your project. (e.g. internal developer, project lead, or external partner lead)... (E.g. when moving an issue out of internal review, the workflow will assign the issue to an external lead).
If we embed the name or group of the external partner in the workflow, that workflow will only work for that one company. Using roles will allow us to flexibly use the workflow across multiple projects, parametrizing the people involved.”
If the people or groups change between Jira projects, Use a role. If the same people are consistent across all interactions in Jira, Use a group.
3. Set up Jira Permission Schemes
Permission schemes control who can see and manipulate the core functions inside a project. Browse project permission. This controls who can see that project inside of Jira. Let’s start by granting access to the group mars_users (internal employees) and the role partners (partners for that project).
External users can only see Jira projects where their company group is added to the role partners, but regardless, grant permission scheme access conservatively, and keep it simple by modifying the default permission scheme, rather than creating a new one.
4. Set Up Jira Issue Security Schemes
Teams that need to restrict the visibility of issues within a project can do so with issue security schemes. These control who can view a particular issue or its comments. This allows internal users to create issues or conversations in comments that external partners cannot see.
5. If this sounds complicated, that’s because it is.
That’s why Atlassian recommend you experiment on a staging instance while setting up permission and issue security schemes. Experiment with workflow conditions and post function triggers, and then produce documentation and book training to ensure all users comply with naming conventions on shared objects, agile boards, and filters. Without these safeguards in place, you risk leaking secure information.
That’s why there’s a marketplace for easier options:
Option B: Use Exalate to clone part of your instance in theirs.
There’s a detailed step by step guide: how to synch two Jira instances using Exalate
But the short version is:
1. Install iDalko’s Exalate from the Atlassian Marketplace
2. Map a workflow that works for both teams. The workflows don't have to be identical, but you will have to map how they work, and what changes in one mean for the other.
3. Choose what to share, from the most appropriate templates.
4. Install Exalate on both instances.
5. Exalate each issue you want to copy.
6. Customize Jira synchronization rules through scripting:
7. If required, seek assistance from the Exalate team.
Option C: Share Jira Issues With External Share for Jira
If you simply want to share a few Issues and subtasks with a few people for days or months, External Share for Jira is your best bet. Not only does it give you easy granular control of exactly which issues everyone has access to, but also exactly how long everyone has access for, and what exactly they can see, comment on, and add attachments to.
All links can be password protected, and all permissions can be revoked at any time with a flick of a switch. For peace of mind, admins get a clear easy view of what’s being shared, how much access they’ve been given, and what the default sharing time-limit is. For those not looking to share entire projects, External Share for Jira is a secure and quick-to-set up solution.
There’s also a free version to help you securely share access to Jira or Confluence as well, available on the Atlassian Marketplace.