Jira 9.9 EAP 01 is now on hand!

Hi, Developer Community! :wave: The first EAP for Jira 9.9 Data Center and Server is ready for testing.


Integrate Jira Software with Microsoft Graph API

Jira Software incoming mail servers can now integrate with Microsoft Graph API. The Microsoft Graph API protocol ensures robust data security in your Jira instance and protects it from unauthorized access, corruption, and breaches.

Configure empty custom fields to always appear on issues
Working with custom fields becomes easier and more efficient as we introduce the Empty custom field configuration. You no longer need to edit the issue or navigate to the issue details view each time you need to fill in an empty custom field — such fields can now be visible in the issue view.

Use the new importSettings field to manage the Developers project role

The Jira Importer Plugin no longer automatically creates and assigns the Developers project role to all project leads and assignees in the imported file by default. You need to turn it on with the new importSettings field in the config file config.create.and.assign.default.project.role.

Get a great speed-up in email notification performance

A Jira instance can now send 30,000 email notifications per minute. The previous capacity was 4,000 emails per minute.

Check more accessibility fixes for low-vision and keyboard-only users in Jira Service Management

The highlights for this release include improved roles, attributes, labels, and navigation in Assets objects and search. Check out the full list of fixed issues

Share requests with Jira groups to enhance visibility in your Jira Service Management instance

Scale up the service desk and customer management in your instance by enabling internal customers (employees) to share requests with other members of the Jira groups they’re assigned to without additional permissions.

Run imports on dedicated nodes and track the progress of the operations in Jira Service Management

You can run manual imports on the same nodes that you configure for scheduled imports. A request for a manual import operation will send a cluster message to the other nodes, so only a dedicated node will handle the import. The progression of imports and other operations will be shared across all nodes. You’ll be able to check it in the Process results tab on any node.

Test comments on approvals in Jira Service Management for Mobile

You can now leave comments when approving or declining requests in Jira Service Management for Mobile, just like in the web version of the application.

Downloads & docs
For details, check Preparing for Jira 9.9. You can download the EAP from this page. If you’re using maven.atlassian.com, the version is 9.9.0-m0005.

If you have any comments, post them below.

Happy testing,
The Jira Server and Data Center team


Hi, @DariaShatsylo ~ Jira 9.9 has Breaking changes for our app JMCF. The breaking changes are during the Custom Field configurations.

1. What has changed

The old UI, up to Jira 9.8.1 (included) used to list all the custom field contexts one by one with all the configuration options returned by List<FieldConfigItemType> getConfigurationItemTypes(), as shown below

With Jira 9.9 the UI has been implemented in React and uses an AtlasKit Dynamic Table to render the contexts and their configuration.
This is already a significant change, since the available horizontal space for each configuration item has been drastically reduced, but there are other challenges that we’ll see very soon.

Those changes are in jira/secure/admin/views/customfields/configurecustomfield.jsp , where we can also find that there’s an isUiLegacy flag to use the old UI.
In ConfigureCustomField#getIsUiLegacy we see that a global feature flag is used, so we can’t toggle that behavior for a single extension:

  public boolean getIsUiLegacy() {
    return !this.featureManager.isEnabled(JiraFeatureFlagRegistrar.CUSTOM_FIELDS_CONFIGURE_MODERN_UI);

2. What is broken :broken_heart:

2.1. The process :business_suit_levitating:

This is not mentioned at all in the Preparing for Jira 9.9 page. Why?

2.2. The layout :lipstick:

Custom fields with multiple configuration items are displayed in a suboptimal way, requiring the user to scroll even on very large screens.

2.3. The code itself :writing_hand:

Let’s see what is going on with configurecustomfield.jsp, in the ww:else block, i.e. the new UI

    <custom-field-configure-panel data-field-id="<ww:property value="fieldId"/>">
        <ww:iterator value="/configs" status="'status'">
            <ww:iterator value="./configsByConfig" status="'status'">
                <ww:iterator value="./key/configItems" status="'rowStatus'">
                    <div data-context-scheme-id="<ww:property value="../id"/>" data-context-scheme-column-name="<ww:text name="displayNameKey"/>" style="display: none;">
                        <ww:property value="viewHtml(null)" escape="false" />
                        <ww:if test="baseEditUrl && /fieldConfigureAvailable == true"><a id="<ww:property value="/fieldId"/>-edit-<ww:property value="objectKey"/>" class="actionLinks subText" href="<ww:url value="baseEditUrl"><ww:param name="'fieldConfigSchemeId'" value="../id" /><ww:param name="'fieldConfigId'" value="../key/id" /><ww:param name="'returnUrl'">ConfigureCustomField!default.jspa?fieldId=<ww:property value="/fieldId" /></ww:param></ww:url>">
                            <ww:text name="'admin.customfields.edit.value'"><ww:param name="'value0'"><ww:text name="displayNameKey" /></ww:param></ww:text></a>

Focus on this line:

`<div data-context-scheme-id="<ww:property value="../id"/>" data-context-scheme-column-name="<ww:text name="displayNameKey"/>" style="display: none;">`

Each configuration item is rendered using the template provided in getConfigurationItemTypes and hidden using CSS.
Also, since the code is looping over the available contexts, all the config items are stacked next to each other without any separation, which means that we can’t just inject a JS file to strip the display: none clause, otherwise we’d get a confusing mess in which the user doesn’t know which config item is related to which context, see below:

2.3.1. Wait, what?

An astute reader might have noticed that in the second screenshot in this page, the configuration options for PCFU’s SIL script fields are shown in the table, each correctly rendered in the row for the right context, and in the JMCF example there are a bunch of configuration columns, where do they come from and why would someone care about those hidden div elements?

The code for the React component that handles custom-field-configure-panel is minified and I don’t have a license to get Jira’s source code, so I can only guess that it’s parsing the DOM and moving the content of those hidden elements to dynamic columns in the contexts table, unfortunately, the behavior is extremely buggy.

With the old UI, custom fields can render custom HTML without limitations, including custom to the renderer for the “Search template” config item and all the columns after it are not shown, and neither is any configuration element for the second row: they’re available in the DOM with their hidden div elements. Notably, the elements for “Groovy formula”, “Format expression” and “Search template” items for the first context have been removed from the DOM, which suggests that there’s some kind of manipulation going on with those elements.

3. Workarounds and remediation :interrobang:

If your app needs tags in your configuration item types templates, the only way to do it is to inject a JS file globally, but you won’t have access to the Velocity context, FieldLayoutItem and all the other goodies inherited from FieldConfigItemType

If your custom fields have many configuration items, you probably need to combine them to prevent horizontal overflows

4. Atlassian pls:

It would be decently good if we could configure on a field level which layout to use

Thank you.


Thanks @ajay1 for raising this issue. We didn’t look into 9.9 yet as nothing seemed problematic from the notes. If that would have been mentioned, we would have definitely checked it out sooner.

@DariaShatsylo , this cannot be released like this. There are many vendors that offer custom fields in their apps and some have very elaborated UI, like in our case. Take a look at what our UI can look like in the field’s context:

And this is how it’s rendered in the new UI

Some sections are cut out/truncated while others timeout during the rendering and don’t show at all. And you tell me that this is good UX to have to click on the truncated view to open the full data set in a dialog?

I’m sorry but Atlassian has dropped the ball real bad here, and it cannot be allowed to be released as is.

1 Like

Hey @yvesriel and @ajay1!

Thank you for your comments and feedback on the changes, we really appreciate it! After meeting with our engineers and product teams, Jira 9.9 will release with this feature “off” by default. We have also started working to resolve the issues you’ve highlighted to make sure that we offer a great user experience. You can expect to see that resolved in a future Jira version.

Thank you again for your feedback and for being part of our developer community!


Good to know @RomanKolosovskiy Atassian’s Jira team’s decision on turning the feature off by default. Thank you!

Hi @RomanKolosovskiy ,

Thanks for the feedback and making sure that it will be off by default. However, I hope that you will really rethink the concept with columns as it’s not adequate for many custom fields.

Also, I would like to offer our participation in testing concepts with our custom field so that we ensure that customers will be happy with the final result.

To be honest, I’m still a little bit worried that customers can activate this to try it out. Our app is used in a lot of instances amongst some of your biggest customers. I’m afraid that there could be some backlash and they will most likely contact us before Atlassian. You should minimally let them know about this in the release notes.




Hi @DariaShatsylo

I’ve had a few inquiries from customers, will there be an option (dark feature flag or something else) for admins to disable the Configure empty custom fields to always appear on issues (hide this option, or make it impossible to change these parameters)?


Hi @RomanKolosovskiy ~ my team wanted to review the implementation of custom field improvements (More custom field improvements coming your way). Unfortunately in the latest release, we don’t see the changes even after enabling it through dark mode by adding jira.customfields.configure.modern.ui (Steps followed to enable a dark mode feature). Can you please confirm if it was added in the latest release? Thanks

@RomanKolosovskiy ~ the new change will significantly affect our JMCF app and . Unlike the pre-release changes which Atlassian documents in for e.g. Preparing for Jira x.x page,

Hey Adam,

Yes - please take a look at the notes here about the feature flag and how to enable/disable it.



Hi Ajay,

Yes - the changes are definitely there and as noted here they are behind the feature flag you indicated. A common issue we see is to make sure to please double-check if you also added the .enabled suffix.

If that doesn’t work - please let me know and we can connect to figure out what’s going on



Thanks Roman. Adding the .enabled suffix did the trick.

Hello! In regards to the Show or hide empty fields in the issue view
there’s mention of getting this information via the screens & tab API.
But how would I access this information given a issue & issuekey. We’re not seeing any information about showWhenEmpty when fetching field information via /rest/api/2/issue/{issueKey} for example. How can I in my app figure out if we’re to display the field or not, given an issuekey for a user that may not be an admin in the project.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.