To support these changes in your app, if you're using a Content Security Policy that sets the style-src policy, you must add the Connect CDN (https://connect-cdn.atl-paas.net) to your policy to allow these stylesheets to be injected. It's safe to remove unsafe-inline from your policy if you've been using it up until now.

The stylesheets mentioned here were included automatically via the Connect JS script, not manually by the app vendor. There are two circumstances under which Connect injected stylesheets into your app:

1. The first is only for apps which opted in to the Theming API.

   1. The theme stylesheets previously loaded via an inline stylesheet, which forced vendors to adopt the insecure unsafe-inline policy, and is the main motivation for this change.

2. The second location is only for dynamic content macros.

   1. We injected a stylesheet with CSS classes representing colors from the legacy Confluence editor.

   2. This happened without opt-in, to be backwards-compatible with macros created in the legacy editor.

   3. This injection was done via CSSOM, not inline styles, and therefore isn’t impacted by style-src CSP rules currently. However, it is also now being served from the CDN.

To summarise, all styles are now being loaded from the CDN, and the inline/CSSOM methods have been removed.

As discussed in an RFC, apps will be organized into an “Apps” item in the overflow menu and given a higher relative position. Accessing apps will require no additional clicks as apps will appear upon hover.

Note that apps in the overflow menu in live pages are already organized this way.

For guidance on how to adapt to these changes, see the deprecation notice.

We recommend making sure that your app works in live pages that may never be published and always remain live pages. Keep in mind that live pages can still be published (e.g. for use cases like knowledge bases), so make sure that your app still makes sense with published pages--both while viewing & editing them.

Continue to consider permissions scenarios around who can edit / view pages, these continue to exist in live pages (e.g. a user may have view-only permission of a live page).

Live pages will support the following page extension points. If you are using any other extension points, we recommend you migrate so that your app is accessible in live pages. As stated on October 31, 2024, we will be deprecating other Confluence page extension points (note that extension points beyond pages are unaffected). Learn more about the extension points we are deprecating here.

• Forge

  • confluence:contentBylineItem

  • confluence:contentAction

  • confluence:contextMenu

• Connect

  • system.content.action/secondary

  • contentBylineItem

  • system.content.action

  • system.content.action/primary

  • atl.general

  • system.content.action/modify

  • page.view.selection/action-panel

  • system.content.action/marker

  • atl.footer (will not render a UI component, but can still be used for running background scripts)

Bodied Macros (COMING SOON)

In December, we plan to rollout changes that make Bodied Macros like Table Filters & Aura Tabs functional in live pages. Today while editing, bodied macros only display in their “Edit” state--a text box where users can enter rich Confluence content. Users must publish to see macros in their rendered “Display” state. We will be giving users the option to switch between these “Edit” and “Display” states freely within the Editor without publishing, making them functional in Live Pages.

• When inserting a bodied macro, users will see the “Edit” state of the macro by default, so they can add content. They will need to exit the “Edit” state to see the “Display” state – now, they won’t need to publish & scroll around to see the “Display” content.

• When viewing a page with a bodied macro, users (assuming they did not insert the macro themselves) will see the “Display” state by default. They will be able to hover on the macro and enter the “Edit” mode.

We will let you know when we release these changes and we recommend testing your apps then to make sure they work as expected.

Non-Bodied Macros

As discussed in RFC-50, we’ve made it so non-bodied macros like Gliffy and draw.io, are more easily interacted with AND configured in the Editor, both for live pages & classic published pages. This has also been referred to as “removing the glass pane” from macros while editing. We recommend that you test your non-bodied macros in live pages to make sure they work as expected.

Since live pages do not have drafts and are not explicitly published, there are updated events for them. Note that live pages can still be published, which turns them back into standard published pages.

Currently, Live pages and draft/published pages will be differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API.

In the near future, we will make the subtype field available on the v2 content API, making it a stable API.

Currently, a new version is created at the end of the “editing session”, which occurs 15 minutes after the users finish making changes.

In the near future, this logic will change such that the new version is created immediately once a user makes changes, but this version will remain in flux as users make changes, and only finalized 15 minutes after the editing session ends.

We're updating how we provide packages for customers and partners to develop with our platforms. Starting February 1, 2025, we will discontinue providing third-party packages on packages.atlassian.com. Instead, customers and partners must fetch these packages directly from the original upstream repositories.

For details on how this change affects you and for guidance on migration, please refer to the documentation available at http://developer.atlassian.com .

Why is this deprecation necessary?

As we bring some of our most popular extension points into the Editor to increase their visibility & make apps functional in live-edit pages, we are deprecating extension points that do not work in the Editor or are very unpopular in the Editor to simplify how customers interact with apps, and decision-making for developers. Learn more about the other extension points we are deprecating here.

What is changing? Dates and rollout?

Starting May 8, 2025, the Confluence Cloud system.content.metadata Connect extension point will no longer be available on Confluence pages.

Migration guidance

Check the extension point locations your app is using to determine if your app is using system.content.metadata. Our documentation on Extension Point Locations as well as our Extension Point Finder for Confluence app may be useful.

Update your app configuration to use a location name that’s suitable for your app & not being deprecated. The simplest approach would be to use a location name within the same extension point, as their properties are likely the same. For example, replace the deprecated system.content.button "location" property with system.content.action/secondary, since both are web items. As a reminder, here are the extension points on pages that are not being deprecated:

• Forge

  • confluence:contentBylineItem

  • confluence:contentAction

  • confluence:contextMenu

• Connect

  • system.content.action/secondary

  • contentBylineItem

  • system.content.action

  • system.content.action/primary

  • atl.general

  • system.content.action/modify

  • page.view.selection/action-panel

  • system.content.action/marker

For more info about moving to a new location, check documentation for the location you’re trying to switch to: Content Byline Item, Web Item, Web Panel

Known issues

None so far. We will update this if any come up.

Support

Please feel free to start discussions in the Confluence Cloud category of our developer community, where we’ll be monitoring for your posts. You can also contact our developer support service desk.

Q&A

As we start to field more questions from developers/ partners we will update this section.

In further detail:

• Any macros copy + pasted from this point onwards will receive a newly generated localId

• Any existing macros with duplicate IDs will not be affected

  • This is because changing these IDs has the possibility of altering the user’s view of the page, if apps are storing data keyed against this ID

• The only caveat to the above is:

  • Cutting and pasting a pre-existing duplicated macro also triggers the paste logic, and will result in a new localId being generated

  • This does not apply to using the handles in the Confluence UI to drag the macro to a new position

Note that localIds are only expected to be unique within a given page, so if you wish to have a globally unique ID across the entire site, you should continue to use a combination of content.id and localId.

Because of this, copying and pasting a macro from one page to another will not result in the ID being regenerated, unless that ID is no longer unique on the new page (such as the macro being pasted from another page multiple times).

See RFC-59 for more information on Confluence Cloud navigation changes

To update your calendar application, visit Confluence > Apps > Calendars > “…” (next to the calendar you want to synchronise) > Subscribe and then select the appropriate app from the Calendar app list.

For step-by-step guides on setting up or adjusting Calendar Subscriptions, see https://support.atlassian.com/confluence-cloud/docs/subscribe-to-team-calendars-from-third-party-calendars/

Why is this deprecation necessary?

As we bring some of our most popular extension points into the Editor to increase their visibility & make apps functional in live-edit pages, we are deprecating extension points that do not work in the Editor or are very unpopular in the Editor to simplify how customers interact with apps, and decision-making for developers. Thank you so much to all of the developers who participated in our RFC discussing the matter.

What is changing?

Starting Apr 30, 2025, the Connect extension points page.metadata.banner, atl.page.metadata.banner, system.content.button, atl.editor.savebar, system.editor.precursor.buttons, system.content.metadata, and atl.footer will no longer display on Confluence pages to simplify the number of ways customers can interact with apps. Note that atl.footer will still be available for running background strips, but will no longer render a UI component on Confluence pages.

Starting May 8, 2025, system.content.metadata will no longer display on Confluence pages.

Dates and rollout

Starting Apr 30, 2025, we will be rolling out this change gradually. Even though we are rolling it out gradually, a portion of customers will no longer see deprecated extension points starting on that date, so plan to make and launch necessary changes before then to avoid impact to customers.

Migration guidance

Check the extension point locations your app is using to determine if any of them are being deprecated. Our documentation on Extension Point Locations as well as our Extension Point Finder for Confluence app may be useful. As a reminder, here are the Connect extension points being deprecated:

• page.metadata.banner

• atl.page.metadata.banner

• system.content.button

• atl.editor.savebar

• system.editor.precursor.buttons

• Also, the atl.footer Connect extension point will no longer render a UI component on Confluence pages, but can still be used for running background scripts only.

Update your app configuration to use a location name that’s suitable for your app & not being deprecated. The simplest approach would be to use a location name within the same extension point, as their properties are likely the same. For example, replace the deprecated system.content.button "location" property with system.content.action/secondary, since both are web items. As a reminder, here are the extension points on pages that are not being deprecated:

• Forge

  • confluence:contentBylineItem

  • confluence:contentAction

  • confluence:contextMenu

• Connect

  • system.content.action/secondary

  • contentBylineItem

  • system.content.action

  • system.content.action/primary

  • atl.general

  • system.content.action/modify

  • page.view.selection/action-panel

  • system.content.action/marker

For more info about moving to a new location, check documentation for the location you’re trying to switch to: Content Byline Item, Web Item, Web Panel.

Known issues

None so far. We will update this if any come up.

Support

Please feel free to start discussions in the Confluence Cloud category of our developer community, where we’ll be monitoring for your posts. You can also contact our developer support service desk.

Q&A

As we start to field more questions from developers/ partners we will update this section.

With the introduction of roles which are assigned ‘named collections of permissions’, space permissions for Confluence principals are now allocated via role assignment, rather than direct space permission addition & deletion. As such, the below capabilities are now available to customers enrolled in our Early Access Program in order to help power the new experience.

Our intention is to allow customers using the V1 Space permission APIs the time to investigate these new V2 APIs, and make sure that their integrations will work seamlessly when we fully release this capability more broadly over time. We welcome feedback on the APIs and their usages.

In addition, capabilities for retrieving available space permissions on a tenant, retrieving information about a specific space role by its id, and creating a space with specified role assignments are also being made available at this time.

• The Get available space permissions endpoint is primarily available to support newly split permissions on a tenant (and indicate their availability). Please see more in the announcement post.

We recommend using the above endpoints to identify existing roles and role assignments, and use the Set Space Role Assignments endpoint to add/remove role assignments that fit your use case, in place of manually assigning space permissions.

The below table indicates the V1 Space permission APIs that can be replaced by identifying and assigning roles with the new V2 endpoints.

The V1 Space creation endpoint has a direct V2 successor endpoint now available that optionally accepts an array of role assignments, roleAssignments, for a newly created space, rather than direct space permission assignments.

Finally, an additional query param has been made available for the V2 Get Space by Id GET /spaces/{id} endpoint, include-role-assignments, which will return existing role assignments within the retrieved space. The V2 Get Space by Id query param include-permissions is included in the set of deprecations associated with this change.

The below list of endpoints that directly manipulate space permissions are being deprecated.