-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Low
-
None
-
Affects Version/s: 7.9.3, 7.10.2, 7.11.0
-
Component/s: Integrations - Office Connector
-
1
-
Severity 3 - Minor
Closed as a duplicate of CONFSERVER-60876
Problem
Attachment (office .doc, .xlxs) renders fine on the page it's attached to. However, if this attachment is referenced on another page via Office macro, it won't render and the UI will show only a spinning wheel as if it were loading.
Reference to the Office macro docs:
Environment
Confluence Server/DC versions: 7.9.3, 7.10.2, 7.11.0.
Doesn't occur on versions lower than 7.9.
Steps to Reproduce
- Install a vanilla Confluence (versions where this was reproduced: 7.9.3, 7.10.2, 7.11.0)
- Add an office-type attachment to a page. They'll render fine.

- Create another page and add the Office macro (tested with .xlxs and .docx files) to it - point the macro to the page where the Office files were uploaded to

Expected Results
Office macro to render the attachments from another page without issues.
Actual Results
Office macro can't find the attachments because it's not searching for them on the correct page.
However, while the page is in editing mode, the macro does render the file contents properly (so it looks for them on the correct page at some point):
![]()
Notes
HAR and javascript console files taken from the browser's DevTools show this HTTP 404 on the attachment.
HAR file:
![]()
Upon further checking on the HAR file, it seems that the contextEntityId parameter in the URL is not pointing to the correct pageID:
![]()
From the repro steps, what seems to be happening is:
- the pageID in the URL that the Office macro calls to render the attachment is from the same page where the Edit Office macro was included, and not the pageID of the page where the actual attachments were uploaded to.
- if I replace the contextEntityId in the URL and point it to the pageID of the page where the attachments were included, then it seems to render fine:

This does not happen with PDF files.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available.