Retrieving Macro Configuration Parameters During Export in Forge Macros

We created multiple forge macros to facilitate repeated content tasks.

Similar to what is explained here add-configuration-to-a-macro-with-ui-kit, we are adding configurations to our macros.

For content rendered by forge macros to export (PDF, WORD and word exporter for confluence) and match the Front-end content we implemented a adfExport.

When launching an export request to word or pdf, our adfExport export function is indeed called which is great. It is invoked one or multiple times per page (depending on number of macro instances on each pages) which is expected.

However, we are struggling to implement conditions that require configurations parameters values .

For instance, referring to the Pet sample where the “age” parameter is easily retrieved in the Front-End using useConfig(). In the Back-end adfExport exporting function, we are struggling to understand the full context of the invocations, namely what is the macro configuration (parameters key and their values) that we need to resolve to render the content.

In the “Pet” sample and to illustrate we need to render the “age” value for instance.

The context we receive looks like this:

“context”: {
“localId”: “…”
“cloudId”: “…”
“moduleKey”: “”
“siteUrl”: “< atlassian base URL>”
},
“exportType”: “pdf”

So how are we supposed to resolve the following? Is it possible with the context we receive?

-The “age” parameter value for instance that we need to print,
-The macro instance or macro-ID (the macro instance that is being printed since there could be many on the page and we get called multiple times).
-The content ID or page-Id being exported.
-The content version

If not currently possible, can we request to add more information to the context so we can render based on macro specific instances and configuration?

4 Likes

Hi @VincentDumas1 ,

I’ve looked into this and am also not sure how to access the macro configuration from within the context of the export so I’ve reached out to see if the Confluence team can help.

Regards,
Dugald

Hi @VincentDumas1 , I’m an engineer on Confluence. Thanks for pointing out this limitation, I do indeed see that for exporting via pdf specifically, the macro configuration is not passed into apps’ specified adfExport functions. I’ve gone ahead and made a quick change to include these configuration values, as well as the contentId as part of the function payload–it should be merged and deployed by early next week.

Unfortunately the pending code change does not include the other fields that you’re after (macroId and content version); their exclusion is a limitation of the platform right now. Would you know of any other places where Forge surfaces such data to apps? It could help us to evaluate the effort required to potentially add those fields in the future.

3 Likes

Thank you so much for this change (parameters and page ID), this will help forge applications to support printing and exporting.

To clarify, the main reason I was inquiring about the other fields was to enable us to implement a (workaround) way to resolve the macro parameter values by referencing the page’s expanded storage. We believed we needed also the macro ID, and version to make the necessary Confluence API calls and to then resolve the parameters configuration.

However, if you’re passing the parameter names and values and the content page ID of the macro instance version being printed, then these additional parameters won’t be necessary. This enhanced context will allow Forge application developers to execute the required logic to render exported content in a way that mirrors how it’s rendered on the front end.

2 Likes

Sounds good! The change should now be available on production, let us know if you have any issues accessing the macro configuration in calls to the adfExport function

2 Likes

It works well now thanks.

Hi all, in the end after working further on forge apps I realized we need a unique macro ID for printing and for UI rendering too present in the contexts.

The reasons are diverses and mainly because we cannot differentiate between the multiple macro instances that are on same and different pages.

If for instance we have a special association of data with a macro, we would need this unique Id.

Currently there is this low priority on this ticket but for us that is a showstopper.

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