@Makisa Appleton could you please re-open CONFSERVER-22874?

Hello - thank you for voting for and watching this suggestion.

Although we will not be implementing locking of a file as requested in this suggestion, we have been exploring a notification to let users know of a change to a working file prior to uploading a new version in Atlassian Companion. As per current functionality, uploading changes will add another version as opposed to overwrite an existing file, with all versions able to be viewed in Confluence. At this stage, we do not have plans to explore this suggestion and in order to be clear about our plans, we're closing this request now. You may be interested in following the related ticket, which provides the notification in the new Companion dialog window: CONFSERVER-58035.

We recently made changes to Atlassian Companion, which allows you to edit any type of file, if you have a compatible application installed. This requires you to install Companion on your computer. You can also read more about these recent changes on Community: File editing in Confluence Server: Atlassian Companion updates are almost here!. Companion 1.0.0 is available with Confluence Server and Data Center customers in Confluence 7.3.1. Upgrade now or check out the Release Notes. 

Thanks again for your comments and support of this suggestion.

Makisa | Senior Product Manager, Confluence Server and Data Center

Yes, this is an important one!

It is 2020....we need this

This is really disappointing. Some basic features are missing and not being considered..meanwhile in the news

'Atlassian shares soared more than 10 per cent in after-hours trade, after the quarterly numbers showed revenue jumped 37 per cent to $US409 million ($597 million), while earnings per share rose 22 per cent. The company’s operating margin leapt from 25 per cent to 31 per cent.'

Atlassian, if you dont start listening to your customers, you might start losing customers.

I'm disappointed for all the loyal confluence customers that they have to rely on pricey add-ons.  And I'm sad for Atlassian that they are not keeping up with other products like O365.  I hope that they wake up to that soon.

Hello,

Request for an update on this ticket.
Locking the attachments will bring more value to the documents versioning.

Kindly let us know any roadmap or in which future version of confluence this feature can be expected?

Br/Anil

Hi all,

Thanks for providing your thoughts and votes on this suggestion.

As you’re probably aware, we made significant improvements to our editing files experience in our 6.11 release, allowing users to both edit any file type, and do so without having to manually download the file and reupload their changes. For more information on these improvements, please see our documentation.

However, as part of these immediate changes we decided not to implement attachment locking. There is an add-on available (Lockpoint from Arsenale) which offers the ability to lock documents while they’re being edited.

We do though understand the value attachment locking would bring, and will reconsider this suggestion at a later date.

Best
Jenny | Confluence Server Product Manager

Thanks @Karin!  will look into it

Victor, you might want to have a look at Arsenale Lockpoint. It helped solve our main issue in regards to locking attachments

Help!  We are getting issues with this.  Is there a work around for this in the mean time?

+1 Our organization deals with this issue every day.  We need a solution !!!

+1  Something has to be done to stop multiple versions of Office document editing/saving.  This is a mess for all of our documents with multiple users.

+1 ... why is this critical feature unassigned for so long?

+1 though pending since 2005

Would love to completely dump the use of a Document Management Systems, but our users are still heavy office users. Need to be able to lock/unlock attachments to ensure that documents are not overwritten.

This request is over 10 years old. Any updates?

Any updating about this request guys?
We are with confluence license 2000 users.

Cheers

Hello - For teams working with attachments this is a must feature, isn't it? Best regards, Martin

We would like to have an option in Confluence to lock a page or attachment when concurrent editing is in place.

It should work this way:

User 1

1. Log into Confluence
2. Load page with attachment called "File A" (in version 0)
3. Expand file menu and click on "Edit in office" button
4. User 1 is making changes

User 2 - at the same time as User 1

1. Log into Confluence
2. Load page with attachment called "File A" (in version 0)
3. Expand file menu and click on "Edit in office" button
4. User 2 gets message that the page / attachment is "locked for editing by User 1"

The Arsenal Lockpoint is not a solution for us.

Any idea, on when we can get this feature out ? or any alternative (plug-ins), to lock the attachment from making changes by concurrent (user) updates?

Hello,
i want to ask how about that attachment control? Lockpoint plugin is looking good, but we have a more users and locking attachment when editting by another user is important.
Are there any news about that?
Regards,
Ales

I agree with previous comments ... it is very important that attachment control is implemented so that you can edit a document knowing that your changes will not be overwritten by someone else updating the same document. And also knowing that you will not overwrite someone else's changes.

@David,
Thanks for update. It makes the notification more clear.

Regards,
Anna.

@Anna Afanasieva – Two updates we thought you'd be interested in on Arsenale Lockpoint:

You were right that notification emails from Arsenale Lockpoint going out to your confluence-admins on install of the plugin were a little ambiguous/confusing. We took your feedback and reworked the email message in the latest release so it's more clear what's going on – "You are receiving this email because someone installed the Lockpoint plugin and you are a member of the confluence-administrators group."

Also we decided to make Arsenale Lockpoint completely free for Confluence installations with 10, 25 and 50-user licenses. No strings attached; all features included. Hopefully that might make it a no-brainer install for your team and others out there.

Thanks again for the good feedback!

Hello Scott,

Thanks for clarification. I just got a complaint from the colleague that some users received such notification and they did not know anything about the plugin. I haven`t checked their access rights. If they were only confluence-administrators then it`s more or less ok. However it would be good to be able to check/uncheck the option to notify anybody by email about the change.
Thanks for your answer!

Regards,
Anna .

Anna,

Just to clarify, the Lockpoint plugin sends a welcome email to Confluence administrators (not users) upon installation, including a number of tips for using the product, which is similar to the operation of a number of other commercial plugins, including Gliffy and so on. However, we do apologize if this email to your confluence-administrators group was undesired.

Scott @ Arsenale
http://www.arsenalesystems.com

Arsenale Lockpoint plugin is an option, but it is not free. Be careful, as after installing the trial version of this plugin the users of our Confluence received notifications "thank you for installing the Arsenale Lockpoint plugin for Confluence.", which was an unpleasant surprise.

Voted to have the attachment locks in the basic functionality!

Thanks.

Here's a new solution to that was released today:

Arsenale Lockpoint is a Confluence plugin that gives your company controlled versioning of Confluence attachments, allowing locking of individual files for exclusive editing

Learn more: http://www.arsenalesystems.com/products/arsenale-lockpoint

This would be a great feature, in many cases I have concurrent access to the same file, managing the lock or the notification that the file is in use would be cool.

It's just one of the "dodgyness" aspects of confluence. It needs to be fixed if people are to really like confluence. it doesn't take much for people to dislike a product and when something is dodgy it's just asking for it. currently we only use it in the IT dept. there's no way I would want the masses to start using it. Imagine how many support calls we would get for things like this! it would be a nightmare to support it. However, if it just worked and there were no issues like this then it would be a great product. The editor difinately is one of these dodgy parts of confluence. Let's hope the editor in version 4 is bug free.

as it is, there are only a handful of people in IT that like it but will everything fixed and with a better editor and if it would run faster as well then I think more people might use it.

I agree! please please can anyone update the planning of this feature?

It looks like you included a somewhat similar feature in 3.1 for the editing and restrictions of pages? That's awesome! Now you need to push forward that capability to attachments! Please?

Closed duplicate CONF-6012, with 25 votes noted, as of October 13, 2009.

A warning would do for us. We are using Confluence for New Product Development with a wide range of users. The Office connector has made it a great tool but we are concerned about overwritten attachments that have to be repaired.

I just voted for this issue.

We just got a user who expressed concern that two people on his team were editing the same attachment, and then overwrote one another's changes.

This user's team is still evaluating Confluence's usefulness, and this issue could be a big the deciding factor on whether they use Confluence or another system.

We can easily see this issue coming up again in the future, so it is very important to us.

We have looked at at the Attachment Checkout Plugin, but its sporadic updates (it hasn't yet been updated to work with Confluence 3.0), and its fundamental incompatibility with the Office Connector (which is used heavily at our company), make it not a good solution for us.

I've just voted for this.

I'm working with a company that is evaluating Confluence. While they like the idea of using Confluence for managing the many document attachments associated with projects. It would permit them to keep using subversion for development assets, but use Confluence for project documentation – today project documents are checked into subversion, and while that works, the experience isn't great. Developers are used to traditional version control, but project leads and managers would be happier with a user experience like Confluence. However, they need locking, which subversion provides as a capability.

An easy way to lock an attachment, preventing a new version of that attachment from being uploaded by any user other than the person who locked it, would allow them to use Confluence for this purpose.

Concur - the ability to do a check-out/check-in has become a top priority for our users.

It at least needs to notify the user that someone else has it such as occurs when a page is being edited. And it needs to notify them if the attachment has changed since they checked it out. If it is a lock, there needs to be a way to override the lock.

Are there any plans to implement this? – this is a huge pain point for us.

Less severe than locking is flagging as being edited - CONF-7339

<from Jens' email>

An idea for a macro would be to display all the attachments on a page and a button (check in/check out) next to it. When the button was clicked you will have to save the state of the document.

An advanced feature could be to hide the Attachments tab and only allow uploading documents via the macro. Then you would have full control over what state which document is in and could deny a download if the doc is checked out already.

I know that voting works, we use it in our JIRA here.

We are considering developing this feature for ourselves, but that leaves us
with a potentially non-compliant branch of software when Atlassian does its
own. That's why I wanted to know if this feature was actively being
developed. We could wait a while, if it was.

Also, Jens has helped me scope out a check in/check out macro that takes
this locking idea one step farther. Should I add that to your JIRA as a new
issue?

Thanks,
Tracey.

Anything in JIRA is 'on the radar', but we don't have a delivery date for this feature at the moment. Voting is not a waste of time, it's part of the process we use for deciding what features make it into which version.

Any updates on this "lockable attachments" issue?

I see periodic acknowledgement that this is an important aspect of Confluence as a corporate tool, but no suggestion that a solution is in the words. Is it even on the radar?

Yes, I voted for it.

Thanks!

Thanks for the suggestion. We're looking into ways that we can warn people about concurrent edits inside Confluence, and we'll add attachments to the list of things people want to see protected.