Duplicated Issue Types with different IDs - how to work with context parameters now?

Jira Development Jira Cloud
, ,
1

Hi! Some time ago we’ve noticed that Issue Types had started to have “duplicates” - the issue types with the same name and avatar, but different IDs. These “duplicates” seem to be project-scoped:

/rest/api/2/issuetype

[
  {
    "self": "https:\/\/....atlassian.net\/rest\/api\/2\/issuetype\/10100",
    "id": "10100",
    "description": "A user story. Created by JIRA Software - do not edit or delete.",
    "iconUrl": "https:\/\/....atlassian.net\/...&avatarType=issuetype",
    "name": "Story",
    "subtask": false,
    "avatarId": 10315
  },
  {
    "self": "https:\/\/....atlassian.net\/rest\/api\/2\/issuetype\/10207",
    "id": "10207",
    "description": "Stories track functionality or features expressed as user goals.",
    "iconUrl": "https:\/\/....atlassian.net\/...&avatarType=issuetype",
    "name": "Story",
    "subtask": false,
    "avatarId": 10315,
    "scope": {
      "type": "PROJECT",
      "project": {
        "id": "10406"
      }
    }
  },
  {
    "self": "https:\/\/....atlassian.net\/rest\/api\/2\/issuetype\/10200",
    "id": "10200",
    "description": "Stories track functionality or features expressed as user goals.",
    "iconUrl": "https:\/\/....atlassian.net\/...&avatarType=issuetype",
    "name": "Story",
    "subtask": false,
    "avatarId": 10315,
    "scope": {
      "type": "PROJECT",
      "project": {
        "id": "10402"
      }
    }
  },

When going to the Jira Issue Types page, however, I can’t see any duplicates there (Jira settings -> Issues -> Issue types).

The problem is, in our Connect Descriptor we use issue type IDs to understand the current context: ?id={issuetype.id} And it seems that Jira now sends those “scoped”/“duplicated” IDs, so we can’t correspond these arbitrary IDs to their “generic” type.

Given the example above, Jira may send an issue type ID “10200” or “10207”, and it would be a “Story”, which on the Issue Types page is represented as ID “10100”. This makes working with issue types context seemingly impossible. :frowning:

Could you please clarify:

  • what is this change, how it is planned to unfold and what is the final goal of it?
  • how can we work with the issue type context now that every new project seemingly has its own set of Issue Type IDs?

Thank you!

2

Hi @k.menshov,

What you are seeing is a side-effect of the next-gen projects. To answer your first question and give you some more context regarding next-gen projects, you can read this post here from @mythili. Jira Cloud next-gen projects and Connect apps

The next-gen projects simplify the project configuration experience and allow non-jira-admins to create projects and configure them. All project configuration entities in these next-gen projects like issue types, statuses, and custom fields – are scoped to the project. Schemes don’t exist in these projects. Project configuration entities that are created within a next-gen project are only available to that project.

In terms of how to work with them, any issue type with a PROJECT scope are from next-gen projects and will always be scoped to that specific project, and these won’t show up on the main issue type page. Instead, these issue types will show up on the issue type page under the project settings of the project they are scoped to. The issue type that does not have a scope is the Global Issue Type that are used in Classic projects.

Hope that helps,
Edward Zhang
Senior Development Team Lead, Jira Platform

3

Hi @ezhang,

thank you for your reply, it does help to understand the situation, but unfortunately, as I suspected, this presents a big problem when working with Jira context parameters.

At the moment the documentation for context parameters only mentions the issuetype.id. But now with any new NextGen project created there will be a new set of IDs - one for each issue type. So, what do we do if we want to know which issue type an add-on is called for (e.g. is it a “Story” or a “Bug”)? Do we have any other way to know it besides issuing a separate synchronous call to Jira API to fetch an issue type object by its ID?

A separate synchronous call would be very problematic, because it would increase the add-on loading time up to a few seconds. We first get the issue type ID from the context parameter, then we GET the issuetype object from API, and only then we know which issue type we are dealing with. :frowning: Is there any better way to do it?

Kind regards,
Kirill

4

How are you determining if an issue-type is a “Story” or a “Bug” for classic projects?

5

We just used IDs instead. Since all projects had the same set of issue types we didn’t really have to know anything except the IDs and could leave the config to users. So if they wanted to “apply the add-on to Bugs in all of my projects”, we just stored the “Bug” issue type’s ID and then used the ?id={issuetype.id} context parameter to compare.

So “apply the add-on to Bugs” would’ve looked like “apply the add-on to 10100”, and that’s it.

But now not only ID doesn’t tell us anything about the issue type, also new IDs are constantly being created. How can we implement the “apply to Bugs” scenario then?

6

Classic projects will continue to use the “Bug” issue type that you have been using. In the API, these are the issue types returned without the scope .

Next-gen projects have their own issue types. These issue types are not shared with any other project. As issue types within a project can change and be renamed depending on what the project owner wishes to do, there isn’t a clean way to create equivalence between issue types across projects or with classic.

In the example above, 10406 is one such project.

So what this means, is that in order to understand the current context, you will need both the {issuetype.id} and the {project.id} or {project.key}

For classic projects, the {issuetype.id} will match the Issue Types page.
For next-gen projects, the combination of {issuetype.id} and the {project.id} or {project.key} will tell you which issue type is being referenced.

For next-gen projects, it may make sense to ask the “apply the add-on to Bugs” question on a per-project level, as issue type decisions are made at that level, rather than globally. A project settings page can be added using this: Project settings UI locations

Hope this was helpful :slight_smile:

7

Thank you, it was. :slight_smile: It confirms my assumptions, and we most probably will explore the per-project configuration way.

I just wanted to mention that this new approach effectively makes the issuetype.id context parameter not informative. It would be great to have some other too, like projects and issues do with *.key Something like issuetype.name maybe. But I do understand that even if it gets in the schedule, it will probably take time. )

1 Like
8

@ezhang my add-on relies on context-parameters and does not request any scopes or use the API to look up information. If the context-parameters would include the Issue Type’s name (rather than just the ID), this would save me from adding these scopes and needing access simply to look up this name. More background on what I would like to do here

Is this something your team could consider adding to the context parameters?