共享编辑改进

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:

and then at the bottom Edit Post

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 个赞

有关于此事的任何消息吗?我们通过将以下内容添加到 CSS 中来“修复”它:

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

但很明显,这是一个修复,而不是解决方案……

3 个赞

您清晰地阐述了 wiki 功能和共享编辑是如何交互的。而且这并不好看。感谢您的变通方法/修复!!

我已将其整合到我的小型 Wikified Posts Component 中,因为它是对 wiki 功能的一个很好的小改进。

1 个赞

啊——我不知道我们的组件,非常有用(我刚刚用旧的来给 Wiki-帖子着色,现在将切换)。

2 个赞

您可以将此添加到您的主题的 common > header 选项卡中(或远程组件中的 /common/header.html),如果当前用户可以编辑共享编辑帖子,它将为共享编辑帖子添加 shared-edits-post 类。

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

然后在 CSS 中

.shared-edits-post {
  // do some work
}
5 个赞

完成!!现在已全部整合到 Wikified Posts Component 中:


谢谢 Joe - 使一切成为可能!!

我真正需要定位的是第一个 revision-footer-button(带有“Edit Wiki”文本),并仅为 Shared Edits 帖子隐藏它。有什么方法可以使该类也覆盖修订面板/对话框?

3 个赞

我推送了一些更改。

此问题已修复。现在,在共享编辑帖子中切换 wiki 的开启/关闭将显示正确的标签。

此问题也已修复。如果您从修订历史记录模态框中单击该按钮,并且帖子设置为 shared-edit,它将打开共享编辑编辑器而不是默认编辑器。

我在插件中添加了该类。因此,您可以删除您添加的代码片段。该插件现在将添加该类,而无需进行任何修改。

我猜您之所以需要这样做是因为该按钮以前会打开默认编辑器?现在已修复,因此您不再需要隐藏它。

6 个赞

这对我们来说仍然是一个无法解决的问题:出于隐私原因,我们尽量减少版主的数量。因此,我们非常希望有一个选项,让任何能够启动维基的人也能启动共享编辑——基本上是相同的。顺便说一句:我们给这种模式命名为“WikiPad”——比共享编辑更引人注目。

4 个赞

当然,完全可以添加一个“允许发起共享编辑的组”的设置,默认设置为“staff”,但允许您根据需要进行更改。

8 个赞

这有多大可能实现?再说一次——这个小小的调整将彻底改变我们日常的工作。

5 个赞

感谢您提供的这个很棒的插件,它非常适合我们使用 Discourse 来协同记录笔记、头脑风暴等用例。在使用该插件的过程中,我偶尔会遇到一些故障,但遗憾的是很难稳定地重现。

我遇到的情况是,用户 A 所做的更改在用户 B 更新文档时被撤销了,而这两项更改都已通过“保存”按钮明确保存。我猜测这可能是由网络连接引起的,并设法通过以下方式重现了该行为:

我知道这看起来有些人为,但这似乎是我偶尔会遇到的唯一一种重现该行为的方式。其他人是否遇到过此问题?是否有可能修复它?

5 个赞

是的,我遇到过类似的问题,当时网络连接很差,有时会丢失很多编辑内容。这非常令人沮丧。也许可以实现某种断线检测,然后切换到 localStorage 缓冲区或其他东西。也许可以优先使用 localStorage,然后稍后同步……我不确定技术上是如何实现的,但肯定有些时候,将同步延迟几毫秒比丢失文本要好。

3 个赞

这仍然是我们网站上的一个巨大问题。也许这些信息会有帮助:请看历史记录中的这个编辑:

“system”是系统根帐户。为什么没有显示用户帐户?另一种变体是:

它仍然分配给系统,但带有额外的“由 xy 编辑”信息。奇怪。

1 个赞

你好 @Ralf_Stockmann :slight_smile:

我已经将你的帖子分到了一个新的 UX 主题中,以防止它们被主题计时器吞没。我认为其中可能包含一些值得单独跟踪的问题(我认为 @Johani 的修复处理了一些?)。如果是这样,请告诉我,我们可以为它们创建一个新的主题。:+1:

3 个赞

谢谢 - 但我现在找不到 @literarymachine 关于这个话题的帖子(他是我的一位同事),他在帖子中指出了这个插件的一些与网络相关的竞态条件,这些条件 a) 仍然没有修复,b) 使这个本已很棒的插件对于严肃的工作来说几乎毫无用处……?

3 个赞

我认为就这样了。:crossed_fingers:

3 个赞

这对我们来说非常有用。

提交一个 PR 会有帮助吗?像我这样的业余爱好者在官方插件 PR 方面会遇到很多困难,因为它们需要比我现有的知识和技能更多的设置和专业知识!

Tl4 现在可以切换共享编辑,这为您提供了更大的灵活性。

PR 欢迎将其切换为基于组的网站设置。

2 个赞

版主呢?还是他们需要被提升到 TL4?

既然他们无论如何都可以将自己提升到 TL4,那么授予他们激活共享编辑的所有能力是有意义的。

1 个赞