Last year, we published a blog regarding the development of our new site rename feature, including information on the impact of this feature on your Cloud apps.
The feature allows customers to rename their site from foo.atlassian.net to bar.atlassian.net. Since April, this feature has been available to customers via submitting a Support request. We action a site rename request based on the criteria that the ecosystem apps installed on a customer's site are compatible with our feature
Over the past few months, we have been reaching out to vendors to verify the compatibility of their apps with our feature. This is an ongoing process and we have listed vendors who have confirmed with us on this public ticket here (CLOUD-10809 – Ecosystem vendors that are compatible with the Cloud Site Rename feature). If you want to verify your apps’ compatibility with us, want to test the feature on your site or have questions, please reach out to us via here.
We are actively developing a self-serve option for customers and the site rename feature is expected to be available to customers via the Admin UI in the near future.
Concurrently, we are working on enabling customers to have custom domains. The custom domains feature enables customers to configure their Atlassian products to be accessible via a custom domain e.g. the customer can change the site URL from foo.atlassian.net to jira.foo.com. We'll be engaging with vendors soon on the impact of this work.
What is required to be compatible with site rename?
To recap from our last blog, we have decided to leverage an existing lifecycle method, “installed”, to update the installation and send a new payload with the new base URL of the site. Everything else will be the same, and the payload will be signed with the existing shared secret. This change will have an impact on your app when:
- your app cannot process the new installed payload and update the base URL in its database.
- your app uses the base URL as a primary key to identify a specific Jira or Confluence site. We recommend using the client key for this.
- your app stores full urls (including base URL) (a Jira issue URL for example)
Your app can use the existing site name to reach Jira or Confluence APIs for some time period. These requests will be slower due to redirects so we do recommend apps update promptly to the new site name. Please also note that your Connect app must use an HTTP client library that can handle redirects. However, if you have used the site name as some sort of key in your data storage, you will need to make changes to be compatible with our feature.
FAQ
I'm using Atlassian-Connect-Spring-Boot or Atlassian-Connect-Express, am I compatible with the feature?
If you are using the storage mechanism provided by Spring Boot or Atlassian Connect Express and have not implemented your own storage layer, you will be compatible with the feature. All versions of spring-boot are compatible.
As an
As you can see whenever an ‘installed’ callback is received all the payload is used to update the record in database.
On top of updating the record you need to make sure that:
- You don’t use the base URL as a primary key for any other table
- You don’t store or leak the base URL somewhere else, and always read the base URL from the addon settings table (or equivalent) if needed
When a site gets renamed, does the tenant's client key change?
No, the tenant's client key remains the same. Only the base URL is changed.
Are you actively renaming customers?
Yes, we've been actively renaming customers since April. Customers and Vendors can request for their site to be renamed via a Support request.
Does the old site URL redirect to the new one?
Yes it does. We retain a history of all site names used by the customer. Upon accessing an old site URL, the customer will be redirected to the new site URL.
How long do you retain the site name history for?
We are currently retaining site name entries from the customer's history to enable redirects and support customers transition from their old site name to their new one. However, in the long-term we will review the data around the usage of our feature and determine when we would start releasing these previously used site names.
Is there a limit on how many times a customer can rename a site?
The current limit is five renames per site. If you require more renames for testing purposes, please let us know.