community.developer.atlassian.com Open in urlscan Pro
184.105.99.43  Public Scan

Form analysis
1 forms found in the DOM

POST /login

<form id="hidden-login-form" method="post" action="/login" style="display: none;">
  <input name="username" type="text" id="signin_username">
  <input name="password" type="password" id="signin_password">
  <input name="redirect" type="hidden">
  <input type="submit" id="signin-button" value="Log In">
</form>

Text Content

Loading

The Atlassian Developer Community


IMPROVED SECURITY AND USABILITY: 2025 DATA CENTER PRODUCT UPDATES

Announcements
confluence-data-center, jira-data-center, data-center
MalathiVangalapati December 6, 2024, 11:18am 1

Hello, Atlassian Developer Community!

Throughout 2025, we’ll be bringing changes to all of our Data Center products in
their next major version:

 * Jira Software 11,
 * Jira Service Management 11,
 * Confluence 10,
 * Bitbucket 10,
 * Bamboo 11,
 * and a Crowd version to be released by the end of FY25.

These releases will include upgrades that provide a more secure experience,
while enhancing the overall quality of our technical stack.


WHAT’S CHANGING?

Here’s an overview of the planned changes:

 * Upgrade to Spring 6 and migration to Jakarta 10—we’re upgrading the Spring
   version used in all products to Spring 6 due to the end of open-source
   support for Spring 5. This Spring version will no longer support Java
   EE(javax) which in turn will require us to upgrade to Jakarta EE 10. These
   changes will allow us to continue providing you with security fixes.
 * Upgrade to jQuery 3 —while Confluence and Bitbucket have already migrated to
   jQuery 3, we’re now aligning on jQuery versions across all products. This
   means a significant jQuery version uplift for products containing older
   versions of jQuery. Our current plan is to upgrade to jQuery 3, however we’re
   closely monitoring the potential of a final jQuery 4 release. This upgrade
   will make developing cross-product apps easier.
 * Removal of deprecated components from AUI 10—we’re removing components
   displaying accessibility issues: Toolbar 1 and Dropdown 1.
 * Upgrade of internal dependencies in AUI 10—we’re upgrading AUI 10’s internal
   dependencies to better support jQuery 3 and proactively address security
   issues.
 * End of support for the original theme—with the new light and dark themes that
   brought accessibility and usability improvements, we’re removing the original
   theme from all products.
 * Removal of the LESS transformer—we’re removing the ability to transform LESS
   to CSS at runtime, requiring LESS to be transpiled into CSS at compile time.
   We’ll provide CSS variables as a replacement for Look and FeelLESS variables.
 * Removal of Trusted apps—we’re removing Trusted apps to reduce the number of
   insecure entry points into the products. We’ve replaced this way of
   exchanging information between Atlassian products with more secure solutions
   that follow industry best practices, like the OAuth 2.0 protocol.
 * Basic authentication disabled by default—we’re disabling authentication with
   basic authentication by default. This is a first step towards the removal of
   basic authentication altogether as we develop and mature alternatives to
   support the remaining few use cases.

Each Data Center product may deliver additional improvements on top of these
upgrades. We’ll communicate more details in future announcements and release
notes.


HOW WILL THESE CHANGES IMPACT APPS?

Your apps will need to be compatible with the new versions of Spring, Jakarta
(and any dependencies we’ll have to upgrade to complete the migration to
Jakarta), as well as jQuery 3. If your app utilizes Trusted apps, basic
authentication, or runtime LESS transformation, you’ll need to migrate to
available alternatives. We’ll communicate these in the future when we have more
details to share.

We’re aware that these changes will require significant effort from you to
adopt. However, we strongly believe those improvements make the Atlassian
ecosystem more reliable and secure.

For those planning to attend Atlas Camp, we’ll be there to answer your questions
and guide you through the process in person. We’ll also arrange for office hours
or webinars early next year to support those of you who can’t attend.


WHAT’S NEXT?

You can expect announcements about the timing of the upcoming EAP releases of
Data Center products containing these changes. We want to give you enough time
to prepare and test your apps.

We’ll also publish the first Request for Comments (RFCs) for these updates very
soon. We’ll update this Community post with the links.


RFC-76: Updates to AUI 10 components and dependencies Request for Comments (RFC)

> RFCs are a way for Atlassian to share what we’re working on with our valued
> developer community. It’s a document for building shared understanding of a
> topic. It expresses a technical solution, but can also communicate how it
> should be built or even document standards. The most important aspect of an
> RFC is that a written specification facilitates feedback and drives consensus.
> It’s not a tool for approving or committing to ideas, but more so a
> collaborative practice to shape an idea and to fin…


RFC-75: Ending support for LESS in Data Center products Request for Comments
(RFC)

> RFCs are a way for Atlassian to share what we’re working on with our valued
> developer community. It’s a document for building shared understanding of a
> topic. It expresses a technical solution, but can also communicate how it
> should be built or even document standards. The most important aspect of an
> RFC is that a written specification facilitates feedback and drives consensus.
> It’s not a tool for approving or committing to ideas, but more so a
> collaborative practice to shape an idea and to fin…


RFC-77: Upgrades to Spring and Jakarta versions Request for Comments (RFC)

> RFCs are a way for Atlassian to share what we’re working on with our valued
> developer community. It’s a document for building shared understanding of a
> topic. It expresses a technical solution, but can also communicate how it
> should be built or even document standards. The most important aspect of an
> RFC is that a written specification facilitates feedback and drives consensus.
> It’s not a tool for approving or committing to ideas, but more so a
> collaborative practice to shape an idea and to fin…


LET US KNOW WHAT YOU THINK

We want to hear your feedback and ideas. Leave your comments under this post.

11 Likes
AndreasEbert December 6, 2024, 12:23pm 2

Thanks for the early warning.

Looking at the timeline and end-of-life of current product versions, I see an
overlap of platform 6, platform 7, and this announcement (“platform 8”?):

 * Platform 6 versions:
   * Jira 9.17 (EOL date: 26 June 2026)
   * Confluence 8.9 (EOL date: 2 Apr 2026)
   * Bitbucket 8.19 (EOL date: 12 March 2026)
   * Bamboo 9.6 (EOL date: 14 Mar 2026)
 * Platform 7 versions:
   * Till 2027
 * This announcement (“platform 8”?):
   * For product-versions released in 2025

So, for some part of 2025 and some part of 2026 all 3 platforms are supported.
So, we app vendors should also support all 3 platforms in our apps during that
period, I guess. Correct?

Any chance to postpone this until platform 6 is end-of-life, so that we only
have to support 2 platforms simultaneously?

6 Likes
rlander December 6, 2024, 12:34pm 3

Thank you for the early notice!

Our internal teams are kicking off our platform 8 investigation next week, so
this is excellent timing.

The changes for platform 8 appear relatively straightforward on first
inspection, albeit a bit tedious to implement. I also have a concern that some
of our third party libraries may have hidden dependencies on javax packages,
we’ll check that out.

For us the biggest help would be publishing a list of all impacted packages at
the earliest opportunity. With ScriptRunner customer scripts are likely to be
using some of the impacted packages, the earlier we know what is impacted the
earlier we can proactively warn our mutual customers.

Unfortunately these changes do not appear to be backwards compatible, so as
@AndreasEbert notes we will be maintaining 3 branches of code til 2026

I appreciate that this is the announcement of breaking changes for the platform,
as vendors we also need to know as soon as possible if any additional breaking
changes are being introduced by the individual product teams.

So far we are aware of the Lucene deprecation impacting Jira, is there anything
else we need to factor in to our planning?

Another key piece of information would be an indication of which product will
ship a platform 8 EAP first, will it be Confluence again? This information will
help us adjust our internal roadmaps and allocate resources appropriately to
begin work immediately when an EAP arrives.

Thank you again for the early notice!

Cheers,

Reece

9 Likes
tobias.viehweger December 6, 2024, 12:49pm 4

Hi Malathi,

thanks for the heads up - one question we have is in regards to the removal of
the trusted apps functionality. We are not sure if this also has some
implications to application links in general? We are still using an application
link to enable OAuth1a login (delegated), so we were wondering if this will also
be impacted by this announcement?

Thanks!
Tobias

5 Likes
mkemp December 9, 2024, 9:11am 5

The rest of the questions, we’ll need to get back to y’all, but I can answer:


rlander:

> I appreciate that this is the announcement of breaking changes for the
> platform, as vendors we also need to know as soon as possible if any
> additional breaking changes are being introduced by the individual product
> teams.

Ah sorry, I had intended to post everything breaking we know of so far on the
product UI side too for exactly this reason. The only others are 1) Removal of
<client-resources (use <web-resources instead. 2) Replacing Client Web Fragments
in Bitbucket with Client-Side Extensions, all existing CWF locations will gain
CSE.

They should be relatively straight forward to migrate so these will likely land
after the other changes.

5 Likes
MalathiVangalapati December 9, 2024, 9:19am 6

Thanks for the feedback, @AndreasEbert . Unfortunately, we can’t wait until the
end of life of Platform 6 due to the support timelines for Spring/Jakarta. We
need to upgrade to the latest versions as soon as possible to maintain our
security standards.

2 Likes
MalathiVangalapati December 9, 2024, 9:19am 7

Thanks for the feedback, @rlander . We hear you and agree that these are valid
concerns. We’ll aim to share a list of changes as soon as we have more clarity.
In the meantime, we plan to post probable breaking changes on DAC as we identify
them instead of waiting for a finalized list.

Regarding the EAP and product sequencing, we haven’t finalized anything yet but
will update you once we do. It’s great to hear your team is already exploring
this. We’re happy to collaborate with the community to make managing the three
branches more manageable and less painful!

3 Likes
TomRijnbeek December 9, 2024, 9:23am 8

Hi @tobias.viehweger! Unless your Application Links use Trusted Apps for
authentication, they should continue to work as normal. You can check whether
your Application Link will break by checking if it’s status is set to
“deprecated”. Normal OAuth 1 Application Links won’t see any change in
functionality, and for the majority of use cases you can safely migrate
Application Links from Trusted Apps to OAuth if you’re still using the
deprecated links.

3 Likes
lexek-92 December 9, 2024, 12:36pm 9

Are there any reasons you are able to share why it wasn’t done in platform 7?

1 Like
aragot December 9, 2024, 7:23pm 10

If you’re going to make front-end changes, can we please have a clear example of
the canonical/recommended way to add JS to the front-end? As in, should we use
require(), which require() are allowed, should we use React, etc. ?


mkemp December 11, 2024, 10:29am 11

Maybe I misunderstand what you’re saying? The changes we’re making shouldn’t
affect the following existing/standing recommendations:

 * Component system: Atlaskit is preferred, AUI is supported
 * Module system: Use require(); AMD is preferred, UMD is supported. Avoid using
   global variables (not right now, but we will be defining more AMD modules to
   allow migration). If you’re using a bundler, you can use ESM syntax which is
   preferred
   * Don’t forget to declare the web-resource dependency too!
 * Extending existing pages: CSE is preferred, Web Fragments are supported
 * Creating new pages: CSE is preferred, vanilla servlets are supported
 * Web-resource definitions: Generating them
   atlassian-webresource-webpack-plugin - npm is preferred, writing them
   manually is supported
 * Getting JS/CSS/etc onto an existing page: adding to a web-resource context is
   supported, requiring your own resources via a web panel or web item etc is
   preferred. Avoid generic contexts like atl.general and atl.admin
 * Frameworks: React is preferred

If anything stops you (we know it’s not always possible) from taking the
preferred routes I’d love to have a ticket, it helps us prioritise which
problems and extension points.

2 Likes
MalathiVangalapati December 11, 2024, 10:33am 12

Hi @lexek-92 , we considered including Spring and Jakarta updates in Platform 7
but decided not to for a few reasons:

 1. Platform 7 complexity: Platform 7 already had a lot of work, and adding more
    to the scope would have placed a heavy burden on both Marketplace partners
    and Atlassian developers.
 2. LTS release plans: Many customers plan their updates around the LTS schedule
    with specific downtime windows. To ensure we could meet the LTS timeline and
    avoid disruptions, we chose not to include these updates, as the overall
    workload would have made it difficult to deliver on time.

1 Like
aragot December 11, 2024, 1:43pm 13

Hi mkemp,

For all of your answers, there exist no public example of implementation, a lot
of libraries are supposed to be open-source but searching on BitBucket doesn’t
yield any result, and we haven’t succeeded to make large parts of it work (such
as the live-reload), and we have put the work in (6 full-stack developers and 2
front-end developers), so I’m quite confident to say no-one in the community has
a fully-functioning stack. Let’s review:

 * Component system: Atlaskit is preferred, AUI is supported → React isn’t
   available in current LTS versions of Confluence / Jira, and once React is in
   both versions of LTS, it will be a different version of React and it will be
   impossible to maintain the same code for React 16 and React 19. (We’ll ship
   in our own version of React as a remedy).
 * Use require() → Yes, that’s easy.
 * Avoid using global variables → Even in JIRA, major functions such as
   “JIRA.ViewIssueTabs.onTabReady” aren’t documented in AMD/aren’t available in
   AMD/we have to rely on guesswork.
 * atlassian-webresource-webpack-plugin - npm is preferred → Atlassian WRM (the
   webpack/npm plugin) doesn’t fully work. Despite having spend a month on it
   last year, then having hired a front-end consultant to work on it for a month
   as well: Either it wasn’t compatible with Webpack 5, or it’s
   Jira-but-not-Confluence, or we are missing a single variable that makes that
   nothing really works about it. It may seem simple for you, but it’s not — Can
   we have an example sandbox project that proves that it works in Confluence?

All of the rest is due to Atlassian WRM not working, and can be solved by
providing a sample project showing us how it’s done.

 * Web-resource definitions: Generating them
   atlassian-webresource-webpack-plugin - npm is preferred → Atlassian WRM
   doesn’t work,
 * Extending existing pages: CSE is preferred → There is no public documentation
   about it and I’ve asked the community and they say CSE are Bitbucket-only.
   Atlassian people always send the link to the global explanation of CSE, which
   don’t explain how to set it up for example for Confluence and don’t contain
   public examples of a working CSE working in Confluence and Jira beyond
   BitBucket — and any further click redirects to the server-fe repository on
   Bitbucket, which is even more global. I’m suspecting you’re browsing your
   documentation logged-in with Atlassian credentials, and don’t realize the
   redirections we have,
 * Creating new pages: CSE is preferred → Again, lacking public documentation.
 * Getting JS/CSS/etc onto an existing page: requiring your own resources via a
   web panel or web item etc is preferred → PageBuilderService doesn’t work, we
   still have to rely on WebResourceManager.
 * Frameworks: React is preferred → Can’t, until Atlassian WRM works.

It may seem a lot of work, but I assure you my question is simple: Can we see a
sample plugin, which contains Atlassian WRM, and which works in Confluence?

I’m very confident that poor architecture practices are spreading in the
ecosystem because of the lack of available information. Driving adoption of
excellent front-end techniques will impact your customer’s frontend tomorrow.
We’re really keen to adopt Atlassian WRM, React, design tokens, CSE and
Atlassian’s other guidelines for the sake of the performance of our mutual
customers. A major factor in driving adoption is providing a sample plugin that
proves that the suggested frameworks are ready for external usage.

Best regards

3 Likes
mkemp December 11, 2024, 2:29pm 14

aragot:

> For all of your answers, there exist no public example of implementation, a
> lot of libraries are supposed to be open-source but searching on BitBucket
> doesn’t yield any result, and we haven’t succeeded to make large parts of it
> work (such as the live-reload), and we have put the work in (6 full-stack
> developers and 2 front-end developers), so I’m quite confident to say no-one
> in the community has a fully-functioning stack

Yes, the documentation is lacking, but I’m pretty sure there’s a public example
for everything. Unfortunately, they’re not easy to find.

I’ll quickly respond, but if you need to reply again, but so we don’t go too far
off-topic, please instead create another CDAC thread or create Jira issues. Most
platform components have their own issue tracker, if not, SPFE is fine. If it’s
a product-specific issue, please create a jira.atlassian.com ticket

It doesn’t sound like any of these has to do with the changes in the upcoming
major versions of our products? With the exception of CSE, but it doesn’t sound
like you have problems specifically with respect to moving from Client Web
Fragments to Client-Side Extensions?


aragot:

> React isn’t available in current LTS versions of Confluence / Jira, and once
> React is in both versions of LTS

Jira:
https://developer.atlassian.com/server/jira/platform/jira-frontend-api/#code-sharing
Confluence: com.atlassian.confluence.plugins.confluence-super-batch:react-dom
(although I don’t think it’s documented anywhere)
Bitbucket doesn’t expose a version as API

I would like to have a single web-resource for all products of the same major
version in the future, first we have to do the work to get on to the same
version. For now, perfectly fine to bundle your own version of React for
products that don’t expose it or are on too old a version.


aragot:

> Avoid using global variables → Even in JIRA, major functions such as
> “JIRA.ViewIssueTabs.onTabReady” aren’t documented in AMD/aren’t available in
> AMD/we have to rely on guesswork.

Yes, sorry that’s what I meant by we still have work to do. Jira will be
defining and documenting their API here:
https://developer.atlassian.com/server/jira/platform/jira-frontend-api/#jira-api-modules
(pretty baren ATM). AUI does offer the module names in the documentation when
they exist, e.g. Banners - AUI Documentation


aragot:

> Can we have an example sandbox project that proves that it works in
> Confluence?

It should be product independant, it sounds like you might have other issues?
AUI uses Webpack 5 and is open source; it’s quite a complicated setup but it
doesn’t cover hot-reloading.


aragot:

> I’ve asked the community and they say CSE are Bitbucket-only

We currently only have CSE extension points in Bitbucket, but it’s possible to
use the page bootstrapper in any product and it’s possible to define your own
extension points on your own UI in any product too.


aragot:

> I’m suspecting you’re browsing your documentation

All our DC UI Platform documentation is public AFAIK, I personally make a very
strict point of it. Please give feedback when on developer.atlassian.com pages
and we can action it, or in the issue tracker linked from the repository.


aragot:

> Creating new pages: CSE is preferred → Again, lacking public documentation.

It’s both documented here and we have examples in the CSE repository.


aragot:

> PageBuilderService doesn’t work, we still have to rely on WebResourceManager

Please create a ticket for the specific page where you’re having problem,
ideally with a minimal reproduction repository, it should be working. Although
if you’re not having any problems using WebResourceManager, that’s fine because
it’s not going anywhere.


aragot:

> I’m very confident that poor architecture practices are spreading in the
> ecosystem because of the lack of available information.

Definitely, we’re we want to be, we’re honestly still figuring out things
ourselves. We still haven’t even finished unblocking all the modern practices
and tech stack yet.


aragot:

> Driving adoption of excellent front-end techniques will impact your customer’s
> frontend tomorrow.

Absolutely and I love that you were thinking of how to reduce bundle size by
sharing the same version of React. We (both Atlassian and vendors) can’t solve
everything at once, these RFCs are one step at a time.


aragot:

> A major factor in driving adoption is providing a sample plugin that proves
> that the suggested frameworks are ready for external usage.

A common problem we had internally too. This bootstrap project is still relevant
even if a little dated. We’ve instead been focusing on this via Atlas FE which
will add a modern FE setup to any existing plugin.

Finally, while we don’t expect it, we do take contributions and we really
appreciate them when they do come. Most DC Platform repositories live here with
the notable exception of fe-server.

2 Likes
UlrichKuhnhardtIzym1 December 16, 2024, 4:47am 15

@mkemp Please make sure you don’t ‘drop’ any of the existing Client Web Fragment
locations on the way, as Atlassian did with bitbucket.pull-request.nav which
never got fixed!

IMO CWF to CSE extension warrants a separate RFC for Bitbucket DC. Can you
please compile a list with existing non-CSE extension points and the equivalent
post migration, something like the BBDC 7 announcement a while back.

3 Likes
mkemp December 16, 2024, 1:10pm 16

Thanks @UlrichKuhnhardtIzym1, I’ll raise all three points with the Bitbucket DC
team.


 * Home
 * Categories
 * Guidelines
 * Terms of Service
 * Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled