Limitations
Last updated
Last updated
Rendering of Forge custom fields is fully supported on the issue view and issue create screens. Other places use the formatter to display field values, and simple built-in components are offered for editing. There is an open feature request with Atlassian, which you can vote here:
Currently, the integration doesn't allow us to read the user's locale in the formatter. Therefore, in places like boards, the issue navigator, bulk edit view, and transition screen, only the option's fallback value is displayed - options won't be translated.
While we acknowledge the importance of various views offered by Jira, not all of them are currently supported by Forge, particularly in terms of editing.
Atlassian's promise is that eventually they introduce fully custom rendering to as many places as possible.
Currently, we are supporting only the Global (all issues) context. If you are working with different contexts, please let us know.
An option's ID, value, and translations are stored within the issue. This is necessary to make JQL search possible, but it has its downsides. When you make changes to an option, the changes won't be reflected until the field in the issue is edited manually.
One notable limitation is that custom fields, including those from other third-party apps, cannot be created within the scope of a specific project. Therefore, these custom fields must be created globally by an administrator before they can be used by the project lead.
Forge custom fields are not yet supported by Jira Service Management. Therefore, we decided to provide custom support for translated fields on the Portal and an additional Translated form panel for the Issue view. Read more in the sections dedicated to: JIRA SERVICE MANAGEMENT and Customer Portal
We plan to address this by implementing a synchronization feature that will edit all the issues with affected options in bulk. If you feel that this is a must-have feature, please .