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. 

UPD: Starting with Jira 8.17 and above, the JQL search only displays native custom field names (not translated values or IDs). As the Jira limitation still exists, we cannot fix it on our side, but we do monitor Jira updates continuously. If all your Jira users use the same locale, you might try the following workaround provided by Atlassian.

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 not all third party applications are covered. 

However, we have implemented support for the Portfolio for Jira and Easy Agile (with rare exceptions) 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 E2F app on a DC environment with 4 nodes.  On two of the nodes, when I go to create a new "Feature", it is still showing as "Epic" on the issue type field?

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

We have loads of complex scripts in the workflows, listeners that call for certain validation checks for the issue type Epic. Does replacing the word to Feature affect all these existing scripts ? Do we need to modify these scripts to use the custom field ID instead of the issue name for functioning after enabling E2F app ?

E2F app does indeed change the name of targeted custom fields. If your script references these custom fields by name, you must change these references in your script. You can also refer to the custom field by id. This has the advantage that the id will not change even when the name does. The Groovy language itself also may have a feature which supports aliases. Basically the idea would be to create a file that creates references to the custom field name that can be updated in a single file. The alias is like a virtual link in Unix programming (the metaphor is still valid if you think of it as a url link). If you equate the name as it exists in your script with the custom field as it exists on your system (name or id), you will not have to make changes to all your scripts. 

For example, let's say you have a reference to an "Epic Link" in you code like this:
string epicLink = #{Epic Link};
If you create an alias in the alias file, it would look like this:
#{Epic Link}=#{Feature Link}
 
In this example, any time "Epic Link" is referenced in a script, it will update "Feature Link" because of the alias.

Why is Issue Type displayed incorrectly on the Create Issue and Edit Issue screens?

Once you have translated Issue Type 'Epic' according to the steps described here, it may require to update your Issue type Schemes which are used. To do this, go to Administration → Issue Type Schemes, select necessary Scheme  and click Edit (though no changes needed), and then click Save.

Why some users don't see the translation?

One of the reasons is that the user profile language is different from the selected locale on the configurations page. Please note, that translation dialog contains the locale. The translations are implemented only for the locale that is selected on a screen. On the certain pages (for example -  the Special Translations page, First page of the  configuration page wizard) you are able to select the  Translate all option to implement the translation to any language. But on some native Jira pages (for example - Custom Fields, Issue Type) you need to manually input new value for each language so that the translations are displayed correctly.

Are there any known issues with other Jira plugins?

The only known issue is the interaction of E2F with Easy Agile User Story Maps. The add-on does not display translation correctly on the filters panel. Meanwhile, it does not affect its functionality.