There are two scenarios as shown below in working with and trying to save attached files in contained in a page in Confluence.
#1: the user clicks on the link to the file, modifies the file, but when saving it is not saved back to the file in Confluence.
#2: he user clicks on the "edit" button, modifies the file, when saving it is saved back to the file in Confluence.
The biggest problem I see here is that in scenario 1, after clicking save, everything seems to be okay and the user feels they are good to go, but there work is gone.
Hello @DSell !
I tried to replicate this in my Confluence site but then I noticed that the default User Interface for our Attachment Macro is pretty different from what you have. Here is what I see:
I believe that you are using a plugin that manages document accessibility and usage. Do you know what plugin is that? Confluence does not have the option to lock attachments for edit natively. Knowing what plugin you are using will help us to better understand what is happening.
Natively, when using the attachments macro, if we click the attachment name (link) it will download the file. For us to edit it, we need to click the edit button and use the companion app. Here we have more information about our Attachments macro:
Let us hear from you!
The team is using Cenote Lockpoint.
We are using Confluence in this area for document control / repository and once the document is approved it needs to be locked for edit. I am not sure that Lockpoint at the end of the day will serve our purpose as we want a workflow and locking for both pages and attachments.
Writing from the Cenote team:
Lockpoint does move the placement of the buttons and it adds the Lock buttons, but it doesn't otherwise impact the functionality that you describe.
In general, Confluence styles the topmost link to the attachment as a direct download link, while the Edit in App features with the Companion are only available through the Edit button, as you noted. This is how things work regardless of whether Lockpoint is in use or not.
I understand that this behavior may not be entirely intuitive, but as far as I am aware, this is by design on Atlassian's. Your best bet might be to file an improvement request with Atlassian.
If I can provide any further clarification in terms of Lockpoint features, please let me know.
Scott @ Cenote
Hi Scott / @Diego
It seems odd that both ways open the file in the same fashion. Both offer the same was of saving the file. The difference being that one way actually saves the file and the other way does not save the file and does not that it did not save. (losing your work)
If this is the intended behavior, it is beyond not being entirely intuitive, it is a terrible flaw.
Hi @DSell ,
My understanding is that the topmost link to download the file has always been present since the early days of Confluence. Originally, if you wanted to change an attachment, you would click on the link to download it, edit the download, save it, and manually upload the saved file back to the page.
When Edit in Office (or the newer Edit in App) was introduced, this added a new way of opening the document that permitted the document to be downloaded and opened with one click, and also permitting a saved file to be automatically funneled back to Confluence. When this feature was added, Atlassian did not remove the direct-download link (perhaps because people may still want to directly download an attachment without editing it).
I speculate that you are seeing identical behavior with the two options because you have your browser configured to automatically save and open certain types of downloaded files. The Edit in App feature will always automatically open the document no matter what, but the flow after downloading a file (using the uppermost link) is controlled by your browser and its settings.
When I click on that link, for example, I see the file appear in my Chrome downloads bar but it does not automatically open. If your browser is set to automatically open, you should be able to reset the behavior so as to make the two paths at least slightly visually-different.
All of that having been written, I do not work for Atlassian, so this is only an educated guess as to why things are made the way they are...but I hope the information is at least partially helpful.
Again thank you for all your help w/this. I do understand that you do not work for Atlassian and makes your help even more appreciated.
One final point for clarification to anyone ready this. You mention in your last post "seeing identical behavior with the two options". The two options do not yield the same result. On option #1 when clicking on save, the user thinks the file is saved, but in fact it does not save and when it is closed the changes are lost.
Hi Community! We're thrilled to share that Team Calendars for Confluence is now a built-in feature for Confluence Data Center releases 7.11 and beyond. A long time favorite, Team Cale...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events