Settings Created for Jira Product Discovery Projects – Not What I Expected

Mistakes in Jira administration are learning opportunities. Here’s an example of one of my incorrect assumptions and what new settings are actually added when Jira Product Discovery projects are created.

Jira Cloud Deployment Type

Today I expected Jira to behave one way and after some experimentation, I learned that I was wrong. Sometimes this happens and there’s no reason to be afraid of it or embarrassed. Mistakes are an inevitable part of Jira administration. I don’t see them as a waste of time, I see them as opportunities to learn and improve. Allow me to explain.

In 2023, Atlassian launched Jira Product Discovery (JPD) in Cloud for product teams track and prioritize ideas. Just like all Jira project types, JPD projects come with built-in settings and templates to help you quickly build and get started. When evaluating project types and templates, I always recommend creating them in a test environment first. It’s important to understand what additional settings different project templates create in the background. That’s because lots of new settings may mean more items to clean up in the future.

For this article, I set out to document all the new settings added when Jira Product Discovery projects are created. This way you can see what to expect in your own application without messing it up. E.g.: I’ll make the mess so you don’t have to! But after experimenting, I learned that there were few new settings to document. Here’s why:

Scope of Settings

The JPD project configuration is similar to other team-managed project types in Jira Cloud. Projects are scheme-less meaning the settings are not shared with other Jira projects. Therefore there are less global application settings created than for company-managed projects. So, there’s actually not much to report! As such, I’ve categorized the information below into more impactful (global) and less impactful (project-specific) settings.

After I created a sample JPD project, I checked the Jira audit log which records some (but not all) admin changes. (Visit: Admin > System > Audit log) The log recorded 152 actions, but only a few of them were related to creating shared settings. I was pleasantly surprised by the low new global setting count! As I mentioned, in my 9 Ways to Learn Jira Administration article, having a healthy curiosity and willingness to try things out (in a test environment, of course) is a great way to learn new things!

New application-level settings (More impactful)

I found the following new settings by hunting around the Jira admin area.

Global Link Types

Global link types created for Jira Product Discovery projects
Global link types created for Jira Product Discovery projects

Three new link types were created. Atlassian sometimes give new products and features a temporary name during their beta testing phase. I’m assuming that “Polaris” was the initial name for JPD.

Global Groups

The following global access and admin groups were also created:

NameDescription
jira-product-discovery-contributors-1-<cloud-site-name>Grants contributor access to shared Jira Product Discovery projects on <cloud-site-name>.

jira-product-discovery-contributors-<cloud-site-name>Grants access to contributors for Jira Product Discovery on <cloud-site-name>. (E.g.: grants contributor product access)
jira-product-discovery-user-access-admins-<cloud-site-name>Grants access to administer users and groups for Jira Product Discovery on <cloud-site-name>. Doesn’t grant any product access.
jira-product-discovery-users-<cloud-site-name>Grants access to Jira Product Discovery on <cloud-site-name>. (E.g.: grants licensed user product access)

That’s it! Everything else I found is stored at the project level. Those settings are:

new Project-Level Settings (Less Impactful)

The Jira audit log reports the following were created. These settings exist in the background and are managed by project-level admins. They are not listed with other similar schemes in the Jira application admin area. Here’s how they work.

Issue types

Jira Product Discovery Idea Issue Type
Jira Product Discovery Idea Issue Type

In JPD projects, there is only one issue type displayed with an orange light bulb icon. There are currently no settings for managing or adding additional issue types. Users can query for issues in JPD projects using the JQL statement: type = idea.

Fields

The audit log shows 1 new field configuration scheme, 28 new custom fields, 28 custom field contexts, and 7 custom field selection options. Again, all this information is scoped to the specific project. Here are the fields and the page to manage them.

JPD Project-specific Fields
JPD Project-specific Fields

As the screenshot shows, it’s also possible to leverage global custom fields, although none are added to the project by default.

JPD Project-specific and Global Custom Fields
JPD Project-specific and Global Custom Fields

Additional settings

A workflow scheme, workflow with a few specifically-worded statuses (Ex: “discovery” and “ready for delivery”), permission scheme, and notification scheme were also created. Those settings are managed in the project settings area. The menu options in the left sidebar look slightly different than in other Jira project types.

JPD Project Settings
JPD Project Settings

Group membership

Additionally, default Atlassian-created service account users like Automation for Jira, Atlassian Assist, Statuspage for Jira and more are added to the new groups noted in the “application-level settings” area above. This is done in the background and membership for these users is not managed by Jira admins.

So, what did I miss? Add your findings in the comments section below!

See also: Default Jira Global Permissions | Default Jira Project Permissions | Default Jira Notifications | Settings Created for Jira Product Discovery Projects

Jira Sandbox and Test Environment Options

It’s shocking, but many organizations don’t have a test environment! I didn’t have one when I first started out either. But I quickly saw how important it was to be able to experiment and learn without impacting production data. You need a place to see how your changes work with real-life scenarios. Here are some options, depending on whether you have Jira Cloud, Jira Server, or Jira Data Center.

Contents:

Options for Jira Cloud

Here are some test environment options for Cloud customers using the Atlassian hosted environment.

Sandbox

In Cloud, visit: admin.atlassian.com > Products > Sandbox

There’s a sandbox option built into all Premium and Enterprise plans. This is an isolated environment where you can test and experiment without impacting production. The application has the same user limit as the production application it’s linked to. The sandbox application will has its own URL which is similar to the production URL.

Read more: https://support.atlassian.com/organization-administration/docs/manage-product-sandboxes

Dev Instance

If you’re an Atlassian Marketplace developer, you can sign up for a free development instance. Developer assets are subject to the Atlassian Developer Terms, which are additional to the regular terms of service. This licenses comes with a limited number of users for test purposes. For example, you can only have 1 JSM agent user and 5 Jira Software users.

Read more: https://developer.atlassian.com/platform/marketplace/getting-started

Free Version

There’s also a free version of Cloud. It’s like the paid version, except it includes less features. For example, it doesn’t include project or issue permissions. It won’t help you test those areas. That’s why I prefer the previous ideas.

Read more: https://www.atlassian.com/software/free

Other Ideas

Another option is to get a second application instance and pay for just a few users.

You can also start a new free trial. This might be helpful if you’re testing the features of a different Cloud plan and don’t wish to upgrade or downgrade production.

Finally, if you have no better option, create a test project in your production application.

Options for Jira Server

Atlassian stopped selling new licenses of Server products in February 2021 and support ended in February 2024. But I know some of you are still using Server right now and for a variety of reasons, will continue to use it for some time.

Luckily, the installation process for Server is the same as Data Center. The difference is licensing and of course, Data Center has additional features for enterprise environments. If you still have a working server license, simply follow the instructions in my “How to Install Jira on Windows” article.

Options for Jira Data Center

Here are some test environment options for Data Center customers hosting their own software:

Per Atlassian: “Atlassian supplies “developer” licenses that can be used by existing commercial license holders who wish to deploy non-production installations of our software to use in QA/staging environments.

Read more: https://confluence.atlassian.com/jirakb/get-a-developer-license-for-jira-server-744526918.html

my.atlassian.com

There’s also a 30-day free trial available. Visit my.atlassian.com and click the “New Trial License” link.

If you have no better option, create a test project in prod.

Regardless of the method you choose, make sure you have a place to test your changes before you unleash them on your users! 

Always make sure your test environment settings match your production environment as much as possible. Don’t forget to include any reverse proxies, SSL, or load balancer settings.

The Right Strategy to Migrate Jira with Rachel Wright

“Spend 25% of your migration project auditing what you have, understanding your configuration and the apps you have installed, how much data do you need to migrate, and if you even need to migrate all the data. Upfront planning is the key to your success.”

Join Rachel Wright and Manuel Pattyn from iDalko, a Platinum Atlassian Solution Partner, as we discuss Jira migration. In this episode of iDalko Live, we cover how to plan your migration, handle Jira apps, choosing the right Jira Cloud plan for your needs, involving end users in the migration process, and more.

Listen in podcast format or read the written transcript on the iDalko website.

Migration Help
Need help migrating or consolidating your Atlassian products? Complete the form below and we'll get right back to you.
Are you migrating to a different deployment type, changing hosting environments, or merging applications?

Project Administration Links in Jira Software and Jira Service Management

If you have Jira Software and Jira Service Management, how do you know which project admin links are for Jira project settings and which are for service management features?

While both Jira Software and Jira Service Management settings work together to power support projects, it’s helpful to know which links are for which application type so you can consult the correct documentation and information.

Here’s a handy list and and some differences between links in the Cloud and Server deployment types.

Project Admin Area

To get to a project’s admin area click the “Project settings” link in any Service Management project. It’s at the bottom of a project’s left sidebar. In Jira Server, the link takes the admin to the “Request types” page by default. In Cloud, the link takes the admin to the “Details” page by default.

Service project admin in Server

In Server, the first set of sidebar settings are common to all Jira projects. Those links include: Summary, Details, Re-index project, and Delete project.

Further down the page are settings specific to Jira Service Management (JSM) projects. The first link in the section is labeled “Request types”.

The additional links below are for standard Jira project settings like issue types, workflows, screens, and more. You might also have additional links for managing third-party app settings.


Service project admin in Cloud

In Cloud, the Jira and JSM settings are ordered differently.  For example, the second section shows the Jira issue types and the JSM request types together.

Settings List

Here’s a handy list of the typical sidebar links and which application type they belong to.

Jira Software

The following settings are used by software-type projects:

  • Summary
  • Details
  • People (Cloud only)
  • Re-index project (Server only)
  • Delete project
  • Issue types
  • Workflows
  • Screens
  • Fields
  • Priorities
  • Versions
  • Components
  • Users and roles (Server only)
  • Permissions
  • Issue Security
  • Notifications
  • Project links
  • Development tools
  • Issue collectors

Jira Service Management

The following settings are used by service-type projects:

  • Change Management (Cloud only)
  • Request types
  • Customer permissions
  • Language support
  • Portal settings
  • Email requests
  • Customer notifications
  • Widget (Cloud only)
  • Satisfaction settings
  • Knowledge base
  • SLAs
  • Calendars
  • Automation
  • Apps (Cloud only)
  • Incident management (Server only)

Need help using or configuring Jira Software or Jira Service Management settings? Take my LinkedIn Learning courses to understand capabilities and best practices.


Rachel Wright’s Jira and Confluence
Admin and User Courses on LinkedIn

Default Jira Notifications


Default notification scheme (Jira Software Cloud)

Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?

To find out, visit Admin > Issues > Notification schemes in your application. Then use this baseline list to compare your Jira settings to the default.

Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!

Jira Software Cloud, Server & Data Center Notifications

Issue Created (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Updated (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Assigned (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Resolved (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Closed (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Commented (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Comment Edited (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Comment Deleted (System)

Notifications:  none

Issue Reopened (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Deleted (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Moved (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Work Logged On Issue (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Work Started On Issue (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Work Stopped On Issue (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Worklog Updated (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Issue Worklog Deleted (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

Generic Event (System)

Notifications:

  • Current Assignee
  • Reporter
  • All Watchers

See also: Default Jira Global Permissions | Default Jira Project Permissions | Default Jira Notifications | Settings Created for Jira Product Discovery Projects

Default Jira Project Permissions

Default permission schemes (Jira Software Cloud)

Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?

To find out, visit Admin > Issues > Permission schemes in your application. Then use this baseline list to compare your Jira settings to the default.

Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!

Jira Software Cloud Free & Standard Project Permissions

Scheme name: Default Permission Scheme

Project permissions

Administer Projects

Ability to administer a project in Jira.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Browse Projects

Ability to browse projects and the issues within them.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Manage sprints

Ability to manage sprints.

Granted to:

  • Project role
    • atlassian-addons-project-access

View Development Tools

Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

View Read-Only Workflow

Users with this permission may view a read-only version of a workflow.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Issue permissions

Assignable User

Users with this permission may be assigned to issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Assign Issues

Ability to assign issues to other people.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Close Issues

Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Create Issues

Ability to create issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Delete Issues

Ability to delete issues.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Edit Issues

Ability to edit issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Link Issues

Ability to link issues together and create linked issues. Only useful if issue linking is turned on.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Modify Reporter

Ability to modify the reporter when creating or editing an issue.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Move Issues

Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project they have the create permission for.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Resolve Issues

Ability to resolve and reopen issues. This includes the ability to set a fix version.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Schedule Issues

Ability to view or edit an issue’s due date.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Set Issue Security

Ability to set the level of security on an issue so that only people in that security level can see the issue.

Granted to:

  • Project role
    • atlassian-addons-project-access

Transition Issues

Ability to transition issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Voters & watchers permissions

Manage Watchers

Ability to manage the watchers of an issue.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

View Voters and Watchers

Ability to view the voters and watchers of an issue.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Comments permissions

Add Comments

Ability to comment on issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Delete All Comments

Ability to delete all comments made on issues.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Delete Own Comments

Ability to delete own comments made on issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Edit All Comments

Ability to edit all comments made on issues.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Edit Own Comments

Ability to edit own comments made on issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Attachments permissions

Create Attachments

Users with this permission may create attachments.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Delete All Attachments

Users with this permission may delete all attachments.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Delete Own Attachments

Users with this permission may delete own attachments.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Time tracking permissions

Delete All Worklogs

Ability to delete all worklogs made on issues.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Delete Own Worklogs

Ability to delete own worklogs made on issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Edit All Worklogs

Ability to edit all worklogs made on issues.

Granted to:

  • Project role
    • Administrators
    • atlassian-addons-project-access

Edit Own Worklogs

Ability to edit own worklogs made on issues.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Work On Issues

Ability to log work done against an issue. Only useful if Time Tracking is turned on.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Scheme name: Default software scheme

Same as the Jira Cloud “Default Permission Scheme” except:

Manage sprints

Ability to manage sprints.

Granted to:

  • Project role
    • atlassian-addons-project-access
  • Application access
    • Any logged in user

Jira Software Server Project Permissions

Scheme name: Default software scheme

Project permissions

Administer Projects

Ability to administer a project in Jira. 

Granted to:

  • Project role
    • Administrators
Extended project administration

Also includes a checkbox to grant extended project administration permissions.

Browse Projects

Ability to browse projects and the issues within them.

Granted to:

  • Application access
    • Any logged in user

Edit SPRINTS

Ability to edit sprint name and goal.

Granted to:  none

Manage sprints

Ability to manage sprints.

Granted to:

  • Project role
    • Administrators

Start/Complete Sprints

Ability to start and complete sprints.

Granted to:  none

View Development Tools

Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.

Granted to:

  • Application access
    • Any logged in user

View Read-Only Workflow

Users with this permission may view a read-only version of a workflow.

Granted to:

  • Application access
    • Any logged in user

Issue permissions

Assignable User

Users with this permission may be assigned to issues.

Granted to:

  • Application access
    • Any logged in user

Assign Issues

Ability to assign issues to other people.

Granted to:

  • Application access
    • Any logged in user

Close Issues

Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.

Granted to:

  • Application access
    • Any logged in user

Create Issues

Ability to create issues.

Granted to:

  • Application access
    • Any logged in user

Delete Issues

Ability to delete issues.

Granted to:

  • Project role
    • Administrators

Edit Issues

Ability to edit issues.

Granted to:

  • Application access
    • Any logged in user

Link Issues

Ability to link issues together and create linked issues. Only useful if issue linking is turned on.

Granted to:

  • Application access
    • Any logged in user

Modify Reporter

Ability to modify the reporter when creating or editing an issue.

Granted to:

  • Project role
    • Administrators

Move Issues

Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project they have the create permission for.

Granted to:

  • Application access
    • Any logged in user

Resolve Issues

Ability to resolve and reopen issues. This includes the ability to set a fix version.

Granted to:

  • Application access
    • Any logged in user

Schedule Issues

Ability to view or edit an issue’s due date.

Granted to:

  • Application access
    • Any logged in user

Set Issue Security

Ability to set the level of security on an issue so that only people in that security level can see the issue.

Granted to:  none

Transition Issues

Ability to transition issues.

Granted to:

  • Application access
    • Any logged in user

Voters & watchers permissions

Manage Watchers

Ability to manage the watchers of an issue.

Granted to:

  • Project role
    • Administrators

View Voters and Watchers

Ability to view the voters and watchers of an issue.

Granted to:

  • Application access
    • Any logged in user

Comments permissions

Add Comments

Ability to comment on issues.

Granted to:

  • Application access
    • Any logged in user

Delete All Comments

Ability to delete all comments made on issues.

Granted to:

  • Project role
    • Administrators

Delete Own Comments

Ability to delete own comments made on issues.

Granted to:

  • Application access
    • Any logged in user

Edit All Comments

Ability to edit all comments made on issues.

Granted to:

  • Project role
    • Administrators

Edit Own Comments

Ability to edit own comments made on issues.

Granted to:

  • Application access
    • Any logged in user

Attachments permissions

Create Attachments

Users with this permission may create attachments.

Granted to:

  • Application access
    • Any logged in user

Delete All Attachments

Users with this permission may delete all attachments.

Granted to:

  • Project role
    • Administrators

Delete Own Attachments

Users with this permission may delete own attachments.

Granted to:

  • Application access
    • Any logged in user

Time tracking permissions

Delete All Worklogs

Ability to delete all worklogs made on issues.

Granted to:

  • Project role
    • Administrators

Delete Own Worklogs

Ability to delete own worklogs made on issues.

Granted to:

  • Application access
    • Any logged in user

Edit All Worklogs

Ability to edit all worklogs made on issues.

Granted to:

  • Project role
    • Administrators

Edit Own Worklogs

Ability to edit own worklogs made on issues.

Granted to:

  • Application access
    • Any logged in user

Work On Issues

Ability to log work done against an issue. Only useful if Time Tracking is turned on.

Granted to:

  • Application access
    • Any logged in user

Scheme name: Default software scheme

Same as the Jira Server “Default Permission Scheme”.

Jira Software Data Center, Jira Cloud Premium, and Jira Cloud Enterprise Project Permissions

These types of Jira have archival features and additional permissions. Same as the Jira Server “Default Permission Scheme” plus:

Browse Project Archive

Ability to browse archived issues from a specific project.

Granted to:  none

Archive Issues

Ability to archive issues for a specific project.

Granted to:  none

Restore Issues

Ability to restore issues for a specific project.

Granted to:  none

See also: Default Jira Global Permissions | Default Jira Project Permissions | Default Jira Notifications | Settings Created for Jira Product Discovery Projects

Default Jira Global Permissions

Global Permissions (Jira Cloud)
Global Permissions (Jira Cloud)

Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?

To find out, visit Admin > System > Global permissions in your application. Then use this baseline list to compare your Jira settings to the default.

Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!

Jira Software Cloud Global Permissions

Administer Jira

Create and administer projects, issue types, fields, workflows, and schemes for all projects. Users with this permission can perform most administration tasks, except: managing users, importing data, and editing system email settings.

Users/Groups:

  • system-administrators
  • atlassian-addons-admin
  • site-admins
  • trusted-users-xxx (unique alphanumeric string)
  • administrators
  • jira-administrators

Browse users and groups

View and select users or groups from the user picker, and share issues. Users with this permission can see the names of all users and groups on your site.

Users/Groups:

  • system-administrators
  • site-admins
  • jira-software-users
  • administrators
  • jira-administrators
  • atlassian-addons-admin

Share dashboards and filters

Share dashboards and filters with other users.

Users/Groups:

  • atlassian-addons-admin
  • jira-software-users
  • system-administrators
  • jira-administrators
  • site-admins
  • administrators

Manage group filter subscriptions

Create and delete group filter subscriptions.

Users/Groups:

  • jira-administrators
  • jira-software-users
  • administrators
  • system-administrators
  • atlassian-addons-admin
  • site-admins

Make bulk changes

Modify collections of issues at once. For example, resolve multiple issues in one step.

Users/Groups:

  • atlassian-addons-admin
  • jira-software-users
  • site-admins
  • administrators
  • jira-administrators
  • system-administrators

Create next-gen projects

Create projects separate from shared configurations and schemes. Next-gen projects don’t affect existing projects or shared configurations like workflows, fields or permissions. Only licensed users can create next-gen projects.

Users/Groups:

  • Public, anyone on the internet, including logged in and anonymous users.

Jira Software Server & Data Center Global Permissions

Jira System Administrators

Ability to perform all administration functions. There must be at least one group with this permission.

Users/Groups:

  • jira-administrators

Jira Administrators

Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).

Users/Groups:

  • jira-administrators

Browse Users

Ability to select a user or group from a popup window as well as the ability to use the ‘share’ issues feature. Users with this permission will also be able to see names of all users and groups in the system.

Users/Groups:

  • jira-administrators
  • jira-servicedesk-users (If installed)
  • jira-software-users

Create Shared Objects

Ability to share dashboards and filters with other users, groups and roles.

Users/Groups:

  • jira-administrators
  • jira-servicedesk-users (If installed)
  • jira-software-users

Manage Group Filter Subscriptions

Ability to manage (create and delete) group filter subscriptions.

Users/Groups:

  • jira-administrators
  • jira-servicedesk-users (If installed)
  • jira-software-users

Bulk Change

Ability to modify a collection of issues at once. For example, resolve multiple issues in one step.

Users/Groups:

  • jira-administrators
  • jira-servicedesk-users (If installed)
  • jira-software-users

Browse Archive

Ability to browse all archived issues.

Users/Groups:

  • None (empty)

See also: Default Jira Global Permissions | Default Jira Project Permissions | Default Jira Notifications | Settings Created for Jira Product Discovery Projects

How to avoid the top Jira migration mistakes

As a consultant, I’ve seen a lot of different Jira configurations and helped plan many migrations, merges, and moves. Sometimes the effort is small, like moving a Jira project from one application to another. Other times it’s porting an entire application to a different hosting environment or combining multiple large instances together. Regardless of the scope or effort, organizations often make two big mistakes. They are:

Lack of Preparation

The most common mistake is poor planning. A migration is rarely a quick and easy activity. It requires many hours of discovery, multiple dry runs, and testing.

Organizations often rush to complete the effort without performing enough pre-migration analysis. They don’t take the necessary time for due diligence. When proper analysis isn’t done, impactful setting differences are missed, data is mistakenly omitted, and Jira doesn’t function the way users expect.

Examples

  • When security and permission settings aren’t handled properly, users don’t see data they expect.
  • If email settings aren’t considered, end users may receive more or fewer notifications than expected.
  • If data from third-party apps isn’t migrated, users won’t see information and functionality they are used to.

Remedy

There’s no substitute for a proper upfront analysis and verification before the final event. You need to understand the application configuration intimately, clean up unneeded schemes and settings, archive projects and issues you no longer need, and make sure the application is healthy before migrating any data.

You need to thoroughly test the migration results in a staging application, often multiple times, until everything is perfect.

Lack of Communication

The second most common mistake is poor communication with stakeholders. Before you even start the project, you need to identify the many types of impacted users, how they will be impacted, and what kind of participation is expected from each. The migration effort should never be a surprise to anyone!

Examples

  • The Finance Department wasn’t informed of the migration and had to shuffle money around when license fees increased.
  • Not all data was migrated and the Help Desk team was bombarded with user trouble reports.
  • A Developer logged in to find Jira was not connected to critical build tools.
  • The Compliance Team failed an audit because settings in the new application conflicted with company policy.

Remedy

Just like with any large company strategic initiative, Migration Team members need to a good job communicating and managing expectations. Overcommunicate at each step. At a minimum, users need to verify that their data is as expected in the staging and production environments. Involve users early and often.

To avoid these common mistakes and others, download my free 210 page book, The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud.


Migration Help
Need help migrating or consolidating your Atlassian products? Complete the form below and we'll get right back to you.
Are you migrating to a different deployment type, changing hosting environments, or merging applications?

Thoughts on Atlassian’s Server Decommission

In October 2020, Atlassian announced they will stop selling new Server licenses on February 2, 2021. Further, they will end support for Server products on February 2, 2024. This means customers like me will need to
switch to Data Center, migrate to Atlassian-hosted Cloud products, or make alternate plans.

It’s no surprise that this announcement brought a mixed reaction from the user community. There was a lot of initial shock and emotion as the online forums erupted with commentary. It took me a while to process all the information and I’m finally ready to share my opinions.

Before I do, there’s something you should know. It’s no secret; I’ve been in a relationship with Jira since 2011.

I'm Currently in a Relationship with JIRA

But before I discovered Jira, I was in love with Salesforce. I fell in love with both applications for the same reasons: both were infinitely flexible and let me configure them exactly the way I wanted. I could adapt the software to fit my needs without changing my behavior.

A well-worn Salesforce conference giveaway

I attended a Salesforce user conference and brought home a giveaway that I still have today. This little mint container displays Salesforce’s trademark “no software” logo. At first I didn’t understand. How could a software company be anti-software? The logo conveys that Salesforce said “no” to the familiar concept of hosted software and “yes” to cloud infrastructure instead. I acquired this item sometime around 2005. So ~15 years later, the fact that the software industry has pivoted to leverage the cloud is not a huge surprise. Cloud proponents might ask why Atlassian took so long to make their announcement! Don’t get me wrong, I’m a HUGE Jira Server fan and I will always love and prefer it. But asking Atlassian to develop and support multiple deployment methods, with different code bases, features, and terminology is a terrible long term business plan.

Cloud is Inevitable

This announcement was ultimately inevitable but it doesn’t mean it will be an easy road for everyone. There are certainly organizations with a real or a perceived aversion to cloud software. Some industries have complex governance and compliance regulations to consider and there are data residency concerns and latency issues to resolve. There are consultants facing real challenges with helping their clients through this transition. There are Jira Server administrators wondering if moving to Cloud means their role is unnecessary or redundant. (Not at all! Cloud applications need competent administrators to manage and maintain the configuration. There are just a few things you won’t need to do anymore. Example: a manual re-index.)

Some Options

For customers who can afford it, switching from Server to Data Center can be as easy as simply pasting in an updated license key and installing Data Center compatible apps, assuming they exist. Jira Data Center has some attractive features, like clustering (multiple applications), archival, high availability, redundancy, disaster recovery, etc, but you don’t have to use them. You can simply run Data Center as non-clustered (single) application.

For customers who are open to migrating to Cloud-hosted products, there are cost, feature, app, and user interface differences to consider. Migration is not a simple weekend project, but with adequate analysis, planning, and testing, it is doable.

I have to give Atlassian credit for announcing this change years in advance. At the very least, we all have adequate time to prepare or make alternate plans. They have visibly invested in their Cloud infrastructure and there’s still a lot of time before “end of life” to address the outstanding concerns. Atlassian has provided migration information, created a new Cloud tool to help move data, and publicly addressed our gripes – although I understand that not all will be satisfied with the responses. Some customers feel forgotten, disrespected, or excluded. I can understand that perspective and don’t intend to disregard or minimize those feelings.

Pricing Concerns

Many of us are concerned with price increases. The Data Center cost is simply out of reach for some organizations. As a consultant, I keep a Jira Server instance running simply to take screenshots, create training materials, and support my clients using Server. This is a test instance and I am the only user. My annual starter license cost is $10 USD. If I understand correctly, to simply change to a Data Center license, my annual cost increases to over $20,000 USD. This is simply impossible and unreasonable. If true, it means small consultancies like mine can’t properly support Data Center clients in the future. It’s crazy to think that I can’t afford the software I love so much and help others manage! I’ll have to try to keep my sandbox Jira Server instance running as long as possible or until it’s no longer useful for its intended purpose. For charitable and non-profit organizations, I’m happy to see that free Data Center licenses are now available.

Change is Constant

Change is hard. I understand and sympathize. But change is also constant in this world. The only thing you can control is how you react to change. I’m trying to improve the way I personally respond and in this situation, I’m choosing to find ways to see this as a positive opportunity. For example, I have the ability to help organizations determine the best path for their unique needs. I can help companies reduce risk during their migrations. And I can learn to love Jira Cloud as much as Server – or at least try.

The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud

If you plan to change to Jira Data Center, migrate to Jira Cloud, have multiple Jira Server applications to consolidate, or simply feel lost about what to do next, there’s a new resource just for you! I teamed up with Appfire to create The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud. This free 210 page ebook is the master resource to answer all your migration questions and provide a comprehensive plan to follow.

Regardless of your situation, take a deep breath, and try to work towards arriving at the “acceptance” stage of this announcement. You’ve likely survived bigger software challenges and I have no doubt you will get through this one as well. Until then, I wish you the very best of luck, success, and prosperity in the new year.

Announcing The Ultimate Guide to Jira Migrations

Software migrations are fact of life and Jira is no different. No solution fits forever and organizations must pivot as needs and industry capabilities change. As systems evolve, features grow, and infrastructure becomes obsolete migrations and consolidations are inevitable.

In October 2020, Atlassian announced they will stop selling new licenses of their Server products. Customers need to switch to Data Center, migrate to Atlassian-hosted Cloud products, or make alternate plans by Feb 2, 2024. What should you do if you have Jira Server or multiple Jira applications? There’s a lot of great migration information available, but until now, it was all scattered in different locations.

The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud

That’s why I teamed up with Atlassian Solution Partner Appfire to create The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud.

This 210 page book is the master resource to answer all your migration questions and provide a comprehensive plan to follow.

This book includes:

  • best practices for planning a migration or merge,
  • practical tips for preparation, execution, and testing,
  • a 73 step checklist so you don’t miss anything before, during, or after
  • 16 customizable worksheets for planning, analysis, and project management,
  • a quiz for determining the best deployment method for your situation,
  • and expert advice.

Download your FREE comprehensive Jira migration, merge, and consolidation guide from the Appfire website.

0
    Your Cart
    Your cart is empty. Go add some materials!Return to Shop