How can a Forge app proactively detect whether instance admins have disabled analytics access?

Forge
,
1

Hi Atlassian team and community,

We have a Forge app that sends product analytics events to an approved analytics domain (declared in permissions.external.fetch with category: analytics).

From the docs, I understand that org/app admins can disable analytics access for apps.
I’d like to handle this proactively and avoid attempting event delivery in those instances.

Is there any official runtime signal/API/context value in Forge to check whether analytics access is currently disabled for the installation (before sending events)?

For example, is there any supported way to:

  1. Query analytics-access status at runtime per tenant/install.

  2. Distinguish “admin-disabled analytics” from generic network/egress failures.

  3. Get a webhook/event when this admin setting changes.

If there is no direct API today, what is the recommended pattern from Atlassian for resilient behavior (for example, circuit breaker/backoff strategy and expected error codes/messages)?

Thanks in advance.

Carlos

2

Hi Carlos,

This feature isn’t currently available but I have raised this thread with the relevant team.

If you can put your use case on this ticket, it would help on the prioritisation: Jira.

Cheers
Ben

3

Does anyone know how the new Permissions SDK behaves in relation to analytics and whether it will detect admin-disabled analytics?

For example, if we have this in our manifest:

permissions:
  enforcement: app-managed
  external:
    fetch:
      backend:
        - address: "www.google-analytics.com"
          category: analytics
          inScopeEUD: false

And then we query the Permissions SDK:

import { permissions } from '@forge/api';

const isPermitted = permissions.canFetchFrom('backend', 'https://www.google-analytics.com')

Is the value of isPermitted sensitive to whether the customer has disabled analytics for this app in their site?

4

Hi everyone

Thanks @Benny, I’ve added a comment in the issue explaining the problem.

Thanks @AaronMorris1. I tested https://developer.atlassian.com/platform/forge/rolling-releases/#permissions-sdk and it’s close to being a workaround for performing that check, but the results I get don’t make sense.

When checking permissions (checkPermissions) against the same URL https://api2.amplitude.com/2/httpapi from the frontend:

  • It doesn’t matter whether analytics is enabled or disabled, it always says I have permission from both the client and the backend.

When checking permissions (canFetchFrom) against the same URL https://api2.amplitude.com/2/httpapi from the backend:

  • If analytics is enabled, it says the frontend does not have permission but the backend does.

  • If analytics is disabled, neither the client nor the backend has permission.

None of these cases solves the problem because the behavior is inconsistent. With analytics enabled, all checks should return OK, and with analytics disabled, all checks should return KO.

I’ve verified that if, as an admin, I disable analytics, my app fails when trying to send data to Amplitude from the backend. I assume there’s an interceptor blocking those requests, which is the expected behavior. However, if I send data from the frontend, nothing intercepts it and the data is still sent. That means I can’t rely on the platform preventing data from being sent, and I need a way to check beforehand to avoid sending it.

5

Hey @carlos.fernandez,

for what it’s worth, we’ve decided to treat it as follows:

It seems that the resolver-side permissions.canFetchFrom('backend', ANALYTICS_URL) actually returns the truth and only the client equivalent is bugged. We use a resolver on Custom UI startup to check the permission for the backend and use it for the frontend as well.

The customer admin has no way to disable only backend or client analytics, it’s an everything or nothing button, so the partial check is enough for now.

That said, FRGE-1868 definitely has to be fixed :wink:

Cheers!