Changelog

Access to the Get User Email and Get User Email Bulk APIs is only supported when making asApp() requests. Requests made asUser() are not compatible with these APIs.

Learn more about profile visibility on Forge apps here.

Existing Connect apps now have a simpler, automated and incremental pathway to adopt Forge capabilities. This release includes:

• Automated tooling to support the conversion from Connect to Forge

• Support for immediate version updates of Forge apps containing connectModules

• Increased compatibility for the types of connectModules that can be declared within a Forge manifest

• Support for Forge Remote Compute (preview) in the Atlassian Connect Express (ACE) and Connect Spring Boot (ACSB) frameworks.

When making a request to:

POST /rest/api/*/priority

or

PUT /rest/api/*/priority/{id}

use avatarId instead of iconUrl.

e.g.

instead of:

adopt the following request:

At present an object type in Assets for Jira Service Management can have an unbounded number of unique constraints applied to its attributes. After 31st of October 2024 we will be introducing a new limit of 2 unique constraints per object type. This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe this new limit will be sufficient for the vast majority of use cases in which Assets is utilised.

For customers with any existing object types that already have more than 2 unique constraints, we are asking these customers to please reduce these down to 2 per object type before 31st of October 2024. Not doing this will mean:

• When we are ready to begin moving you to the new Assets platform, we will be unable to do so without first disabling your unique constraints on any object type with more than 2.

• You will be able to re-enable up to 2 per object type after this is completed.

More information on this process will be released in future.

Effected public Assets REST API endpoints are:

• POST /objecttypeattribute/{objectTypeId}

• PUT /objecttypeattribute/{objectTypeId}

Both of these endpoints will begin to return a HTTP status code of 400 if there is an attempt to add a unique attribute constraint (via the uniqueAttribute property) and the limit has been reached.

If you have more than 2 attributes on an object type that you need to ensure are unique, a potential workaround is creating an automation rule to check the number of objects that can contain a particular value after an object is updated. You could then raise a Jira issue to resolve the duplicate or notify the relevant schema administrator.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

To prepare for this change, update your firewalls and other security measures to allow connections to the new IP ranges.

For more information, see IP addresses and domains for Atlassian Cloud products, which includes instructions on how to receive notifications of changes, as well as links to machine-readable lists of our IP ranges.

At present an object type in Assets for Jira Service Management can have an unbounded number of attributes. After 30th of September 2024 we will be introducing a new limit of 120 attributes per object type (which also includes any attributes inherited from a parent object). This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe this new limit will be sufficient for the vast majority of use cases in which Assets is utilised.

For the few customers with any existing object types that already have more attributes than this new limit, we are asking these customers to please reduce these numbers down to no greater than 150 per object type before 30th of September 2024. If you are one of these customers we’ll be reaching out to you to see if we can help in any way.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

After 30th of September 2024 we will be introducing new limits regarding URL, Email and Select attributes. The limits are:

• A maximum cardinality of 50 for attributes with multiple values, OR

• A total of no more than 2700 characters for all values within an attribute (single or multiple values)

Whichever is reached first.

For Select attributes these limits apply to both attribute values and options.

For example this would mean that if a URL, Email or Select attribute had 50 values, then each value can on average contain 54 characters.

This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe these new limits will be sufficient for the vast majority of use cases in which Assets is utilised.

For the few customers with existing data that breaches this limit, we are asking these customers to please adjust their data to align with the limits by 30th of September 2024. If you are one of these customers we’ll be reaching out to you to see if we can help in any way.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

The Cloud App Migration support in apps adopting Forge from Connect will continue to only support the migration of Connect modules. For more details, please refer to Limitations and Differences.