Shared-Edits Improvements

UX
1

We did some further testings on odd behaviours of the - otherwise great - shared edit mode. Here are some findings:

image

Note that the plugin does not enable edit access per se. This means that if you want non-moderators to be able to collaboratively edit the post you must also make the post a Wiki (green, optional):

If I enabled Shared Edits, I have the option to make it a wiki, too. But if I do so via the Make Wiki option, it still reads “Make Wiki”. It will enter Wiki mode, though. But there is no way to revoke the Wiki.

Moderators can toggle shared edits on a topic (red) via the gear icon on the composer bar

I would like to see an option, where the right to start/stop shared edits is linked to the right to start/end a wiki. The functionality is quite similar, why choosing different rights (mods only)?

Now this is a critical one:

  1. I set a posting into wiki and shared edit mode
  2. Some people start editing away in the shared edit composer
  3. Some other people use the “classic” wiki editor - via the revisions link on the same posting at the same time:

image
image849×235 24 KB

and then at the bottom Edit Post

image
image1163×141 8.16 KB

Now things get ugly real quick. Like - reeeealy ugly. Lots of overwritten stuff, changes not saved, revision conflicts. My understanding is, that shared edits is not designed to work at the same time as classic wiki editing (completely understandable from a technical view).

I figure the best way to solve this would be to redirect the Edit Post button to the new shared edits composer?

Hence the shared edits composer doesn’t offer the option to edit the metadata of the posting (titel, tags etc.), there has to be a solution for that, too.

One could argue “just tell your people to stay away from the revisions-pencil”, but this is not how it works - a lot of our users like this way instead of scrolling down to the end of a long WikiPad posting.

I see this might not an easy one to be fixed, but right now the shared edits feature is quite broken. We’ve tried it on several postings with different people, and always conflicts arose.

9 Likes
2

Any news on this? We “fixed” it by adding

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;
}

to the CSS, but quite obviously this is a fix, not a solution…

3 Likes
3

You have articulated really clearly how the wiki functionality and the shared edits interact. And it isn’t pretty. Thanks for the workaround / fix!!

I rolled it into my little Wikified Posts Component as it is a nice little enhancement of wiki functionality.

1 Like
5

Ah - I didn’t knew about our Component, very useful (I just used the old one to color Wiki-posts and will switch now)

2 Likes
7

You can add this to your theme common > header tab (or in /common/header.html in a remote component), and it will add a shared-edits-post class to shared-edit posts if the current user can edit them.

<script type="text/discourse-plugin" version="0.8">
  api.addPostClassesCallback((attrs) => {
    if (attrs.shared_edits_enabled && attrs.canEdit) return ["shared-edits-post"];
  });
</script>

then in CSS

.shared-edits-post {
  // do some work
}
5 Likes
8

Done!! It is all rolled into the Wikified Posts Component now:

Thanks Joe - made it all possible!!

What I really need to target is the first revision-footer-button (with the text Edit Wiki) and hide it for Shared Edits posts only. Any way to get that class to cover the revision panel / dialogue too?

3 Likes
9

I pushed a few changes.

This is fixed. Toggling wiki on/off on a shared edit post will now show the correct label.

This is also fixed. If you click the button from the revision history modal AND the post is set to shared-edit it will open the shared-edits composer instead of the default one.

I added the class in the plugin. So, you can remove the snippet you added. The plugin will now add that class without needing any modification.

I’m guessing you wanted that because the button used to open the default composer? That’s now fixed, so you won’t need to hide it anymore.

6 Likes
10

This is still a dealbreaker for us: we try to have as few moderators as possible for privacy reasons. Hence we would LOVE to have an option that everyone who can start a wiki can also start the shared edits - basically it’s the same. By the way: we named this mode “WikiPad” - it’s more striking than shared edits.

4 Likes
11

Sure totally open to add a setting for “groups that are allowed to start shared edits” default to “staff” but allow you to change it to whatever you want.

8 Likes
13

What are the chances to make this happen? Again - this little tweak would be a gamechanger in our everyday work.

5 Likes
14

Thanks for this great plugin, which fits in really well with our use-cases to use Discourse to collaboratively take notes, brainwrite etc. While examining the plugin I have occasionally experienced glitches though, which are unfortunately hard to consistently reproduce.

What I have experienced is that a change done by user A is undone when user B updates the document, both changes being explicitly saved using the Save-button. I am assuming it could be caused by network connectivity and managed to reproduce the behavior as follows:

I know this seems quite artificial, but it was the only to reproduce the behavior I am experiencing every now and then. Has anybody else encountered this issue? Is there perhaps even a fix for it?

5 Likes
15

Yes I stumbled across a similar issue with a bad Internet connection, sometimes losing quite a bunch of edits. This is very frustrating. Maybe some disconnection detection could work and switch to a localStorage buffer or something. Maybe using a localStorage-first and synchronize later… I’m not sure how it is implemented technically, but surely there are some times where having the synchronization delayed by a few milliseconds would be better than losing text.

3 Likes
16

This is still a huge issue on our site. Maybe thsi information may help: see this edit in the history:

image
image1177×229 14.6 KB

“system” is the system root account. Why is there no user account displayed? Another variant is this:

image
image1187×188 14.8 KB

It’s still assigned to system, but with an additional “edited by xy” info. Strange.

1 Like
17

Hi @Ralf_Stockmann :slight_smile:

I’ve split your posts into a new ux topic to stop them getting eaten by the topic-timer. I think there may be a couple of issues included that may be worth tracking separately (I think @Johani’s fix dealt with some?). If so, let me know and we can create a fresh topic(s) for them. :+1:

3 Likes
18

Thanks - but I’m missing now the postings by @literarymachine on this toppic (a colleague of mine) where he pointed out some network-related race-conditions of this plugin, which a) are still not fixed and b) render this otherwise fantastic plugin rather useless for serious work…?

3 Likes
19

I think that should be it. :crossed_fingers:

3 Likes
20

This has come up for us and would be super helpful.

Would a PR be useful for this? Official Plugin PRs are pretty challenging for hacks like me as they require more setup and expertise that I have readily at hand!

21

Tl4 are now allowed to toggle shared edits, so this gives you a fair bit more flexibility

Pr is welcome to switch it to a group based site setting

2 Likes
22

How about moderators? Or do they need to be bumped up to TL4?

As they can bump themselves up to TL4 anyway, it would make sense to grant them all the ability to activate Shared Edits.

1 Like