[bug] published research updates can be overwritten

[iSCJT]

Describe the bug If 2 users have the same research article open at the same time to add an update then whoever publishes first can have their update overwritten when the second user publishes.

To Reproduce Steps to reproduce the behaviour:

1. Open the same research article in 2 different browsers
2. Click on add update in both browsers
3. Add update and save using browser 1, refresh the article to see that the update has been added
4. Add update and save using browser 2, refresh the article to see that the update has been added and browser 1 update is no longer present.
5. Refresh browser 1 and see that the original update is no longer there.

Expected behaviour Updates should be atomic and any updates added to the research article should not be overwritten.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Same problem would occur if any kind of modification is being made to the research article at the same time, possibly even a comment. Need to reduce / eliminate use of cached docs for any crud operations for docs that have multiple potential users modifying. Should also be more specific about which fields are being updated in the doc rather than sending a full new doc each time. In progress pr for useful buttons incudes an update function that can handle partial docs.

[davehakkens]

Something like this PR? https://github.com/ONEARMY/community-platform/pull/2217

[iSCJT]

Yes locking the record would definitely help ~although from my testing I haven't encountered any locks when trying to edit with multiple users~ because the pr hasn't been merged. I'll do some digging.

[runecodedev]

This could help to solve this bug:

1. Save user date when started to typing new content
2. After submiting changes check if date from step 1 is older than latest article update date a) if yes - cancel submiting and display error message smth like "Please copy your current progress and refresh the page, because article has been updated recently" b) if no - just submit changes with success message

Hope it helps :)

[CDeighton]

Hey, I wasn't sure if this one was still needed because of the linked PR (#2217)

But it sounded like an optimistic locking problem to me. I spun up a small proof of concept change here - https://github.com/ONEARMY/community-platform/pull/2455 if people are happy with the direction of it I'm happy to carry on with it

[iSCJT]

@thisislawatts as 2217 is yours can you take a look at this please.

[thisislawatts]

Closing via #2217