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

[#1]

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.

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

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:

Name	Description
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

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

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

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

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!

[Bill Sheboy]

Thanks for the research, @Rachel Wright 

A few other things observed things are:

• Permissions and billing
  • With the different role / permissions model, admins need to take care to ensure who can add versus view content...otherwise there could be billing surprises
• JPD uses its own definition of a "date" field, which is a text representation of two dates to create a range, and is different from the existing date picker and date / time picker types
  • For example, here is one:
    • "customfield_10107": "{\"start\":\"2023-10-18\",\"end\":\"2023-10-18\"}"
  • The internals of this type are relevant for people writing automation rules, or using the REST API, as text functions are needed to move to / from the existing date formats
• Automation and permissions
  • The built-in Automation for Jira user has apparent super powers in that rules just "work", often without tampering with specific permissions at a project level
  • However...this does not always happen for JPD rules, sometimes requiring a change to the rule actor to a user with elevated JPD permissions.  I recall some posts that this is being investigated by the Atlassian team.
• It seems JPD is based upon team-managed projects (TMP), and so as soon as the first TMP-like project is added to a site, additional care is needed for saved filters and dashboards
  • Specifically things which rolled up together with company-managed (CMP) fields no longer do for TMP and JPD
  • This is less of a challenge for JPD as it has its own reporting / views, but may impact CMP dashboards which are imprecise in their saved filters

Kind regards,
Bill

[Rachel Wright]

Fantastic contribution! Thanks @Bill Sheboy !