Launch of Issue Context Module

Hello Atlassian Developer community,

I’m Ahmud, a product manager on the issue experience team in Jira Cloud. I want to share with you we have launched the Issue Context module. We made a prior announcement for how content from apps are displayed within the new issue view.

What’s happening?

We are moving Forge and Connect ecosystem apps from behind the glance view into their own separate group that individual users can expand/collapse. This change will make it easier for users find and update fields in the new issue view.

Why is this happening?

We received feedback from Jira Issue View customers that it can be hard to find app fields, so we’re ensuring their most important fields are visible whenever they want. Instead of their app information being hidden in a glance, they can keep it expanded in a group.

What do Markplace Partners need to do?

If you have been using the Jira issue glance module in your Forge or Connect app, you will need to replace the jiraIssueGlances and jira:issueGlance module with issueContext module. We also recommend you change CSS if needed to make sure your app looks fine in the iframe in the context section.

We have also removed the broadcast event for this feature, we recommend you make sure you load all app data.

Check out the docs to explore how to adopt the the issue context API: https://developer.atlassian.com/cloud/jira/platform/modules/issue-context/

Note: you’ll have 6 months to replace the jiraIssueGlances and jira:issueGlance as we will be deprecating the Jira issue glance module on 6th of October. After feedback from our community, we have decided to delay the deprecation till the 30th of November.

In the iOS and Android apps, the new module will be available by default, so nothing additional needs to be done, unless you don’t want your app to appear on mobile. To prevent your app from appearing on mobile, set the jiraNativeAppsEnabled flag to False.

Thanks,
Ahmud Auleear

Product Manager-Jira Issue View

1 Like

@AhmudAuleear can you elaborate on what this means?

Are you saying that we need to preload data into the context panel, even if it is collapsed?

2 Likes

@AhmudAuleear - to Anthony’s point - loading Jira issue data that is currently behind a glance would generate an enormous amount of new traffic for us. Can you clarify what Atlassian is doing here?

2 Likes

@AhmudAuleear when will the Jira Cloud mobile Apps support this new Issue context? The issue context works in web, but I can’t see anything on the mobile app currently.

Hi @ademoss,
I’m the feature lead on this project. What Ahmud meant is specified on the docs here.

This only applies to Connect apps. For the Connect glances, the app iframe is always loaded when the issue view is loaded (the iframe is not visible to the user as glances are always closed on issue load). Therefore a broadcast event (ISSUE_GLANCE_OPENED) was needed to let apps know when the user has clicked on the Glance app to open the glance and thus make the iframe visible.

For this new context panel, the app iframe will only be loaded once the panel is expanded, and will then stay loaded (even after the panel is collapsed in the same page load). So there is no longer the need to have a broadcast event. We made this decision because

  1. it ensures the issue view to load faster by freeing up resources used to load all apps behind the scene.
  2. it eliminates the flakiness and dependency that broadcast event has caused on third-party apps. With this new implementation, apps can have any implementations optimising app loading without being dependent on Jira. Your app will not need to change its implementation if we make any future changes to our extension module either.

This change may impact your app if your app

  1. listens to the ISSUE_GLANCE_OPENED. Then you would need to modify your app so it does not depend on the ISSUE_GLANCE_OPENED event. For example, if the app was fetching data when the when the ISSUE_GLANCE_OPENED event was broadcasted, you may want to modify the app to fetch the data on page load instead, or provide a button for users to request the data on demand.
    **Note: ** once the iframe is loaded after the context panel is expanded, it will stay loaded regardless of whether the panel is expanded/collapsed. It will not be reloaded again in the same page load.

  2. runs javascript in the background before the glance panel is visible. You will need to add the Background Script module to handle running scripts in the background.

Thanks,
Tina

Can you confirm it’s rolled out on all instances?

Hi @lexek-92

It’s rolled out to all non-enterprise customers. We are expecting enterprise customers to receive the change by the end of next week.

Thanks,

Ahmud

@AhmudAuleear, how do you expect me to develop / test this?

EDIT: this is an issue with the documentation. The example on https://developer.atlassian.com/cloud/jira/platform/modules/issue-context/ says that you should use

{
  "modules": {
    "jiraIssueContextPanels": [
...
    ]
  }
}

but it should actually be jiraIssueContexts, which is mentioned later in the text:

To use this module, add the jiraIssueContexts module to your app descriptor. This module uses the following properties:

@AhmudAuleear, I just noticed that the Issue Context module doesn’t resize based on the content of the panel? It seems to have a default max height of 220px, of which 48px are used by the panel header and 16px of top&bottom padding for the content, leaving us with effectively 156px height for content?

Maybe it is good to also highlight this change compared to Issue Glance in the What do Markplace Partners need to do? section, given that the Issue Glance module actually has ~100% of the height of the issue screen (minus some padding)?

It’s worth noting that the fixed height was not in the initial announcement, nor is it mentioned in the documentation. The only reference I can find is here: Future-proof your issue glance implementation but it only says that it is fixed height, it does not mention the size.

I also love how you are working around AP.resize() with a MutationObserver:

4 Likes

Would love to hear from Atlassian on this. If this is the case, we have to completely redesign one of our apps.

1 Like

Hi @AhmudAuleear,
I recently participated in the EAP of the this module and in my EAP-enrolled instance, the height is not fixed; it remains variable and adjusts according to the content.
However, if Remie’s experience is accurate and represents the final implementation for non-EAP instances, it would be a significant concern for us. Such a design choice would restrict the available space for our application, impacting its functionality and usability. Might even break it.
I sincerely hope that this is a temporary issue related to the rollout process and will be addressed shortly.

Update: Using resize:true data-options in all.js seems to fixt the problem Remie described.

Thanks,
Thomas

1 Like

After receiving a tip from @thomas1 I managed to get this working. I needed to set resize:true on the data-options attribute of the script that includes all.js.

We never use this attribute. For the other module locations, we are manually resizing our iframes (given bad experiences with Atlassian auto-resizing).

Is there a reason why resize:true needs to be set? Because I would reckon that this is a wrong interpretation of that attribute?

@AhmudAuleear @TinaLuo can you clarify the rollout timeline of this feature? Can you confirm that all Jira instances have the issue context module enabled today? If not, when is it safe to roll out this change?

We are replacing the issue glance module with the issue context module using the exact same module key so we can preserve the status issue property. I do not see any other way of doing this, without losing the info from existing status properties.
This also means as soon as we roll out this change, the issue glance disappears for existing customers, so I would like to get absolute certainty that the issue context module will show up instead for all customers.

Thanks

2 Likes

Hi @thomas1 ,
How about for Forge issue-context module? The height issue is observed in Forge module as well…

Hi @tbinna,
Sorry I didn’t reply earlier.
Yes, the issue context module has now rolled to 100% of all users.

Thanks,

1 Like

Hi @AhmudAuleear , now that the issue context module is deployed and that Apps are using it, including ours, we are wondering what is the order of these views? Aka why App X is below or above App Y.
We didn’t find anything on this on the doc or in this discussion.

4 Likes

@AhmudAuleear @DanielDelCore not sure who I should address this to, so I am tagging you both.

I am working on the issue context module and noticed two issues with dark mode:

Issue 1: Background color
The iframe body of the context module gets a background-color of --ds-surface. Why does it do that? None of the other native frames in the sidebar has this background color. I assume it is to keep it consistent with the previous issue glance module (which had this same behavior), but that does not make sense. I could add some spacing around my content to fix this, but that’s just a hack. The content would no longer align with the “Intercom” header (refer to the screenshot below).

If that background color could be removed, the look would be consistent with other frames, and we would not have to add some artificial padding around our content:

Issue 2: Status icon
The second issue affects both the current issue glance and issue context module. If the context module is closed, it displays this icon. This is a static asset referenced in the Connect descriptor. Are there plans to allow adjusting this based on the theme chosen?

3 Likes

Hi @SilvreLestang,

The logic of the ordering is the same as the glance panel which is random. We have on our roadmap the ability for users to configure the order of their panels.

@tbinna I’ll share these issues with our feature lead and get back to you.

Thanks,

Ahmud

2 Likes

@AhmudAuleear any updates - especially on issue 1? It’s important for us to get some clarity on this because the time to the deadline is ticking and we are blocked from progressing until we know if Atlassian is doing something about issue 1 or if we have to re-design the UI.

PS: The actual deprecation date is missing in your initial post. Would be good to update it with a clear deadline.

1 Like

Hi @tbinna,

We are actively looking into a resolution for the two issues you mentioned. Once we have an update I’ll post it, we are still investigating.

The deprecation date is scheduled for the 6th of October.

Ahmud

1 Like