How to differentiate app installed as "migrated from connect" and "from forge"

Forge
1

Hello,

connect is reaching its eol and let’s suppose every app is now Forge app. But those apps will inherently differ:

  • app installed after the migration to forge
  • app installed as connect and and upgraded to forge

Is there any way how to differentiate those two installation types? There is a way how to retrieve the connect’s clientKey Retrieving the Connect clientKey in Forge , but I am not sure if this endpoint is prone to changes or what it returns for forge-only apps - so might not be a correct way to use it to differentiate those two installation types

2

Hey @IvanHanak,

I’m not aware of anything that surfaces this information at the platform level. Retrieving the Connect clientKey in Forge won’t help you distinguish between a Connect / Forge installation. It will only be around until Connect EOS at which point we’ll decide when to deprecate with a shorter amount of notice and it’s purely intended for the pattern:

  1. Your Forge app receives avi:forge:installed:app event
  2. Your Forge app calls the App properties API with the reserved key to fetch the client key
  3. Your Forge app checks for existence of Connect data keyed by that client key in your database, and associates that data with the Forge installation

Perhaps you have an audit log that you can use to derive the state for each installation? Or maybe you have maintained an installedOn date or firstVersion value per installation? avi:forge:installed:app and avi:forge:upgraded:app contain the version that was installed, if you have logs of these events + Connect lifecycle callbacks then you should be able to derive the state of your current install base.

Out of curiosity, why do you need to differentiate the two? I’d like to better understand the problem you’re trying to solve here.

Thanks,

Mitch

3

Thanks @MitchMcCue for very extensive response.

I am very well aware of the three points you mention.

Actually the case is this - a connect app that has been migrated to Forge in a way that it no longer egresses any data (everything connect-related has been removed from the manifest).

And the reason I was after a way to differentiate programmatically installs (customers who upgraded the app from connect and customers who installed just the Forge version) was simply to show different messaging in the app for those two groups. (in particular to inform customers who upgraded from connect about the required data migration - such message would be confusing for those who installed just Forge version).

(I figured this endpoint GET /rest/atlassian-connect/1/addons/{app.connect.key}/properties/connect_client_key_019cdff3-8bfb-71fe-9628-875b700aebb8 is app-related, not installation related - so it will return the clientKey no matter which customer installed the app)

4

Thanks for sharing that with me @IvanHanak - an interesting use case!

The only other workaround I can think of won’t be much use to you now if you’ve already migrated to Forge… But prior to that, you could have pushed had your Connect app push a property to https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-app-properties/#api-group-app-properties before/during the Connect->Forge migration, which you could then consume from your Forge version to drive the messaging.

Sorry I couldn’t be more assistance.

Thanks,

Mitch

5

That is actually a very interesting solution. To “mark” current connect app via an app property and then simply try to retrieve it via forge!

I think it might be an answer to my question.

Thanks @MitchMcCue !

6

Hey @IvanHanak, just want to highlight additional information so you don’t get caught out.

https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-app-properties/#api-rest-atlassian-connect-1-addons-addonkey-properties-propertykey-get can be accessed by both Connect + Forge apps.

https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-app-properties/#api-rest-forge-1-app-properties-propertykey-get can only be accessed by a Forge app, and is not backed by the same underlying store as the Connect API.

Concretely:

if you persisted a property from your Connect app via PUT /rest/atlassian-connect/1/addons/{addonKey}/properties/{propertyKey}

retrieve it from your Forge app via GET /rest/atlassian-connect/1/addons/{addonKey}/properties/{propertyKey} where addonKey is your Connect app that you’ve also got in your Forge manifest like

app:
  ...
  connect:
    key: <addonKey>
    ...

It will NOT be observable via /rest/forge/1/app/properties/{propertyKey}

7

Hi @MitchMcCue ,

thanks for the additional details and for taking the time to look into this - since it relates to just a few connect-to-forge-migration installs. I am aware of the difference between those endpoints and I think that one particular endpoint is a perfect way to differentiate those two kinds of installs.

That’s because while a customer might still be on a connect version, at that point in time the app marks its current connect state within the app property - and after the successful migration from connect to forge:

  • the new (forge only) installs will receive a 404 when retrieving that property
  • and those older installs (from connect) will simply be marked as having that property set