Context content.id is 0 when a macro is used in the template

Issue Summary

When using content.id in a dynamicContentMacros as such:

"dynamicContentMacros": [
  {
      "url": "/hello-world?contentId={content.id}",
      "key": "anne-dynamic-macro",
      "name": {
          "value": "Anne Dynamic Macro"
      },
      "categories": ["media"],
      "outputType": "block",
      "bodyType": "rich-text",
      "featured": true,
      "width": "100%",
      
}

and adding the macro in template, content.id is 0 when viewing the template: http://recordit.co/GSqeVsJCOK

Steps to Reproduce

1. Create an macro app with content.id as context parameters in URL
2. Create a template with the macro in the new editor
3. Click on publish and view the template
4. Notice that content.id is zero:
   

Expected Results

Return content.id as template's id

Actual Results

Zero is returned as content.id

Notes

• Context parameter content.id works with pages and blogs
• Same issue with body and bodiless macros - content.id is 0 instead of entityId (which is essentially a template id)
• I've informed app developer that content.* context parameters are only available in pages, blogs, and custom content:

  From https://developer.atlassian.com/cloud/confluence/context-parameters/ , the content.* parameters are only available on these conditions:

  Confluence provides the content.* variables wherever a page, blog post, or custom content is present. Some examples are viewing or editing a page / blog post, or viewing a Confluence Question.

Background

From app developer:

No, this never worked, but in my opinion it should pass the entityId for the template as content id, like it does for the pages and blogposts.

Otherwise it is impossible to render the 3rd party macros, as we have no idea what is the rendering contents (context) and what to render.

This is especially critical now, with the introduction of a fabric editor, as it attempts to call a "live preview" for the macro, but provides no context

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available