Remove plan_sections and add replace locking mechanism with optimistic locking about roadmap

[briri]

Being done as part of the data model refactoring project

[raycarrick-ed]

Added lock_version to answers table. This triggers optimistic locking.
If you try to save with a lock_version < the current lock_version it throws a StaleObjectException.
When an answer is saved it calls answers#update expecting a JS response.
If the save works then the JS return only updates the lock_version otherwise the next save will fail.
An empty div is added to the answer_form partial.
If a staleObject gets caught then respionse uses this to display the conflicting answer and user.
The lock_version also gets updated so that next time the user saves it will succeed.
There's a fair amount of JS which was to do with locking which is no longer needed.
The answer timestamp also gets changed. It was working of 'created_at' rather than 'updated_at' because we used to created a new answer every time.

As part of this I have also tried to rationalise the testing of question_formats. They used to always be string comps. They now use an enum field.

I had also earlier added question_format constants to avoid string comps. This was an ugly solution and can now go.

[raycarrick-ed]

Commits:
DigitalCurationCentre@51c78fc
DigitalCurationCentre@2a9cead
DigitalCurationCentre@a9cc1b2
DigitalCurationCentre@a6f2a54

[briri]

looks great @raycarrick-ed. moving this on to 'Ready for PR'

[stephaniesimms]

This appears to be working as expected, however, we should consider adding a message to notify users that their answer was not saved/another user was editing the plan simultaneously. At present I receive the default timestamp message if I click Save during simultaneous editing - Answered 4 minutes ago by [email protected]

I only discover that my answer was not actually recorded when I refresh the page.
Would it be very complicated to add a message @raycarrick-ed ?

[raycarrick-ed]

Pulling this back to 'in progress' so I can revisit this

[briri]

this was addresses by fixes made for #241

[stephaniesimms]

The message looks great and answers save/overwrite as expected. It's still too easy to accidentally overwrite a collaborator's answer, however. In the screenshot below, if I click "Save" without deleting or combining my answer text in the lower box as advised, it overwrites the answer in the upper box.

Since we think this is an edge case, maybe it's not worth messing w/now. We can target this for future usability testing. What do you think @sjDCC ?

[sjDCC]

Yes, I agree this is a good case for future usability testing. People are likely to just hit save so it'd be easy to overwrite without incorporating changes. I also got confused about where the new text should go - in the top or bottom box (even though the guidance is clear when I re-read!).

Perhaps we need to add an additional bit of guidance text like:

"The edits in the box below will overwrite the existing answer from [user name] once you click save"

[stephaniesimms]

@sjDCC I like your suggestion about amending the message:
"The edits in the box below will overwrite the existing answer from [user name] once you click save"

[sjDCC]

Possibly grey out top box suggested by @vyruss

[briri]

Updated the messaging per @sjDCC suggestion above and greyed out/disabled the text box to prevent further confusion.

[stephaniesimms]

This looks good for now. Closing issue.