Dear Support,
We have massive problems with Confluence and the bug that attachments disappear (Unknown-Attachments).
There is already a case at Atlassian (CONFSERVER-55928) and there Matthew had written on 04 February that you should contact support and the information that we refer to this case, so that the information is forwarded directly to his team.
We are using Confluence 7.4.6 and we already asked our consulting company who are Atlassian partners. But even never get anywhere here.
We have over 1500 pages in Confluence and we don't see any regularity when exactly this problem occurs. About 75% of the pages we edit, the attachments are then destroyed.
I am a software developer myself and first wrote a program to reconstruct the data. Technically, I iterate over each Confluence page (all via the REST API) and take the content of the page. I then search for
ri:filename=
and extract the filename. Then in the content of the page, I delete the entire attachment plugin and replace it with XXXXXFILENAMEXXXXX and upload that as a new version to Confluence. In addition, I then download all the attachments of the page, delete them in Confluence, rename them automatically and upload them again.
Then I search for XXXXX in the content of the page and extract the file name from this text again. Since I know what the corresponding new file name is called, I create an attachment plugin exactly at this point again and upload the whole thing again under a new version.
At the end I mark the page as "repaired" and take the next page.
This works to 80% also with already broken pages (where no more attachments are, but only the message "Unknwon Attachment"). I was able to reconstruct this because the file name is there as a title attribute within the associated XML element. Unfortunately, this was not the case in all cases.
Sometimes there was only
<ri:url ri:value=\"https://documentation.cargosoft.de/plugins/servlet/confluence/placeholder/unknown-attachment?locale=de_DE&version=2\" /></ac:image>
Something like that in the content. In this case I went backwards through the previous versions and checked how many attachments were specified in the content of the page and how many were specified in the previous version. If the number was the same (so no new images were added), I just took the old order of the images and did the steps from above. I marked these pages extra so that someone can manually check if the pages are still correct at the end.
The whole thing then took 6 - 8 hours, and after that 90% of the pages were correct. Unfortunately, the error occurs again now.
We have already played with the cooperative editing mode in Confluence (it was said at the beginning that this might be the reason). But this does not change anything either. We have the latest LTS version in use, where the error should supposedly be fixed (the process in JIRA is already closed, after all) - although many users still have the problem.
We also don't see any correlation in how the images are added. Partly the images are added via copy & paste, partly with drag & drop, or even via the menu items in Confluence itself.
Since we currently have to consider how we will continue with the Atlassian products anyway (keyword end-of-life for server products) and then such errors have already existed for almost a year, we will otherwise soon really have to look for alternatives. That would be a real shame, because the applications (JIRA and Confluence) are really great, but by forcing us to go to the cloud plus such bugs, you destroy your market advantage. In Germany, we have strict data protection rules, and the current solutions are far too expensive for medium-sized companies.
Maybe someone here can give me some information on how to deal with this problem in Confluence. The case is closed and the users are complaining, but there is no statement from Atlassian.
Sorry if my English is not that good.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.