I’m not sure whether it’s Discourse Shared Edits or the wiki-posts feature, since both were enabled on this particular post to avoid one editor making others’ changes obsolete.
So one post with both wiki and shared edits enabled…
Bug description
Editor A makes revision 55 and presses “Done”.
Editor B goes straight to the revision history to see changes. Revision count shows 54 / 55, but there is no way to access revision 55. Once editor B has made a change, it was against revision 54, effectively removing revision 55 entirely.
Bug resolution
There is no way to circumvent this. Having multiple editors at once for a single post is not supported by the wiki mode, but shared edits seem to create this bug with wiki revisions. It would be nice to be able to use both (in the way that HedgeDoc does it), or to neutralize potential misfit between the two editing modes.
I think I’ve seen another aspect to this bug - but it might be unrelated.
When Shared Edits is turned on for a post, if it is edited too soon (within 20 seconds or so), then a clash seems to occur where only one or the other edits is saved. In other words, the Shared Edit functionality doesn’t actually kick in despite it appearing to be active. Things get very confusing if either author close and re-enter the post again, with edits appearing and disappearing.
If left alone for a while everything seems to sort itself out (albeit with loss of some content). Perhaps a brief 30 second lock of the posts when shared edits are turned on would prevent this?
After having this recur today with a well established Shared Edits + Wiki post, it seems that the problem is definitely the interaction between the two functionalities.
I’ve been using Shared Edits for a while between people with admin privileges without this cropping up. It is only when Wiki is enabled on the same post that we have the problem.
The obvious workaroud is to make all involved category moderators or TL4 so Wiki is not needed, but that has consequences.
Hm. This seems to be the reason why we loose edits on posts, where shared edits is on on a wiki. I naively used wiki mode to extend the range of allowed editors.
I suppose extending the range of allowed simultaneous editors to all readers without the backup features of wiki mode is not a good idea while other possibilities of backup (like a “Save a revision”-button) are lacking?
I think that this is still an issue - certainly caused chaos during an important meeting yesterday!
The problem is that it is quite common to need multiple people have edit access on a shared edits post, so the Wiki + Shared edits combo is highly useful.
Also, it is quite common to want to ‘upgrade’ a wiki post to a Shared Edits post for brief periods of intense synchronous activity. Personally, I think this is the best way to think of it, and the UI should match this - i.e. Shared Edits is an extension of wiki functionality, not an alternative.
Or perhaps Shared Edits could simply include edit access to the post as part of the package, and it becomes an either/or (with both impossible to select). I can’t really see why that would cause problems.
Since we’ve been hit by this bug, we’re using an external pad (HedgeDoc) and copy-paste the result in Discourse afterwards. It’s a bit annoying since Commonmark and HedgeDoc markdown show some differences (e.g., HD has notices, plenty of diagram plugins, etc. that Discourse does not have, and vice-versa, some Discourse markdown features are not available to HedgeDoc, e.g., the arrows: - + > = → and some emojis). But it’s much better than losing edits!