We are developing an add-on for Jira Cloud, and there is a need to check if there is an issue type “Epic” in the project or not.
Currently, we are doing that by:
Getting all issue types of a project by using API GET /rest/api/3/project/{projectIdOrKey} with expand= issueTypes query parameter.
After getting the result, simply checking if there is an issue type name “Epic” or not in issueTypes array in the result.
This works fine if the language of the site is English. But if the language of the site is not English, then the name of the issue type in the result that Jira API sends back will be in the site’s language. It is not “Epic” anymore.
Is there any way to check if there is an issue type “Epic” in the project that works despite the language of the site? I don’t wanna translate the word Epic to multiple languages and then compare it to the name of the issue type that Jira API sends back. It isn’t a feasible solution, to begin with.
We are working on adding support for the Accept-Language header that will allow you to specify in what language you would like to get the response. You can track the progress here: [ACJIRA-1309] - Ecosystem Jira.
Any chance that we can get an App language type? Relying on a specific phrase in a language pack seems fraught with fragility… It would be better if we could have issuetype.epic for uses as described above…
Just looking into the future when Atlassian decides on a Friday to change Epic to epic in the English language pack.
While supporting the Accept-Language header makes sense as it’s part of the HTTP standard and that’s why we decided to implement it, we don’t want to overcomplicate this any further.
The reason is that relying on human-readable names of Jira entities (that as you noticed, are not guaranteed to stay unchanged over time) is not the proper way of doing things. IDs should be used instead.
And how to obtain the ID of the, say, story type? I imagine the app could show a configuration screen to the user where they would select the issue type to be treated as “story” by the app. This could be a part of the installation process.
I find the approach with prompting user to selecting what is “story”/“epic”/“other” in his/her instance a viable option (I don’t see a better alternative right now). Although, I must say that it’s still cumbersome UX for the customer: IMHO an app should be able to determine on its own which issue type is the epic one (i.e. via GET /rest/api/3/issuetype endpoint: https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-rest-api-3-issuetype-get ) and avoid requiring customers to do unnecessary manual setup.
To me, the epic issues have special meaning in Jira, just like subtasks have a special meaning. The latter you can determine with the aforementioned endpoint (by checking for ‘subtask’ field). I guess there is some technical reason we can’t have ‘epic’ field in such responses as well, isn’t it?
Do you have any other practical hints as to how determine programmatically which issue type is the epic one?
@kkercz That’s great to hear! Hope that this change will be available soon.
In the meantime, we will try this solution. It might be not 100% reliable as asking the user which one is Epic issuetype, but it is easier to implement and “good enough” for our use-case.
Thank you all for showing interest and answer my question!
I’m afraid I don’t have any tips on determining which issue type represents epic. I’d say this information should be easily available in the API and it’s unfortunate that it isn’t. I would suggest creating a feature request in the ACJIRA project for this.
I guess Atlassian is aware of the ‘problem’, it just didn’t get high on priorities so far. I’m worried that adding a new ticket to the existing pile won’t make things go smoother, will it?
Well, ACJIRA-2028 seems to be about making the next-gen API bulk; regardless of comments, I see it’s been classified as a next-gen request…
ACJIRA-1309 is about translations.
And ACJIRA-627 is about JQL returning JSF-specific fields, so that’s different. Also, the unfortunate reality is that it’s so old that probably no team has it on their radar anymore.
I’d say creating a new issue clearly stating that a way of determining which issue type represents epics in classic projects would be beneficial.
Hi! Any progress on this topic? I’m facing same problem. Get project issue type hierarchy is deprecated now. Get all issue types for user returns “hierarchyLevel” for both next-gen and classic projects. May I assume that it is now 100% guaranteed way to find Epic issue type?
