Announcement: Bitbucket Server 7.0 EAP2 release

We are pleased to announce the availability of the second Early Access Program (EAP) release of Bitbucket Server 7.0.

This EAP release is so that app vendors and customers who have written in-house apps can update their apps to ensure they will work with the public release of Bitbucket Server 7.0.

Important things to note about this EAP release:

  • As development of the release is underway, the specifics of breaking changes will evolve and there may be other minor API changes between this release and the public release of Bitbucket Server 7.0.
  • This release should not be used in production environments. For all production use and testing of Bitbucket Server, please use the latest official release instead.

Obtaining the Bitbucket Server 7.0 EAP2 release

Links to download installers and archives:

Or via the Bitbucket Server EAP Download page.

Sources are available for users with a valid Bitbucket Server license through their license details at

We need your feedback!

If you have any questions or feedback about this preview of Bitbucket Server 7.0, ask them in the Bitbucket Server category here in the Atlassian Developer Community forums, and our friendly team of developers will respond to them.

Supported platforms changes:


  • Git 2.25
  • MS SQL Server 2019

Removal of support for deprecated databases:

  • MariaDB 10.0

Removal of support for deprecated browsers:

  • Internet Explorer 11

Removal of support for operating systems

  • Support has been removed for running on Linux with kernel version older than 2.6.17
  • Support has been removed for running on Linux with glibc version older than 2.7

Noteworthy plugin API changes since 7.0.0-eap1

Update atlassian-clientside-extensions from 0.6 to 0.9

The atlassian-clientside-extensions plugin has been updated from 0.6 to 0.9. Refer to its changelog for details


Bitbucket Server 7.0 includes a major overhaul to how auditing works for the application. This includes an extended model for representing auditing data, new categorization metadata associated with every event, and changes to how audit events are provided and consumed by plugins.

Audit data model replacement

Prior to 7.0, audit events were represented by an AuditEntry on a Bitbucket Server AuditEvent. This has been replaced by a different AuditEvent, which is a cross-product replacement.

A legacy AuditEntry maps to a new AuditEvent as follows:

  • AuditEntry.getAction() has been replaced by AuditEvent.getAction()
  • AuditEntry.getProject() and AuditEntry.getRepository() have been replaced by AuditEvent.getAffectedObjects() (where a project or a repository is represented by an AuditResource)
  • AuditEntry.getDetails() and AuditEntry.getTarget() have no direct replacements, but can be represented as an AuditAttribute, which is what the system will do internally when converting from AuditEntry into AuditEvent (note that these are not guaranteed to be present on system events after 7.0, and associated data will likely be represented differently)
  • AuditEntry.getDate(), AuditEntry.getSourceIpAddress() and AuditEntry.getUser() have no replacements, but are set automatically by the system as part of processing the event, and are part of the AuditEntity constructed from the AuditEvent as AuditEntity.getTimestamp(), AuditEntity.getSource() and AuditEntity.getAuthor() respectively

Providing audit events

Prior to 7.0, plugin developers were able to add audited events to the system by annotating an event with @Audited and implementing an AuditEntryConverter. Plugin developers could also publish a Bitbucket Server AuditEvent directly. These methods of providing auditing events have been deprecated in 7.0 for removal in 8.0. These legacy methods of providing auditing events to the system do so via the deprecated AuditEntry model. The application internally makes a best effort conversion to the new AuditEvent model, which may not result in the new model being used completely.

It is recommended that plugin developers switch to using @Auditable with an AuditEventConverter. This is the new audit event provider API added in 7.0, which is used to convert directly to the new AuditEvent model. This way plugin developers can directly construct their AuditEvent and have better control over what information is included in the audit event.


The concept of audit Priority (and the associated enum) have been deprecated in 7.0 for removal in 8.0. A Priority set on an @Audited annotation will be ignored (so all events are audited regardless of priority). From 7.0 onward, using CoverageArea and CoverageLevel (via the new @Auditable annotation) can be used to attach metadata to an event to control when it should be audited.


The concept of Channels (and the associated class) have been been deprecated in 7.0 for removal in 8.0. From 7.0 onward, AuditResource's should be added to the affectedObjects property of the AuditEvent instead. AuditUtils has helper methods that can be used to create AuditResources for projects and repositories. Adding a project affectedObject ensures the audited event will appear in the project audit log, and adding a repository affectedObject ensures the audited event will appear in the repository audit log. Multiple affectedObjects can be added to a single AuditEvent if desired.

From 7.0 onward, a Channel set on an @Audited annotation will be automatically converted into a project and/or repository affectedObject, if the relevant entity is present on the AuditEntry. However it is recommended that plugin developers which to using @Auditable to be able to specify affectedObjects directly.

Consuming audit events

Prior to 7.0, plugin developers were able to listen to the Bitbucket Server AuditEvent and consume all auditing events raised by the system and other plugins. The application includes logging auditing to both a file and the database, but this allowed plugins to add additional consumers. From 7.0 onward, the application will no longer publish AuditEvent - it is only being retained as a deprecated provider API until 8.0.

Instead, any plugin wishing to consume audit events must switch to implementing the new AuditConsumer SPI from 7.0 onward.

Retrieving audit events

Prior to 7.0, certain repository and project audited actions were stored in the database, and could be retrieved via AuditService. This service has been deprecated in 7.0 for removal in 8.0. Instead, any plugin wishing to retrieve audit events should use AuditSearchService.


@behumphreys the revamped auditing in this EAP is really cool and is a great improvement on the previous implementation.

One thing I note is that large event JSON bodies seem to overflow the auditing page, a minor inconvenience but in ScriptRunner this is a common case:

Is it possible to get that text to wrap nicer? This would be useful for our customers.



1 Like

Thank you for the feedback Reece! I’ve passed it on to the dev team for the auditing project.

Best Regards,


Hi @rlander, while dev team will work on the fix, we would also recommend switching to new API (if you can) and use set of AuditAttributes to represent what you currently have in “details” JSON. Then all the attributes will show up nicely on separate lines.


Hi Manish,

Thanks for the tip, we’ll certainly look into switching to the new API in the future, we were looking for the ability to split the data out onto individual lines so its great that the new API supports that.

Right now our priority is just to get ScriptRunner compatible with BB7, I appreciate the fact you folks made the new API backwards compatible, at least for now, that makes our lives much simpler.



Speaking of which, do you folks have an ETA for the release of 7.0? Should we still be expecting it to arrive before the end of February?

Hi Reece,

The current most likely timeframe is first week of March.

1 Like

Hi Reece,

Regarding backwards compatibility, please note that while we managed to maintain compile time compatibility there is a change in behaviour in BB 7.0 in terms of how it treats audit events coming from apps using old API. Starting BB 7.0, events logged using old API will either all be logged or none be logged depending on CoverageLevel set for “Apps” area on Audit settings screen - all events will be audited if it is set as BASE, ADVANCED or FULL, none will be audited if it is set as OFF. This differs from pre 7.0 version where you could set Priority as HIGH, MEDIUM or LOW for some events and events would be audited according to value of system property Starting 7.0, Priority of events will not be respected anymore.

1 Like


With 7.0 EAP2 (and also RC1) the “view-pull-request” page (e.g., “/projects/PROJECT_1/repos/rep_1/pull-requests/1/overview”) no longer loads our <web-resource>. Seems that <web-resource> entries tied to this context are not getting loaded:


The only way I have so far succeeded in getting my <web-resource> to load in Bitbucket 7.x on the view-pull-request page is to use either <context>bitbucket.layout.base</context> or <context>atl.general</context>. But I’d prefer not to do that!

My same <web-resource> loads fine on the commit page - in other words <context></context> works fine. Only <context></context> is misbehaving as far as I can tell.

The view-pull-request screen is pretty noisy with warnings in the JS console, but no errors.

Any ideas why my <web-resource> is failing to load on the view-pull-request screen? This pretty much kills our main paid plugin completely!

1 Like

Hi @sylvie, thanks for your feedback. Have you tried using the new Client-Side Extensions that we introduced for new Pull Request page? You can find more information about them in the previous EAP posts:

Let me know if the new extensions points are enough for you to migrate existing plugin code.

We do have a different context for the new pull request page but it’s temporary a non-public API context and the name can still change: I wouldn’t recommend using it in the plugin code. You should consider using the client-side extensions only.




short question, are there plans to support OAuth 2 with Bitbucket 7?
The thing is that many CD tools need this to be able to integrate BB in pipelines and automation.


Trying to use client-side-extensions without webpack: The example does not show examples for bitbucket specific <client-web-item ... section="bitbucket.pullrequest.action">...</client-web-item>
Can you please provide some guidance on how to migrate bitbucket <client-web-item> modules.

I noticed the usual maven structure has changed a bit for CSE. For example atlassian-plugin.xml is in src and there is no src/main folder. Is that intentional?

I suggest to stick to the convention-over-configuration approach.

  1. additional configs in pom.xml would not be necessary
  2. the template would be much easier to copy and paste into existing P2 apps.

So far I have had no luck to integrate the new CSE example into an existing P2 app/add-on/plugin. The extensions/... like

do not show up in the UPM modules when added to traditional P2 app/add-on/plugin.
Note that atlassian-plugin.xml contains a lot of modules like web-resource, web-item, client-resource, component-import, component, client-web-item etc

Most of vendors will need to integrate CSE into existing apps/add-ons/plugins and rely on existing modules in atlassian-plugin.xml

Non-webpack update

When using the non-webpack approach in atlassian-plugin.xml

  <web-item key="link-plugin-js" section="bitbucket.ui.pullrequest.overview.summary">
      <label key="loading..." />
  <web-resource key="link-plugin-js-entrypoint">
      <resource type="download" name="link-plugin.js" location="link-plugin.js" />

The new module shows up in the UPM

… and the link shows up in the PR overview page :kissing_smiling_eyes:

modal-plugin error

When using the modal plugin CSE I get the following error in the browser

Warning: Failed prop type: The prop `onAction` is marked as required in `m`, but its value is `undefined`.
    in m (created by PullRequestDetails)
    in span (created by PullRequestDetails)
    in div (created by PullRequestDetails)
    in div (created by PullRequestDetails)
    in div (created by PullRequestDetails)
    in PullRequestDetails (created by PullRequestOverview)
    in div (created by PullRequestOverview)
    in PullRequestOverview (created by PullRequestOverviewRoute)
    in FocusedCommentProvider (created by PullRequestOverviewRoute)
    in ErrorBoundary (created by PullRequestTabs)

What is the CSE equivalent for <web-item .... section="bitbucket.pull-request.nav">

panel CSE missing in bitbucket.ui.pullrequest.overview.summary

Organizr and Workzone have a couple of <client-web-panel ... > that show/edit labels, duedate, digital signatures etc. Are there perhaps other recipes to get this accomplished?

Here is an example.

Hey @izymesdev, currently we do support only three types of extensions at the bitbucket.ui.pullrequest.overview.summary location:

  • button
  • modal
  • link

Based on your screenshot I think you should consider using to the modal extension type and rendering the calendar widget inside the modal container. Please check out the documentation page for more details:


1 Like

We removed the support for bitbucket.pullrequest.action client web-item with 7.0. Instead you will have to use the bitbucket.ui.pullrequest.action extension point.

I noticed the usual maven structure has changed a bit for CSE. For example atlassian-plugin.xml is in src and there is no src/main folder. Is that intentional?

You can contribute to the plugin template and create a pull request for the template repository.

When using the modal plugin CSE I get the following error in the browser

Can you share what type of extension point and extension type you are using?

1 Like

@madamczak - I understand that RHS items are covered by button, link and modal. Can you please advice how to display a custom tab on the PR overview page. This is important for our enterprise customers that use an audit trail of digital signatures that extend PR approvals.

Can you please advice how to display a custom tab on the PR overview page.

For now, we don’t have any recommended solution that is supported by the product APIs. We are using React under the hood, and there is no guarantee that DOM nodes are stable enough to inject custom HTML nodes. We are working on checking the options of adding a new supported extension point to the pull requests tabs.

Hi @madamczak - I’ve created

This should make it easier for BBS app developers to integrate with their existing P2 app products.
You get the maven-convention-over-configuration P2 prototype by running atlas-create-bitbucket-plugin

1 Like