Silent breaking change of how detect active license?

[jrichards]

Hi Team,

I’m the developer that @clouless mentioned. I made a mistake earlier about the backend resolver because I got app licence mixed up with customer licence:

• 'licensed'
• 'unlicensed'
• 'customer'
• 'anonymous'

refers to customer/user licences. This is relevant when using Jira Service Management or where a Project/Space allows anonymous access.

For the licensed state of an app, what I said above for front-end is correct. For the back-end resolver, we suggest you use something like

resolver.define("checkLicense", ({ context }) => {
  return context.license && context.license.isActive;

From what we’ve seen in the code license.isActive works, and should have been documented as such. We think what happened was that some documentation was written when we only had UI Kit 1, and wasn’t updated.

So, now we’re getting the documentation updated to reflect UI Kit 1, 2, Custom UI and backend resolver examples.

James.

[bjornbrynjar]

Thanks for sharing James @jrichards

I made a mistake earlier about the backend resolver because I got app licence mixed up with customer licence

I am afraid you didn’t make any mistake. Here is the back-end resolver context printed out few minutes ago:

{
    "accountId": "5c77262d5246045a2d8fe269",
    "localId": "ari:cloud:ecosystem::extension/c7209bfb-6e7d-4d94-830d-9b773df00596/.......",
    "cloudId": "3bfeb066-5447-43a0-aa10-007770c144ae",
    "moduleKey": "my-app-modulekey",
    "extension": {
        "issue": {
            "key": "CMP-3",
            "id": "10005",
            "type": "Bug",
            "typeId": "10009"
        },
        "project": {
            "id": "10001",
            "key": "CMP",
            "type": "software"
        },
        "isNewToIssue": false,
        "type": "jira:issuePanel"
    },
    **"accountType": "licensed",**
    "installContext": "ari:cloud:jira::site/3bfeb066-5447-43a0-aa10-007770c144ae"
}

Given this, for the back-end resolver the property you are reffering to doesn’t exits:
context.license.isActive

Can you investigate further, or explain why this is happeing in my development environment?

[clouless]

Thanks Björn for sharing!
I was about to carelessly deploy without changing any code and running into this in production.

I also heavily vote for updating the docs and fixing this!

Atlassian could easily provide an always active license context in STAGING hard coded.
That way we really could test this before deploying to production.

[sopel]

@jrichards

In UI Kit 1, you can check a licence by confirming if license.isActive is true. This is from the useProductContext() from @forge/ui documented in UI kit hooks .

@jrichards

From what we’ve seen in the code license.isActive works, and should have been documented as such.

So therein seems to be an even worse part of the problem than the docs confusion - I’ve just updated @forge/ui from 1.9.0 to 1.9.10 and the isActive property is simply gone:

Error: TypeScript errors in the app caused the bundling to fail. Fix the errors listed below before rerunning the command. [tsl] ERROR in /opt/atlassian/pipelines/agent/build/src/core/licensing.ts(14,65)
      TS2551: Property 'isActive' does not exist on type 'LicenseDetails'. Did you mean 'active'?

Bisecting the versions surfaces the change in @forge/ui/1.9.2/1.9.3/, here’s the diff:

You can clearly see that the simplistic interface LicenseState has finally been replaced with decent LicenseDetails (highly welcome and long overdue), but given isActive is now AWOL, this is a regression and an unannounced breaking interface change, and even in a patch release of that package.

Personally I’d rather make the required code change than lose the new LicenseDetails again, but I strongly recommend a retrospective on how a breaking change like this has been … :

1. … introduced in a patch rather than a major release of that package
2. … not announced upfront and subject to the regular deprecation process
3. … and ideally avoided all together by finding a backwards compatible solution

NOTE: Obviously I’m basing my argument on the typescript interfaces published in the npm package, which may or may not match what might have been changed in your production services, so things might be more messy even

[jrichards]

Hi @bjornbrynjar,

As documented in

• https://developer.atlassian.com/platform/marketplace/listing-forge-apps/#checking-the-licence-status

license is undefined for free apps, apps not listed on the Atlassian Marketplace, and apps in development and staging environments.

That’s why it’s not there.

James.

[joshp]

Just chiming in here to say that we’re seeing the following in the Forge resolver context for both Jira and Confluence in the production environment:

"license": { "isActive": true }

@jrichards I see that you mention that the documentation will be upgraded to describe this which will be great as the current docs only mention license.active (and this is seemingly not correct for resolvers).

In addition to this, would it be possible to also update the @forge/resolver package to include type information about the context value as well? Currently the context value is typed as:

    context: {
        [key: string]: any;
    };

(for reference see out/index.d.ts on npm here)

but it would be much more helpful if it could instead be something like:

    context: {
        accountId: string;
        localId: string;
        cloudId: string;
        // ...
        license?: {
                isActive: boolean;
        }
    };

[nathanwaters]

@nathanwaters

Developers will need a method to test the real license object instead of the current Forge method of faking the data.

Atlassian consistently doubles down on poor decisions instead of just doing the right thing. I could fill a book with examples.

[bjornbrynjar]

@jrichards

license is undefined for free apps, apps not listed on the Atlassian Marketplace, and apps in development and staging environments

Thanks @jrichards. I had not taken note of that

[clouless]

Just a short update from my side:

I have just deployed my licensed app to production without any code changes.

I still use context.isActive in the resolver and it still works.

So as mentioned by Atlassian there seemed to be a mistake in the docs which of 2023-12-01 is still not fixed yet: https://developer.atlassian.com/platform/marketplace/listing-forge-apps/

@jrichards Is there any update on this topic from the Atlassian side?

[jrichards]

Hello Everyone,

It’s fixed now Sorry for the delay but we had a few checks we wanted to make.

• https://developer.atlassian.com/platform/marketplace/listing-forge-apps/

Please have a look.

Thanks,
James.

[KavithaSivalingam]

Hi James,
We are facing a strange issue with this Licensing issue. We use the same code base for both Confluence and Jira and we are able to see it working fine in our DEV & Staging environments and we submitted for the approval from Marketplace.
Surprisingly the same license check working fine with Confluence and not in Jira for the support staff ECOHELP-31513 & ECOHELP-30760. Is there something else happening with the license object with respect to Jira?
This question may not be relevant to the silent breaking change, but there are lots of discussion about the license object here, thought of checking with you.
Thanks in advance,
Kavitha

[jrichards]

Hi @KavithaSivalingam,

I don’t believe there’s a different between them. We’d need to see the specific error and some more details. I know you have two ECOHELP tickets open, but can you open a new one in the Bug category in the https://developer.atlassian.com/support page will a sample app so we can see the details?

Thanks,
James.

[KavithaSivalingam]

Hi James,
We are still waiting for our app approval, seems the app approval team is waiting for some answer from their internal team.
As suggested by you, I have logged a bug here: Jira Service Management
Thanks,
Kavitha