Functions that rely on methods to work with files and attachments (including images) are failing after collaborative editing is disabled.
The following methods have been identified so far:
- saveAttachment() and removeAttachmentVersionFromServer() from the Confluence Java API https://docs.atlassian.com/ConfluenceServer/javadoc/7.4.9/com/atlassian/confluence/pages/AttachmentManager.html
- storeResource() from the Confluence Java API https://docs.atlassian.com/ConfluenceServer/javadoc/7.4.9/com/atlassian/confluence/pages/FileUploadManager.html
This leads to significant side effects for customer:
- users are not able to upload a profile picture using the functionality provided by Confluence natively
- using apps because PersonalInformation of a user (including the profile picture) cannot be retrieved, updated and used by apps with disabled Collaborative Editing.
- Open the user profile page
- Attempt to upload a new image
Everything works as expected.
The below exception is thrown in the Confluence logs:
Enabling collaborative editing at a later stage doesn't resolve the problem. Once the collaborative editing option has been disabled, the problem will remain even after re-enabling it.
Currently Confluence relies on the getContentId but it is not available for the PersonalInformation which is where the attachments are stored in this case.
This has been introduced with the https://jira.atlassian.com/browse/CONFSERVER-55928 fix, so all Confluence versions including the change until a fix for this issue is released are affected.
Currently there is no known workaround for this behavior. A workaround will be added here when available.