Changelog

Previously, we announced an upcoming fix to how Forge SQL returns DATETIME column values when the time component is 00:00:00. We are now rolling out this update on Jun 5, 2026 instead of Oct 6, 2026

As this change relates to a bugfix in an underlying library dependency, deferring the update could expose the platform to security vulnerabilities. However, updating the library as scheduled means rolling out the DATETIME fix earlier than expected.

What's changing:

Previously, querying the value of a DATETIME column where the time component is set to 00:00:00 would result in only the date portion being returned. For example, the value '1970-01-01 00:00:00' would be returned as '1970-01-01'. After this update, the full value including the time component will be correctly returned ('1970-01-01 00:00:00').

This affects DATETIME column values that were set in the following ways:

1. The value was explicitly set with a time component of 00:00:00, or

2. The value was set with only the date component, in which case the time component defaults to 00:00:00.

What you should do:

If your Forge app reads DATETIME values from Forge SQL and parses the returned string, verify that your parsing logic handles the full YYYY-MM-DD HH:MM:SS format.

Why we're accelerating this:

Remaining on an outdated version of this library dependency has the potential to leave Forge SQL exposed to security vulnerabilities. We cannot responsibly defer a necessary security update to honour the original grace period. We apologise for the shortened notice and appreciate your understanding.

A new optional boolean parameter, generateAppEvents has been introduced to the following Jira Cloud REST API endpoints

• POST /rest/api/2/app/field/value - Update custom fields

• PUT /rest/api/2/app/field/{fieldIdOrKey}/value - Update custom field value

What it does: When set to false, this parameter suppresses the generation of app events triggered by the update. Specifically, it prevents issue updated events from being dispatched to:

• Forge app event listeners

• Connect app event listeners

• OAuth 2.0 app webhooks

• Admin-configured webhooks (registered via the Jira admin UI)

Default behavior: When omitted or set to true, all app events are generated as usual.

The jira:actionValidator module (Preview) now supports the workItemTypeChanged action across multiple flows, enabling custom validation whenever a user changes a work item's type. The validator is triggered in:

• Issue view - the user changes the work item type from the type field on the issue view.

• Move issue - when the work item type changes as part of moving an issue.

• Bulk move/migrate - the work item type changes as part of a bulk move or migration.

• Convert to subtask - when a standard work item is converted to a subtask type.

• Convert subtask to a work item - when a subtask is converted to a standard work item.

Also, a new context variable newIssueTypeData (type: IssueType) has been onboarded alongside the existing newIssueType (type: String, returns the issue type ID), allowing more refined conditions on the target work item type within your Jira expression.

Read more here - https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-action-validator/#workitemtypechanged

A filter to breakdown usage of function compute by compute type (sync or async) is now available in the Forge Developer Console’s Usage and Charges section.

• Sync: Synchronous function executions.

• Async: Asynchronous function executions.

This filter is available on the detailed Usage view of Functions - compute usage and the Site breakdown view.

No action is required. However, we recommend using this filter to understand your asynchronous compute consumption before billing for this compute type begins on July 1, 2026. For more context, see our previous announcement: CHANGE-3120

We’ve added an optional urlFormat field to the webtrigger module in manifest.yml so you can choose which URL format Forge uses for each web trigger. This field accepts two values:

• v1: uses the existing app-based URL format, and remains the default when urlFormat isn’t specified (for backwards compatibility).

• v2: uses a new installation-based URL format with an improved domain and path. Use v2 for new web triggers and when you want to opt in to the newer URL style.

Future web trigger capabilities will require urlFormat: v2, and at that point urlFormat will become a required field.

We've added new components to UI Kit, now available in Preview in the latest version of @forge/react:

• Bleed

• Breadcrumbs

• BreadcrumbsItem

• Pagination

For implementation details and examples, see the documentation links for each component.

Forge custom fields can no longer be edited through the legacy bulk edit wizard (/secure/views/bulkedit/BulkEditDetails.jspa). On the legacy screen, they now appear under Unavailable actions with a redirect message.

Forge custom fields remain fully supported in the new bulk edit experience, available from the list view, backlog view, and JQL search page.

You can now migrate a Connect Jira Issue Field module to Forge's Custom Field module. The functionality is now available for Text (text) and Rich Text (rich_text) fields.

See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/#text-and-rich-text-fields for more details.

The boolean usages of the autoFocus prop have now been removed from @atlaskit/modal-dialog. The previously default value of true, which automatically moves focus to the first interactive element within the modal, is now the default with no option to set it to false. This is to improve accessibility and follow the WCAG guidelines for focus within a modal dialog.

Boolean usages of autoFocus can be removed by running the included codemod.

EDITED 8 May 2026

Hello Marketplace partners,

We're excited to share that the newest improvements to Atlassian’s design language is here, as you may have seen at Team '26!

• Tile & Object system

• Spotlight component

• Shape – Border & Radius foundations

• Labelling system (for status and categorisation)

• Motion foundations

These build upon on our refreshed visual language that launched last year at Team ’25 (including colour, typography, and iconography that many of you already adopted). It makes it even easier to build modern UI that is cohesive across Atlassian and Marketplace apps, with better visual clarity and accessibility.

We will be shipping these improvements to components, design tokens and guidance as part of the Atlassian Design System (ADS), and Forge UI Kit will also receive updates.

The Tile & Object system replaces inconsistent custom tile-like UI elements — previously scattered across products with mismatched sizes, radii, colours, and naming conventions. We now offer a single, coherent standard for representing tasks, pages, objects, and app icons.

Changes are coming to Avatar, Icon tile, Tile and Object packages to align with the new Tile system. The Icon-object package has been deprecated and replaced by Object.

Before/After of Tile System in Jira

We are introducing a modernised onboarding component for product tours and user engagement flows consistent with our improved design language. The new Spotlight replaces the deprecated Onboarding component.

Before: Onboarding Component

After: Spotlight Component

New design tokens for border widths and corner radii bring consistency to the shape language across Atlassian UI. Atlassian Design System components will be updated as well as the @atlaskit/tokens package.

Together, these foundations ensure components feel more unified and polished — rounded corners and border styles will follow a consistent system rather than being defined ad-hoc per component. For more information on whats to come, check out our border width and radius docs.

New radius tokens

New border width tokens

We’re introducing a more intuitive, accessible, and scalable labelling system that standardises consistent presentation of statuses and categorisation, supporting app-specific needs while maintaining coherence and visual clarity.

We’ve updated the visual appearance of Lozenges, Tags, and Badges to have the right level of prominence in the UI, and look and feel harmonious in every context they show up. Lozenges can now included a trailing metric, and we are introducing a new Lozenge dropdown variant, as well as a new Avatar tag to represent individuals, teams, or AI agents.

Additionally, to provide greater visual distinction and hierarchy between Lozenge and Tag, subtle Lozenge will be deprecated and need to be migrated to the new default Lozenge appearance, or where applicable to Tag instead.

Updated components: Badge, Lozenge, ad Tag

New components: Lozenge Dropdown and Avatar tag

Motion breathes life into every interaction and brand moment within apps, helping users understand spatial relationships, confirms their actions, and carries branded human expression across experiences. Our approach to motion introduces a systematic, shared language, enabling you to make good motion the easy default, not an exception.

In the initial release, we will be introducing semantic motion tokens and base tokens as the foundation of the system. Uplifted and new motion in key Atlassian Design System components are coming, as well as an improved motion primitive to replace legacy entering components and simplify applying entry and exit transitions in UI.

Learn more about how we think about motion on atlassian.design.

Motion package before vs after

We'd love to hear from you — please share on the Atlassian Developer Community!

The nodejs20.x runtime for Forge apps has reached the end of its deprecation period and is no longer supported.

Starting May 6, 2026, Atlassian will progressively block the ability to deploy or update apps using the nodejs20.x runtime. Existing deployments will continue to function, but they are provided "as-is" without support or warranties. Over time, apps using unsupported runtimes may become non-functional or vulnerable to security issues.

You must update your app's to a supported Node.js runtime (nodejs22.x or higher) to continue deploying updates.

1. Edit your app’s manifest.yml file

2. Update the app.runtime.name property to nodejs22.x or nodejs24.x

3. Update your local development environment to a supported Node runtime

4. Update your Forge CLI to the latest version

5. Run npm install to update your dependencies

6. Test your app for compatibility with any breaking changes in the Node runtime

7. Deploy your app to production using forge deploy -e production

For detailed instructions, see the Node.js runtime documentation.

We are announcing the deprecation of https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-glance/ (jira:issueGlance), as we have replaced with https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-issue-context/ (jira:issueContext) module. The Jira Issue Glance module will soon be removed from the work items completely.

Please refer to the following documentation for more details - https://developer.atlassian.com/cloud/jira/platform/future-proof-issue-glance-implementation/

We’ve updated Forge app upgrade behaviour for apps that add the storage:app scope to their manifest, including apps migrating from Connect to Forge.

Previously, some app versions that added storage:app could be rolled out using bulk upgrade. This behaviour changed on April 30, and is currently not supported. When a new app version adds storage:app, the upgrade requires site admin approval and can't be applied through bulk upgrade.

This behaviour applies when a new app version adds storage:app to the Forge manifest. It may affect apps adopting Forge-hosted storage, including apps migrating from Connect to Forge.

If your app already has storage:app in its manifest, this change does not affect upgrades that do not add new privileged scopes.

If you plan to add storage:app:

• release the change as a major version upgrade

• expect site admins to approve the new version

• for now - don't rely on bulk upgrade to move existing installations to that version

• consider how you will support customers who remain on the previous version until they approve the upgrade.

What’s Next

Atlassian is actively investigating restoring storage:app as a scope increase that is able to be managed by bulk upgrade

The ability to build a custom Teamwork Graph connector using Forge is now in GA. Connectors allow your app to ingest data from external tools into the Graph, associate it with Atlassian objects (for example, work items), and make the data available to customers in platform experiences like Chat, Search and Agents.

Following Forge modules - jira:customField, jira:customFieldType and jira:issuePanel can now run for unlicensed and anonymous users in Jira and Jira Service Management. This means your apps will work on publicly accessible pages and for users who don't have a full Jira and JSM license.

By default, Forge apps only run for licensed Jira and JSM users. To allow your app to serve unlicensed and anonymous users, add the unlicensedAccess property to your modules in manifest.yml.

Please refer to following guide for more details - https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/#introduction.