How to retrieve environmentId and (real) appId from context in a macro?

Forge Forge Modules and Product Triggers
, ,
1

I noticed that there is a difference in the context if I use it in different Forge modules. I am working with customContent where I need the appId and the environmentId to build the content type key (as described in the custom content documentation).

The provided solution to extract the appId noted in the question Is there a way to get the Installation Id and App Id programmatically in Forge? works fine on a general page, BUT it seems the localId differs in structure and value for macro modules. The envronmentId is missing completely…

I work with Custom UI, but the same ist true for the macro config (which is kind of UI Kit).

Any Ideas what’s wrong here and how to retrieve the appId and envronmentId inside a macro?
This a big blocker for us, as can’t create or retrieve our custom content inside a macro.

See the two contexts

Macro

  context: {
    localId: '12345678-1234-1234-1234-123456789012', <<< NOT MY APP ID
    cloudId: 'foo-bar',
    moduleKey: 'list-macro',
    siteUrl: 'https://foobar.atlassian.net',
    extension: {
      type: 'macro',
      content: [Object],
      space: [Object],
      isEditing: false,
      config: [Object]
    },
...
  }

GeneralPage

  context: {
    cloudId: 'foo-bar',
    localId: 'ari-cloud-ecosystem--extension-12345678-1234-1234-1234-123456789012-12345678-1234-1234-1234-123456789012-static-overview',
    environmentId: 'foo-bar',
    environmentType: 'DEVELOPMENT',
    moduleKey: 'overview',
    siteUrl: 'https://foobar.atlassian.net',
    extension: { 
      type: 'confluence:globalPage' 
    },
    ...
  }
2 Likes
2

Hi Paul

I’m asking the appropriate teams about accessing app Id and environment Id.

Could I ask what your particular use case is here?

Is there a reason you can’t manually add the app id as an environment variable? By extensions unique variables can be set for each environment so --environment production can have a variable FORGE_ENVIRONMENT=production.

Do let me know and I’ll get back to you with replies from our teams.

1 Like
3

“Hardcoding” the envronmentId and appId (as environment variable) was my second option and I will try that out. Maybe I’ll save the whole custom content key in a variable.

But it feels not the right approach to bypass the context, if it normally provides the needed information. Another downside of this approach is that, while development, my colleagues and I have to set both values for each “personal” app and environment.

1 Like
4

I’ll be having a chat to see if we can inject the app id and environment id into the runtime and if it makes sense to do so.

Certainly no promises on this front.

3 Likes
5

I’ll tried using the Forge env variable and this is a proper workaround!

Thanks for asking, looking forward to the result.

6

@JoshuaHwang
Is there any update to this? I don’t see any other proper way to create routes to other app modules. As this is available in the Jira context, I don’t see why this should not be a feature of the Confluence context.

7

Not an answer but this ticket tracks this feature.

https://ecosystem.atlassian.net/browse/FRGE-878

If it gets delivered it won’t be on the current runtime environment it will be implemented in our new environment.

2 Likes
8

Here we go https://developer.atlassian.com/platform/forge/changelog/#CHANGE-1359
Please be aware that this API is available in nodejs runtime only

3 Likes