E2F - FAQ

Feature related fields are displayed as field ID in JQL search, why?

When you include Feature related fields to your JQL search, they are displayed as field name but when you select them, they are displayed as field ID.

This limitation is caused by the fact that JQL doesn't support translations, there's been several tickets on this like this one for instance. As soon as Atlassian resolves the ticket, we will be able to display field names in the search field as well. The good news is that we managed to make it so that epic is not displayed. 

Is this possible to configure different namings for different Jira projects?

We have been investigating this very feature (pun not intended), however, at the moment this is not possible.

The issue with this is that for some of the translations we have to rely on Jira functionality, that is custom field and issue type translation is done by Jira itself. And it is applied globally to all screens across the Jira instance, including all projects and boards.

In this context, if we attempt to apply translations by project we will need to get rid of or work around the base Jira functionality that we rely on and create an approach which will modify the UI values of the html by javascript functions and will be tied by the UI itself. And the potential solution could still be unstable and unportable across Jira versions.

That being said, we are working on the alternatives at the moment, because offering something unstable and unreliable to our users is the last thing we want to do.

We want to have the following hierarchy: Epic > Feature > Story > Sub-Task. What should we do?

There can't be the "Epic" issue type if you already have it translated ("Epic" renamed to "Feature"), because the issue type is still "Epic", even if displayed differently on the UI.

You can have such hierarchy if you create a new issue type with some other name like "Portfolio Epic" or "Epic1" or anything else rather than exactly "Epic". Otherwise there will be conflicts in Jira as it will consider them as duplicates.

Is it possible to have this epic to feature translator in Jira cloud?

Short answer - not at the moment.

Long answer below.

Server Jira and server plugins are running on the same server and we are not limited and can work with everything that we can reach. Jira cloud architecture is built in a way that cloud Jira and cloud plugin are running on different servers and communicate via a very narrow gateway, we can only work with what Jira lets us - REST API and webhooks which is not a lot.

For SAFe EPIC to Feature Translator to be possible in Jira cloud, we have to have several things in place none of which is possible in Jira cloud now, and we don't have the ability to work around this or just do it ourselves. So, until Atlassian changes the way Jira cloud is built, we don't have the ability to create any kind of E2F analogy in Jira cloud.

We do monitor Jira cloud updates of course and will create this as soon as the limitations are gone.

I plan to upgrade my Jira instance, is there any considerations if I have the E2F app installed?

Like with other apps, when you upgrade your Jira, ensure that you have the compatible version of the app installed, no additional action or configuration is necessary.

What if I use third party systems like Jira Align, how will the translations work?

Translations are made in Jira native screens only, and third party applications are not covered. 

However, we have implemented support for the Portfolio for Jira app and plan to add support for several other widely used apps in the future like EazyBI for instance.

If you have a system that uses REST services to communicate with Jira, then you have some service Jira account that makes changes to Jira entities (using which REST API calls are made). Such service account must have a non-translated locale configured in the user profile, because Jira doesn't support working with translated entities in the services.

For example, the default translations are applied to EN_US locale. This means that the service account must have a non EN_US locale, EN_UK for instance.

If I install the SAFe EPIC to Feature Translator for Jira what will happen with current filters applied on Epics?

All saved JQL filters that contain "Epic" will continue to work. 

Note that such JQL filters will still be displayed with the "Epic" in their JQL field. If you edit such filter, then the word "Epic" will be replaced by issue type ID or custom field ID, see explanation of this here.

I'm applying SAFe EPIC to Feature Translator for Jira on a DC environment with 4 nodes.  I'm running into a slight problem on two of the nodes: when I go to create a new "Feature", it is still showing as "Epic" on the issue type field; all other elements seem to be translated properly, however on the other two nodes, the create screen is properly translated to "Feature".

Go to the issue type schemes that had the "Feature" issue type and re-arrange the order of issues on the nodes that were causing the problem. Here's a link to the Atlassian Jira ticket for reference: https://jira.atlassian.com/browse/JRASERVER-64106?error=login_required&error_description=Login+required&state=79673a5c-66d6-4d66-935f-ecc697972ddb