Page attachments changed to URL within our Confluence Space

[Stephen Kairys]

Confluence Server 6.4.3:

Has anyone ever seen the following behavior?

Normally, when I bring up a document and click on an attachment, a simple filename appears on top. e.g.

VendorConfigOptions.PNG * [v.1 current]

However, without anyone changing the attachments, a large # of them now display their filename as follows (where documents.mycompany.com is our Wiki).

https://documents.mycompany.com/download/attachments/28213843/VendorConfigOptions.PNG%28Rev_20170525%29.png?version=1&modificationDate=1495715824613&api=v2

Based on spot checks, the problem may have started after we upgraded from 6.1.1. to 6.4.3. The only commonality I see is docs modified after the upgrade date, even if the image itself was not touched.

The ModificationDate  (per Atlassian) is in Epoch Format. Based on three spot checks, this date matches the date on the Attachments page, within a minute.

While I see the images in my document now, if our Admins would change  our root to (e.g.)

info.mycompany.com, I'm concerned the links would break.

Bottom line:

1. How could the above have occurred?

2. Can it be fixed?

Many thanks for any info you can provide.

[AnnWorley]

Hi Stephen,

It sounds like you are running into behavior related to Images, attachments and user mentions in the page are broken after changing the BaseURL but before the base URL change. The bug report is public so you may comment or vote to elaborate on your case and be added to notifications.

Based on that bug, I am pretty sure if your admins changed the Base URL as you mentioned, that those attachment links would break. The workaround is to turn collaborative editing to off mode and back on, but since your pages are still displaying the images, I don't want to fix what isn't broken. Do you have a test instance you can try it on? I would like to spare your production instance if it isn't going to work because, as it says in the bug report:

• The issue will stop occurring but you will need to go back and manually restore any pages that were affected
• All existing shared drafts are lost when you switch collaborative editing off, so make sure your users have published any work they want to keep before you make the change.

I look forward to any follow up questions.

Thanks,

Ann

[Stephen Kairys]

Hey Ann, thank you for your quick reply. :)

Before we go any further,

1. You said:
>>It sounds like you are running into behavior related to Images, attachments and user mentions in the page are broken after changing the BaseURL but before the base URL change<. 

Please clarify the remark in bold.

********UPDATE********

2. I just found out we may have changed the Base URL (from http prefix to https prefix) around the time the problem occurred. Suppose that change occurred on 11/8/17. Would it make sense that if I modified a doc on 11/16/17, the bug would introduce these rogue filenames?

********UPDATE********

3. I just tried updating a page last modified in 2016. I added some text, and inserted a new image. But, when I checked an few attachments, the filename was still OK, without the URL. Am I not doing the right thing to recreate?

Thanks!

[AnnWorley]

Hey there Stephen,

I got that "before the base URL change" idea from the bug report: 

"This is likely happening because Synchrony "saved" the links with the old Base URL, and then when the BaseURL changed, those changes aren't propagated into Synchrony (because it's saving the editor format)."

 I think you did do the right thing to recreate the issue. If your team ever toggled Collaborative Editing off and back on since the base URL change, it would have fixed the issue going forward but any pages that already have the broken links still have them. That would explain your not being able to generate the URL-instead-of-filename issue even on older pages.

Is there anything that the pages with the attachment URLs instead of file names all have in common? Also, if possible, please find an affected page and restore it to an older version to see how long the attachment links have been URLs. (Use the ... menu on the top right of the page and go to Page History)

Thanks,

Ann

[Stephen Kairys]

Ann,

1. Apologies. I was not clear in my question about "doing the right thing to recreate". I meant "was I not executing the appropriate steps".  Here's my corrected paragraph:

>>I just tried updating a page last modified in 2016. I added some text, and inserted a new image. But, when I checked an few attachments, the filename was still OK, without the URL. Am I not following the appropriate steps to recreate<<

2. What do the pages have in common? Seems to be that they were modified at some point in November.  Which may have been around the time we changed our Base URL.

3.  Would any Confluence logs show;

     a. When the Base URL changed?

     b. If and when collaborative editing was turned off/on?

4. I will say that we found a page (last month) that did not exist until December and MAY, underline MAY have exhibited the issue.. I say that because an image copied from that page to a different Confluence instance showed the URL filename.

Thank you for your insight on this issue.

Stephen

[AnnWorley]

Hi Stephen,

I do think you took the correct steps to reproduce the issue. All it takes is to edit a page after the base URL change.

I changed my base URL in Confluence 6.6.1 and did see an entry in <confluence_home>/logs/atlassian-confluence.log:

2018-01-24 17:44:15,878 INFO [ListenableFutureAdapter-thread-5] [plugins.synchrony.bootstrap.DefaultSynchronyProcessManager] updateSynchronyConfiguration Synchrony External Base URL: 

Disabling Collaborative editing caused an entry in the same log: 

2018-01-24 17:48:03,122 INFO [Long running task: DisableTask] [plugins.synchrony.bootstrap.DefaultSynchronyProcessManager] lambda$stop$12 Stopping Synchrony...

Please do see if your logs go back to November and if so, whether either of those entries are present.

Let's not focus on that page that we are not sure about, because it may have been an issue with the destination instance. Just to contradict what I just typed, please let me know how the page was copied to another instance; publishing to another instance is not available out of the box so I am wondering if an XML backup or other method was used.

Thank you,

Ann

[Stephen Kairys]

Ann,

Getting back to the original problem, I found conclusive proof that Confluence globally changed images within a document. I made a minor revision on 11/16/17. When I look at PAGE HISTORY, a whole bunch of images are tagged as REMOVED/ADDED.

Can't give you the link b/c of proprietary info, but here's a redacted screenshot of the Page History screen.

The reason I'm engaging on this issue on a weekend is that these URLs are now affecting customer-facing docs. I was concerned that they were an "accident waiting to happen" and we spent hours yesterday dealing with the ramifications.

I"d love it if your help desk could come up with a script or something to do through our Confluence files and revert the filenames to the correct and safe format. :)

Thanks and have a good weekend!

Stephen

[AnnWorley]

Hi Stephen,

Thanks for the update. :)

I noticed you have a support ticket open for this issue, I will circle back on this thread when the ticket is resolved, to let the Community know.

Cheers,

Ann