Connect on Forge with Connect condition 'addon_is_licensed'

Forge Forge Platform and Tools
1

We’re currently looking to move our app from Connect to Connect On Forge and have a question about checking / controlling the license status in non-production environments.

On Connect a standard development process would involve usage of Private Listings tokens generated from the marketplace app management page.

For example, we could deploy our app to our staging environment, install it to a Confluence instance we have set up for testing our staging deployments, and apply a Private Listings token so that, with regards to license, the app would behave the same as the production version.

My understanding is that Private Listings are not a thing on Forge. With that change, as a Connect On Forge app deploying to the Forge staging environment, we seem to be in an ‘unlicensed’ state with no way to control it. This means Connect features that we have gated using the addon_is_licensed Connect condition are not accessible outside of production.

What would the recommended solution be?

1 Like
2

Hi, you should be able to test the license state in the CLI for non-production environments - https://developer.atlassian.com/platform/marketplace/listing-forge-apps/#testing-your-app-with-different-license-states

2 Likes
3

Thanks I’ve tested this and the problem seems to be that those commands work (I assume) in a ‘forge code’ context, eg from a Forge backend function, or from Forge frontend (UI kit / Custom UI) code, but we don’t have any such code, we have only our Connect code. The only part of the project that is really ‘Forge’ is the manifest, which we have by running the “Convert descriptor to manifest” tool.

Running the forge install command with --license flag and various values appears to have no effect on the connect AP context object.

4

Hey @TonyGoughAdaptavist,

Thanks for following up on this. Any Connect modules/interactions within Forge should still inherit the associated license derived from the --license flag override. To help us isolate where this is occurring, could you please take a look at some other license flags (such as the ?lic query string parameter on any iFrames) and confirm whether they are present?

5

Hey @SeanBourke, clarification after some further testing: it appears the --license flag override is taking effect, at least on the first install to a test instance. My question would be how to toggle the license state after that - for example I am trying the following:

  1. Create fresh test instance
  2. forge install --license active -p Confluence -s <test-instance>
  3. Confirm license.active: true in the Connect AP context
  4. forge install --license inactive -p Confluence -s <test-instance> --upgrade

But I think this 2nd install does not really take effect, with the console message Your app in the <env> environment is at the latest in Confluence on <test-site>. and the AP context still has license.active: true

6

Hey @TonyGoughAdaptavist,

Thanks for the clarification. At the moment, the --license flag will only apply on the initial installation and is not applicable to any --upgrade flags. To override this flag with a different state, you would need to perform forge uninstall followed by forge install --license <state> to modify the overriden license state.

2 Likes
7

Thanks @SeanBourke that makes sense!