Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Highest
-
Resolution: Fixed
-
Affects Version/s: 6.3.3, 6.8.1, 6.15.1, 7.0.1, 6.13.6, 7.0.2, 7.0.4, 7.2.0, 7.0.5, 7.1.2, 7.2.1, 7.3.2, 7.4.0, 7.5.1, 7.4.1, 7.4.4, 7.9.0, 7.4.6, 7.4.8
-
Component/s: Editor - Synchrony
-
Fixed in Long Term Support Release/s:
-
Support reference count:272
-
Symptom Severity:Severity 3 - Minor
-
UIS:4,472
-
Bug Fix Policy:
Description
PLEASE NOTE: This fix will stop new occurrences of the bug. It does not correct pages already affected by the bug. We have released a plugin to begin correcting pages that already affected, you can obtain more details about it on the related issue CONFSERVER-63615: Provide workaround for fixing broken unknown attachment placeholder in storage format
We have now released a fix for Confluence versions 7.4.9, 7.11.3 and 7.12.1. The fix will also be included in Confluence 7.13.0 and future versions.
Previously we released what we believed was a fix in Confluence 7.4.6 and 7.8.0, and closed this ticket. Unfortunately this fix was only partial, so customers running these and subsequent versions have a partial fix in place. It turns out this issue was more complex than we had previously understood and we apologise to anyone inconvenienced by the bug or the partial fix.
Whilst this ticket addresses the bug itself and should stop future occurrences, we understand a significant number of our customers are already impacted with some impacted across a large number of pages and drafts. With this in mind, we've created CONFSERVER-63615: Provide workaround for fixing broken unknown attachment placeholder in storage format to track our work on creating a method to fix the issue for customers already impacted. This ticket is currently in progress.
To be clear, whilst the goal is to have some method that automatically corrects the issue for impacted customers, there may be some cases wherein automatic correction is not possible and manual intervention may be required. Hopefully we can find a one click solution, but I want to set expectations early and clearly that it may not be possible.
We appreciate your continued patience as we continue working to finalise this issue.
Thanks,
James Ponting
Premier Support Engineer
Summary
When the storage format of a page embeds an image that is not yet attached to the page, the image will still be rendered as "Unknown attachment" in the page editor although the image has been added to the page beforehand.
Steps to replicate
- Ensure Collaborative Editing is switched on.
- Create a page with this storage format.
<p><ac:image ac:height="250"><ri:attachment ri:filename="test.jpg"/></ac:image></p>
- The page displays "Unknown attachment".
- Via '...' > 'Attachments', just insert an attachment 'test.jpg' into the page. You'll see that the page now contains 1 attachment, which is 'test.jpg'.
- View the page you first created and the image is now there.
- Edit the page.
Expected results
The image would still be displayed.
Actual results
The image is now replaced by the initial "Unknown attachment" message.
Notes
If a script that uses REST API to automate the process of creating/copying pages and uploading attachments to it is being used, please remember to follow the order below in the creation of the page to avoid being affected by this bug:
- create a page in Confluence
- add the attachments to this created page
- update the page with the expected content, in the storage format, using REST API
Workaround
Option 1 (preferred) - If the storage format is not yet broken with unknown placeholder.
Leave an inline comment on any text of the page. You can delete or resolve it immediately afterwards. Attachment upload doesn't change page storage format, so the code path that triggers sending view page updates to synchrony is not used. Leaving an inline comment triggers the path, pushing updated editor format data into synchrony.
Option 2 - For Confluence 6.9 and up
- Open the editor for the affected page
- Click on the ellipsis button on the bottom right corner of the screen (besides the Close button)
- Click on revert back to the last published version
- Check if the attachment appears on the editor now
The problem is caused by the draft entry on the DB being created before the attachment exists. The application replaces the attachment name with plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_US&version=2 in that situation. Following the steps from Option 2 creates a new draft entry for this page, so it is able to recognize the attachment.
Additional Issues
Confluence can generate an attachment XML with <ri:content-entity content-id="..."> that renders as an unknown attachment. When it happens, it affects the whole page and will likely impact multiple pages. An examlpe of the issue is shown below
<p> <ac:image> <ri:attachment ri:filename="image2020-10-21_12-40-38.png"> <ri:content-entity ri:content-id="138910055"/> </ri:attachment> </ac:image> </p>
You can check which issue you may be facing by reviewing the Storage Format of the impacted page for something similar to the XML above with the content-entity tag.
We're currently tracking this issue at CONFSERVER-60526: Confluence generates attachment xml with <ri:content-entity content-id="..."> that renders as an unknown attachment.
Attachments
Issue Links
- followed by
-
CONFSERVER-63615 Provide workaround for fixing broken unknown attachment placeholder in storage format
- In Progress
- incorporates
-
-
- Gathering Impact
-
- is related to
-
-
- Waiting for Release
-
- Mentioned in
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- split to
-