Details
-
Type:
Bug
-
Status: Waiting for Release (View Workflow)
-
Priority:
Highest
-
Resolution: Unresolved
-
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.4.6
-
Component/s: Editor - Synchrony
-
Fixed in Long Term Support Release/s:
-
Support reference count:233
-
Symptom Severity:Severity 3 - Minor
-
UIS:3,125
-
Bug Fix Policy:
Description
Dear Customers,
We'd like to inform you that our team are continuing to progress on this issue and it has our ongoing focus.
We wish to state that Confluence versions 7.4.6 & 7.8.0 and above have a partial fix implemented which ensures editor association to occur if an attachment is uploaded post content-creation. The stepwise behaviour seen after this fix is:
- 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 the menu ... > Attachments, 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. You will see an unknown-attachment.
- Publish the page. This fixes the editor association for Synchrony
- Edit the page again. You should be able to see the correct image in the editor now
We hope to get back to you soon with further updates on how the final steps of this fix have progressed. As per previous requests please get in touch with our support team if you are able to replicate unfixed behaviour in your environment
Regards,
Michael
Product Manager | Confluence Server & DC
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)
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.
Option 3
The issue can be resolved if Collaborative Editing is toggled from On to Off and back to On.
note from Maksym Fedoryshyh: Please never use this workaround!
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, probably multiple pages.
Example:
<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>
If checking the Storage Format of the impacted page, please check if it contains something like the XML above with content-entity.
A new bug has been created to track this issue:
- CONFSERVER-60526 - Confluence generates attachment xml with <ri:content-entity content-id="..."> that renders as an unknown attachment
- Reindex fixes the issue.
Hi All,
After having the team investigate we can confirm that this issue is still happening. I have gone ahead and reopened the issue and it is currently a top priority for our team to resolve. We are very sorry to have misled so many of you by closing it. This is a complex bug that surfaces in many ways. If you are experiencing this issue and can replicate it in your environment, please get in contact with our support team at: https://support.atlassian.com/contact/. Please mention my comment on this issue so support can reach out directly to me and my team.
Regards,
Matthew
Product Manager | Confluence Server & DC
Attachments
Issue Links
- followed by
-
CONFSERVER-63615 Provide workaround for fixing broken pages/shared-drafts because of "Unknown Attachments"
- Under Consideration
- is related to
-
CONFSERVER-60526 Confluence generates attachment xml with <ri:content-entity content-id="..."> that renders as an unknown attachment
-
- In Progress
-
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
- split to
-
PSR-616 Loading...