Document Saving after Modification (or not saving) in Confluence

DSell October 2, 2020

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.

 

Thoughts?

2020-10-02_08h34_01.jpg

1 answer

0 votes
Diego
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 6, 2020

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:

Screen Shot 2020-10-06 at 13.05.30.png

 

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!

DSell October 6, 2020

Hi @Diego 

The team is using Cenote Lockpoint.

 

Side note:

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.

 

Thank you

Scott Dudley _Cenote_ October 7, 2020

 

Hi @DSell and @Diego

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

DSell October 7, 2020

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.

 

David

Scott Dudley _Cenote_ October 7, 2020

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.

Scott

DSell October 8, 2020

Hi @Scott Dudley _Cenote_ 

 

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.

br,

David

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
TAGS
AUG Leaders

Atlassian Community Events