RFC-71: Improving Connect to Forge and Forge Platform Upgrades

[EckhardMaass]

Hello @SeanBourke,

We only have Forge Apps so far, but this topic is also a real annoyance for us.

@SeanBourke

One of the key challenges with time-bound updates is the processes which have been established by larger, enterprise customers. We have seen circumstances where customers review updates periodically (i.e. every month, 3 months, 6 months, etc.) and may have significant or robust reviews associated with them; particularly where an elevation in permissions has occurred.

I have to stress here, unfortunately, that this is a bit of a red herring: in my experience major upgrades (due to scope changes) and real, semantic major upgrades that change the App’s functionality are quite independent. I can basically retract all functionality of an App, or change most of what the App does, as a minor upgrade where the customers cannot opt-out. So this review process would be too late in that sense there, anyway. Fwiw, having a maximum of 6 months seems fine to me.

Btw: Tanks @scott.dudley for making such a good case in your reply!

Regards
Eckhard

[SeanBourke]

Hey @JulianWolf,

Thanks for the response.

@JulianWolf

I think the approach Atlassian suggests here poses the risk of things becoming more complicated or, at the very least, more error-prone.

It would be great to understand a little more about how this approach would be more error-prone and if there are measures which you believe could be considered to help mitigate this.

More broadly, I really appreciate your suggestion and is I noted in my response to @scott.dudley, there are multiple facets to upgrades and not one single solution is likely to solve these.

@JulianWolf

With optional (or switchable) scopes, Atlassian could release new (major) app versions to all customers automatically, but with new scopes or egress permissions turned off by default for existing installations. This would still ensure that every customer is always on the newest version.

This works well when features are additive and enable a new capability which otherwise would not be possible with the existing scopes. The app can gate this, preventing utilisation until the right individual has approved the app’s access to additional data.

In the circumstance of a transformative change, such app moving from Connect to Forge and replacing an existing module, this behaviour would subsequently result in the app breaking for all existing customers on the new version until they were to update. While this may be acceptable for some partners, others may not be willing to accept this risk. For this reason, is it fair to warrant that there is still a need for some form of inherited scoping/permissions?

With that said, is it also fair to suggest that these two solutions would be complimentary - in that decoupling versions and installations, but also enabling inheritance of scopes would enable more apps to be on the later version without any disruptive changes?

As I noted in earlier responses, we’re aware and conscious of the breadth, complexity and pain associated with updates today. While this RFC primarily focuses on one scenario (that transformative change), I’m hopeful we’ll see more RFCs related to the problem space in the near future.

[SeanBourke]

Hey @BenRomberg,

Thank you for your feedback on this RFC and glad we’re addressing your FRGE ticket

@BenRomberg

One thing I would ask you to reconsider would be regarding the UNMAPPED mappings. For example, delete:group:jira should be mapped to the ADMIN Connect scope. Even though the “delete group” operation is not available when using Connect, the ADMIN scope with its description “Administer the Jira site.” should cover the adoption of this operation. I’m guessing there were technical reasons why Connect apps did not get access to some of the new UNMAPPED operations and not because the Connect scope description wouldn’t cover those?

Your assumption is correct - we had evaluated new scopes which map only to APIs which Connect could previously not access as UNMAPPED, however the rationale for inheritance is also warranted. Happy to re-explore this to understand whether it’s appropriate, but for now it’s safer to assume that these are UNMAPPED.

Once we finalise the mapping internally, we’ll promote this to a final list for partners, so that you can confidently evaluate / choose your scopes in-line with your apps needs, ensuring that you’ll receive a minor update when moving to Forge.

[JulianWolf]

Thanks for getting back on this @SeanBourke! You’re right. If this were implemented as I outlined, apps’ functionality would degrade with every Connect-scope that gets replaced with a granular one.

Yes, there would still be the need to have some form of inherited scoping/permissions, the two solutions could be complimentary. If both solutions were available together they could however ease the migration and customer experience. Especially large apps will probably want to migrate step-by-step and hence cause multiple major versions, causing more and more customers getting lost down the update line. I appreciate the discussion in this RFC!

Cheers,
Julian

[carlos.martin]

Hello Sean, first of all, thank you for sharing all this information.

I believe it’s very helpful for us to clarify these previously unknown update issues.

In principle, the proposal fits well with us as the possibility of only making a major update of the app when there’s an expansion of permissions seems quite coherent. I think it saves us synchronization problems with clients.

One drawback that may occur is when there are major updates, where there may be new permissions or new remotes essential for the application to function. This leads us to a situation where, during the progressive update process, there could be functionality issues for certain clients during that time range. I suppose we would have to continue giving permissions to both infrastructures, and data migration would have to be done individually per client if necessary.

Perhaps some kind of functionality that allows us to know when there’s a major update in the application before carrying it out would be helpful. Similarly, during the migration process from Connect to Forge.

The proposed idea for major version updates to be done first in Forge and subsequently updates in Connect seems at first glance to be a coherent step, and helps prevent client blockages.

The scope mappings, at first glance, don’t seem to affect our new versions in Forge.

One can feel comfortable being able to do tests with our own instances, validating that the transfer from Connect to Forge is done without problems, evaluating and correcting any type of error without affecting clients.

It could be interesting to be able to know which clients have made a successful migration and which have not, with the aim of being able to make decisions or compel certain clients to update.

Thank you for everything and for the great work on this RFC.
Carlos Martín

[SeanBourke]

Thank you everyone for providing feedback, thoughts and suggestions to this RFC. We’re going to close this as the discuss date has now passed and will come back with a more comprehensive response later in November, informing you of outcomes and next steps.

If you have any further questions in the interim, please don’t hesitate to reach out to me via private message.

[SeanBourke]

Hi everyone,

A big thank you to everyone who provided feedback and suggestions as part of this RFC. I appreciate this response is a little late, we’ve taken some additional time to consider the feedback and explore opportunities to accelerate the availability of this capability where possible. I’ll address some of the key points of feedback as part of this response.

Concerns about updates more broadly

We understand that the way updates work for apps has increased the complexity of change management for apps and appreciate that this has caused challenges in the past. While this RFC was scoped to explore the migration of Connect to Forge and the nature of inheritance for scopes, your feedback has also spurred further conversation about how we can do more to alleviate this.

In the future we anticipate that we will explore alternative avenues to help address this, including increased visibility of updates, decoupling of updates and permissions, as well as other changes. Depending upon the success of this exploration, we anticipate that some of these will become subsequent RFCs for further comment from the developer community. For now, we do not have any timing for these.

Delivery Approach

We’ve reassessed our approach and milestones to enable earlier delivery. We will now deliver in two distinct milestones:

Milestone One - Opt In (Preview)

This milestone will enable migration of existing Connect customers to the latest Forge version, as well as inheritance of all Forge capabilities except scopes. Apps can opt-in for enablement of this capability and may still avoid any major version updates as long as they have their scopes pre-defined. The modification of scopes (addition or removal) would still result in a major update.

Milestone Two - Default (Generally Available)

This capability is now generally available for all apps and is the default behaviour. Apps can still opt for stage migrations, where updates will only occur to a declared set of sites for testing and validation. The modification of scopes (addition or removal) would result in a version which does not require approval, as long as there has been no elevation of permissions.

Unmapped Scopes

We’re continuing to finalise the list of scope mappings for partners to refer to. In doing so, we are reassessing whether scopes which were previously unmapped can be inherited by existing Connect scopes. We will provide a finalised mapping as soon as it is available.