This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL>
in any channel, and RSS updates will appear in that channel as they are posted.
What was the issue?
Before Dec, 2023, when a partner published a new app version for a paid connect app, the app upgrade flow ran for all installed apps, without checking for active licenses.
As a result, partners saw failed /installed
events for app upgrades for the connect apps that were unsubscribed but not uninstalled from the customer instance.
Tickets related to the issue: JAC Ticket, ECOHELP Ticket
What did we change?
At the time, we fixed this bug by:
Introducing checks and allowing only apps with active licenses to be auto-upgraded to new version.
In case of inactive licenses, when the customer resubscribes to the app and license becomes active, the auto upgrade works as usual.
Why are we reverting the change?
This change stopped partners from pushing security fixes among other updates to the unlicensed paid connect apps. To solve this, we would be rolling back the changes. This would be done in a phased manner rolling back 20% each day, until March 23.
By March 23, 2024, changes will be rolled back from all the customer instances.
What’s the impact of the reversion?
Reverting the changes will mean the auto upgrades run smoothly for all the apps including the ones with inactive licenses. Unfortunately, this takes us to the previous state which led to partners receiving failed /installed
events for unlicensed paid connect apps.
A Confluence 8.9 beta version is available now for testing. To find out what’s changed, check out Preparing for Confluence 8.9.
Got feedback or want to discuss this beta? Chat with us in this Atlassian Developer Community thread. The earlier we know about potential problems, the more time we'll have to fix them before the final release.
The Jira Service Management Assets REST API endpoint GET /aql/objects is now deprecated and will be removed after the 1st of May 2024. For querying Assets objects please move to the API endpoint POST /object/aql.
You should now use the endpoint POST /object/aql for all AQL queries to Assets in Jira Service Management.
As we announced in January the anyAttribute function in Jira Service Management Assets AQL will be retired after 31st of March 2024. This includes AQL queries in our user experience, Automation rules and REST API’s. Please see the community announcement for further details and guidance on how to update your AQL queries.
Instead of using:
anyAttribute = “123.123.123.123“
update your queries to refer to the specific attribute(s) you are interested in searching, e.g:
“IP Address“ = “123.123.123.123“
or
“IP Address“ = “123.123.123.123“ OR “Host“ = “123.123.123.123“
We’ve added a set of new query parameters to the v2 Get inline comment by id API endpoint and the Get footer comment by id API endpoint that allows for optional fetching of metadata properties related to the given inline or footer comment. These include:
include-version
include-versions
include-labels
include-operations
include-properties
By default, these metadata properties (besides version
) will not be included in the response unless specified.
We document a list of IP address ranges for outbound connections for Forge apps. These IP address ranges allow Forge apps to make connections through firewalls or integrate with software that has a managed IP allowlist.
In line with improving performance across more regions, we added more compute servers for Forge. As a result, we added more IP addresses to this list.
If you plan to use these IP address ranges, it’s important that you monitor Atlassian’s documentation for changes to this range. A JSON file containing this information is published to https://ip-ranges.atlassian.com/, which may aid automation.
Note: Per-app IP allow listing is still not supported
The IP address range for outgoing connections is shared by all Forge apps. Allowing connections from this IP address range will permit connections from any Forge app.
We originally published this list on Sep 19, 2023, and it’s now grown:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
52.195.248.93/32
54.65.219.119/32
43.207.238.123/32
3.114.146.111/32
54.248.180.178/32
57.180.171.119/32
13.209.252.121/32
15.165.21.19/32
43.202.223.238/32
3.34.8.241/32
3.37.121.177/32
3.34.165.169/32
15.164.153.22/32
43.201.237.75/32
13.200.51.21/32
13.200.127.18/32
65.2.173.31/32
15.206.230.70/32
3.7.242.212/32
43.205.183.186/32
54.255.41.156/32
52.77.196.9/32
18.143.11.169/32
18.142.175.136/32
54.254.13.217/32
52.220.108.50/32
3.104.191.162/32
13.238.244.22/32
3.106.172.84/32
52.65.164.184/32
13.237.143.132/32
3.105.255.118/32
3.98.151.27/32
3.96.73.34/32
35.182.178.44/32
15.156.32.59/32
15.222.164.249/32
15.156.255.184/32
18.153.162.220/32
18.157.151.173/32
3.126.237.94/32
18.196.69.189/32
52.58.86.18/32
3.77.185.155/32
16.63.156.232/32
16.63.10.60/32
16.63.133.73/32
16.63.192.113/32
16.63.86.27/32
16.63.153.19/32
54.220.63.40/32
54.154.186.82/32
52.208.56.204/32
54.76.137.153/32
34.253.103.242/32
63.34.104.55/32
13.43.10.138/32
18.132.72.151/32
13.43.238.10/32
13.43.230.20/32
13.42.94.26/32
13.41.178.119/32
18.229.170.213/32
54.232.43.18/32
52.67.212.82/32
54.94.144.45/32
15.229.167.123/32
177.71.171.149/32
3.224.137.93/32
52.55.61.132/32
54.156.218.101/32
34.194.247.143/32
3.220.210.28/32
34.231.161.126/32
34.194.73.28/32
3.231.15.71/32
54.241.128.19/32
13.56.84.222/32
52.53.140.163/32
54.193.160.145/32
54.218.196.28/32
35.160.6.102/32
18.236.52.165/32
52.43.192.52/32
34.215.254.205/32
54.214.155.219/32
54.190.195.254/32
52.89.100.78/32
Following the deprecation notice, we’ve deprecated jiraIssueGlances
and jira:issueGlance
as we have replaced with issueContext
module.
The team field has an attribute called isVisible
, which is used to indicate whether the field is active and visible to the user. It was not set to false
for deleted teams, which has now been fixed.
There were two team field types: one for Advanced Roadmaps and one for the team entity used across Atlassian products.
Since March 2023, we have been consolidating these into one type, migrating Advanced Roadmap teams into Atlassian teams.
The two team fields handled deleted teams differently in the Jira Issue API. The Advanced Roadmaps team field returned null
, and the Atlassian team field returned an object, to distinguish it from an empty field value.
This is an example JSON response of a deleted team:
1
2
3
4
5
6
7
8
"customfield_10001": {
"id": "f30a43cb-6bcf-4b48-85d6-122ef1c71851-1",
"name": "",
"avatarUrl": "",
"isVisible": false,
"title": "",
"isShared": true
}
Note that the name
and title
attributes have been set to empty string, to that user generated content is not exposed for something which has been deleted.
This progressive rollout announced earlier has started as of 13th March 2024. It only applies to Premium and Enterprise instances of Jira Software Cloud.
To further improve Plans for Jira Software Cloud, team-managed projects will no longer restrict parent association for hierarchies above epic to the same project. The restriction on lower hierarchy levels (epic to stories and stories to subtasks) remains unchanged.
This is a behavioral change on APIs that write and read parent issue associations. As a result, parent issues of epics in team-managed projects can now be from other projects.
When we roll out this change, it will then become possible to set the parent issue of an epic in a team-manager project to be an initiative issue of a company-managed project. See the below diagram for more details.
The color.border.input
token will now use the Neutral500
(light mode) and DarkNeutral600
(dark mode) base token to reach 3:1 contrast. The token is used for borders of form UI elements, such as text fields, checkboxes, and radio buttons, you can learn more about token here.
We will decrease the border width from 2px to 1px border, this approach will help to lessen the visual prominence of inputs in our UI.
Borders of interactive elements need a contrast ratio of at least 3.0:1 against their backgrounds to ensure that we comply with accessibility standards. This includes borders on actionable elements like text inputs, radio buttons, and checkboxes.
Currently, we use token color.border.input
(#091E4224
) Neutral300A
for borders with 2px width, it only has 1.3:1 ratio.
To address this, we updated color.border.input
token to use the Neutral500
(light mode) and DarkNeutral600
(dark mode) behind a feature flag, allowing us to safely monitor customer feedback and build confidence in the changes before rolling them out.
Borders for input states such as; pressed, focused, and invalid will remain at the current 2px border and existing colors. By keeping these fields at 2px it provides a clear visual point of difference for all users to understand their current focus point or fields with errors they need to address, removing the reliance on just color as the indicator.
Some exceptions don’t need to meet this contrast requirement:
color.border for UI dividers
color.border.disabled for disabled UI
Atlassian navigation (search field)
Textfield
Select
Textarea
Date time picker
Checkbox (including use in Dropdown Menu and Select)
Radio (including use in Dropdown Menu and Select)
To help demonstrate the changes, below is a collection of component comparisons.
Note
No change to pressed, focused and invalid states.
These remain at 2px and existing colors.
Bitbucket Data Center 8.19 includes all of the brand-new features, user experience enhancements, and security updates that we’ve released since the last Long Term Support release, Bitbucket 8.9.
Set up dark theme in your profile, create your first draft pull request, configure a code owners file, and get the most of dozens of other improvements.
Check out the whole bucket of new features in the release notes
To improve the speed and reliability of the labels API endpoints, we will be changing the permissions checked when querying issue labels in Jira Cloud.
Currently, the querying process, whether it's done via label field suggestions on issues/JQL search or through the use of 'get all labels' APIs (rest/api/2/label or rest/api/3/label), is too slow and unreliable for many customers. With this change, Jira Cloud will only validate site access and project access permissions when retrieving labels.
Deprecation Period: 6 months
Release Date: Sep 9, 2024
In the past, our system performed an exhaustive permission check when retrieving labels in Jira Cloud. Each label was checked to see if it was linked to any issues that the requesting user didn't have access to. If this was the case, the label would be removed from the results. As this check was done for each label and for every issue across the site, this process was extremely expensive, leading to significant slowdowns and reliability problems.
With this change, Jira Cloud will only validate site access and project access permissions when retrieving labels. The system will not apply any issue security level permissions check during label retrieval.
If a user is granted the BROWSE_PROJECTS
permission, they will have access to all labels within that project. This encompasses special permission grants, such as those granted through reporter
and assignee
system fields, as well as user
and group
custom fields.
Jira now features a new issue ID search API, which allows you to use JQL to search specifically for issue IDs. While this API only returns issue IDs, it is up to 20 times faster than the JQL search endpoints.
The Filters API now features a new approximateLastUsed
field to the response payload. This new field returns information about when a search filter was last evaluated.
The approximateLastUsed
field lets you make more informed decisions about when to synchronize your search filters, and reduce unnecessary requests for filters that are infrequently accessed. It also enables Jira admins to find and clean up unused filters.
Bitbucket Data Center 7.21.23, 8.14.6, 8.15.5, 8.16.4, 8.17.2, and 8.18.1 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Rate this page: