ETA for custom domain lifecycle payload changes

Jira Development Jira Cloud
,
1

Hi,

Following on from Ecosystem support for custom domains - Atlassian Developer Blog I was wondering whether someone at Atlassian could tell us when we should expect to see the new lifecycle payloads, so that we know how to prioritize the work necessary to support that payload?

Thanks,
Jon

1 Like
2

Also, will multiple display URLs be supported?

3

We expect to start a progressive rollout of these fields next week (25 Nov onwards).

I note that these fields, when present, will contain the same value as the current baseURL field. You will not see any unique values in these fields until we commence rollout of the underlying custom domains feature.

Due to the progressive rollout you will see these fields included for some sites but not for others for the duration of the rollout.

4

At present we are not planning to support multiple custom domains for a single site.

Update:
It would be more accurate to say we are not planning to support multiple custom domains per product. In the longer term Jira, Service Desk and Confluence could all have separate custom domains for a single Atlassian instance.

So example.atlassian.net might have associated custom domains: wiki.example.com, issues.example.com and support.example.com

1 Like
5

If we were to miss a lifecycle payload with this information in it, or not store it because we were not ready in time (and right now we are not ready), how would we get the data about custom domains?

1 Like
6

Any chance we can get all of this documented in a central doc repo somewhere (before it launches)?

1 Like
7

The documentation has been updated.

Rollout has commenced so you may see the new fields on some installs.

Note: this is the rollout of these fields in the install payload and not the rollout of underlying custom domains feature. For the time being the values will just be based on the site baseUrl

8

Are these new fields going to be supported by Atlassian Connect Express? Currently, ACE exposes the base url in the handlebars context, it would need to expose these two alternate base urls as well…

2 Likes
9

@cmacneill could it be that atlassian-connect-spring-boot and atlassian-connect-express (as David mentioned above) have not been updated with these changes yet? Maybe I have missed it but couldn’t find anything when browsing the source.

If not, do you have a rough timeline of when is Atlassian is planning to update these frameworks?

We wanted to get our own AC implementation ready for these changes and normally draw some inspiration from atlassian-connect-spring-boot but it seems Atlassian’s own AC implementations are not ready yet for this change.

As the rollout is already in progress, how can we get these details if we miss them now (@jmort’s question above)?

Thanks!

10

Yes, updates are planned for the two frameworks. Getting the install payload changes done is a first step and well in advance of the custom domains feature going live. We wanted to make sure just having the fields present does not cause any issues in the ecosystem. They will not contain any distinct information for a while yet.

When a custom domain is added to a site you will receive an updated install payload (similar to the mechanism used to handle site renames) so there is no danger you will miss any information.

1 Like
11

Thanks for the explanation @cmacneill! If I understand you correctly, our apps won’t actually see the new “installed” payload until this feature is made available to all customers (apart from maybe some early access testers?).

12

@tbinna not quite. The new install payload fields will be present before the custom domains feature is available. In that timeframe, the values will be the same value as the current baseUrl.

Only once custom domains feature is enabled will you start to see distinct values in these fields.

13

Hi @cmacneill, just wanted to clarify something, because I am a bit confused with the following sentence.

These fields may or may not be present on any particular installed payload

So the “these” refers to the displayUrl and the displayUrlServicedeskHelpCenter and not to the baseUrl, which we have to expect to be always available. Am I right ?

Thanks

1 Like
14

You are right. baseUrl will always be available

15

We’ve paused the rollout of this change. We’ve discovered that certain Connect SpringBoot configurations can cause an app to reject installs if an unexpected field in present. We expect this configuration to be relatively rare but we are putting a mitigation in place.

The Details

In a SpringBoot app, by default Spring will configure the Jackson deserializer to ignore unknown fields. This is the desirable behaviour. If, however, your app creates its own Jackson ObjectMapper, it will get the default Jackson behaviour, which is to fail on unknown fields.

So, if you have configuration code such as

@Configuration
public class JacksonConfig {
    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

Your app will reject installs with the displayUrl field present. We are updating the Connect SpringBoot release to ignore extra fields in the LifecycleEvent class even with this configuration in place.

16

Thanks for the info. In light of this, though, would you be able to update the blog post regarding those changes? Ecosystem support for custom domains - Atlassian Developer Blog

There’s a paragraph which states:

For Confluence instances, only the displayURL field will be present.

Which is currently false if I understand correctly the question from @tbatagiannis and your response.

17

I have updated the blog post to indicate for Confluence, only the displayUrl field will be added.

I was just trying to be clear that the displayUrlServicedeskHelpCenter field will not be added for Confluence (since it will never be relevant) but realize this may have caused confusion.