共有編集の改善

貢献 UX
1

一見素晴らしい機能である共有編集モードの奇妙な動作について、さらにテストを行いました。その結果を以下にまとめます。

image
image423×303 12 KB

本プラグインは、編集への「アクセス権」そのものを付与するものではありません。つまり、モデレーター以外のユーザーにも投稿を共同編集させたい場合は、その投稿をウィキ（緑色のオプション）にする必要があります。

共有編集を有効にすると、ウィキ化も選択できます。しかし、「ウィキ化」オプションを通じてウィキ化を行っても、表示は引き続き「ウィキ化」となっています。実際にはウィキモードに移行しますが、ウィキ化を解除する方法がありません。

モデレーターは、コンポーザーバーのギアアイコン（赤）を通じて、トピック上で共有編集をオン/オフできます。

共有編集の開始/停止権限を、ウィキの開始/終了権限と連動させるオプションがあればと思います。機能は非常に類似しているため、なぜ異なる権限（モデレーターのみ）を設ける必要があるのでしょうか。

次に、これは致命的な問題です：

  1. 投稿をウィキ化し、かつ共有編集モードに設定しました。
  2. 何人かのユーザーが共有編集コンポーザーで編集を開始しました。
  3. 同時に、別の何人かのユーザーが、同じ投稿の「リビジョン」リンクを介して「クラシック」ウィキエディターを使用しました：

image
image849×235 24 KB

その後、下部にある「投稿を編集」をクリックします。

image
image1163×141 8.16 KB

すると、事態は急速に悪化します。本当にひどい状態です。多くの内容が上書きされ、変更が保存されず、リビジョンの競合が発生します。私の理解では、共有編集はクラシックなウィキ編集と「同時に」動作するように設計されていないようです（技術的な観点からは完全に理解できます）。

これを解決する最善の方法は、「投稿を編集」ボタンを新しい共有編集コンポーザーにリダイレクトすることではないでしょうか。

また、共有編集コンポーザーには投稿のメタデータ（タイトル、タグなど）を編集するオプションがないため、この点についても何らかの解決策が必要です。

「リビジョンの鉛筆アイコンから離れるようユーザーに伝えるだけでよい」という意見もあるかもしれませんが、現実はそうではありません。多くのユーザーは、長いウィキPad投稿の末尾までスクロールするよりも、この方法を選んでいます。

これは簡単には修正できない問題かもしれませんが、現状では共有編集機能は非常に壊れています。複数の投稿で異なるユーザーと共に試しましたが、常に競合が発生しました。

「いいね！」 9
2

これに関するニュースはありますか？CSSに以下を追加することで「修正」しましたが、明らかにこれは修正であって解決策ではありません…

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;
}
「いいね！」 3
3

ウィキ機能と共有編集がどのように連携するかを非常に明確に説明していただき、それがよろしくないことがわかりました。回避策/修正ありがとうございます!!

ウィキ機能のささやかな強化として、私のささやかな Wikified Posts Component に組み込みました。

「いいね！」 1
5

Ah、コンポーネントのことは知りませんでした。非常に便利ですね（ウィキ投稿の色付けには古いものを使っていましたが、今後は切り替えます）。

「いいね！」 2
7

テーマの 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
8

完了しました！すべてがWikified Posts Component にまとめられました。

ジョー、ありがとう - すべて可能になりました！
本当にターゲットにしたいのは、最初の revision-footer-button（「Edit Wiki」というテキスト付き）で、Shared Edits の投稿でのみ非表示にしたいです。リビジョンパネル/ダイアログもカバーするクラスを取得する方法はありますか？

「いいね！」 3
9

変更をいくつかプッシュしました。

これは修正されました。共有編集投稿のウィキのオン/オフを切り替えると、正しいラベルが表示されるようになりました。

これも修正されました。リビジョン履歴モーダルからボタンをクリックし、投稿が shared-edit に設定されている場合、デフォルトのコンポーザーではなく共有編集コンポーザーが開きます。

プラグインにクラスを追加しました。そのため、追加したスニペットを削除できます。プラグインは、変更なしでそのクラスを追加するようになりました。

ボタンが以前はデフォルトのコンポーザーを開いていたため、それを必要としていたと推測します。これは現在修正されており、非表示にする必要はなくなりました。

「いいね！」 6
Wikified Posts Component
10

これは私たちにとって依然として決定的な問題です。プライバシー上の理由から、できるだけ少ないモデレーターで済ませたいと考えています。そのため、ウィキを開始できる人は誰でも共有編集を開始できるようにするオプションを強く希望します。基本的に同じことです。ちなみに、このモードを「WikiPad」と名付けました。共有編集よりも印象的です。

「いいね！」 4
11

「共有編集を開始できるグループ」の設定を追加することに完全にオープンです。デフォルトは「スタッフ」ですが、好きなものに変更できます。

「いいね！」 8
Discourse Shared Edits
13

この件が実現する可能性はどのくらいですか？これは、私たちの日常業務において、まさにゲームチェンジャーとなるようなささやかな変更です。

「いいね！」 5
14

この素晴らしいプラグインは、Discourse を使用して共同でメモを取ったり、ブレインストーミングを行ったりするというユースケースに非常によく適合しています。プラグインを調べているうちに、時折グリッチが発生することがありましたが、残念ながら一貫して再現するのが難しいものでした。

ユーザー A が行った変更が、ユーザー B がドキュメントを更新したときに元に戻されてしまうという現象が発生しました。どちらの変更も Save ボタンで明示的に保存されていました。ネットワーク接続が原因である可能性があり、以下の手順でその動作を再現することに成功しました。

  • 両方のブラウザは、ドキュメントの共有状態から開始します。
    image
    image726×578 29.1 KB
  • ブラウザ 2 が接続を失います（ただし、ユーザーはそれに気づきません）。
    image
    image1911×865 178 KB
  • ブラウザ 1 が変更を保存します。
    image
    image789×577 164 KB
  • ブラウザ 2 がオフラインのまま変更を加えます。
    image
    image1102×594 80.7 KB
  • ブラウザ 2 がオンラインに戻り、変更を保存します。
    image
    image1918×866 173 KB
  • ブラウザ 2 で行われた変更が保存され、ブラウザ 1 で行われた以前の変更が元に戻されます。
    image
    image852×753 290 KB

これはかなり人工的な状況ですが、時折発生する動作を再現できた唯一の方法です。他にこの問題に遭遇した人はいますか？修正方法はありますか？

「いいね！」 5
15

はい、悪いインターネット接続で同様の問題に遭遇しました。時にはかなりの量の編集を失うこともあります。これは非常にイライラします。おそらく、切断検出が機能し、localStorageバッファなどに切り替えることができるでしょう。おそらく、localStorageを最初に使い、後で同期する…技術的にどのように実装されているかはわかりませんが、同期が数ミリ秒遅延しても、テキストを失うよりも良い場合があります。

「いいね！」 3
16

これは私たちのサイトで依然として大きな問題です。この情報がお役に立つかもしれません。履歴のこの編集をご覧ください。

image
image1177×229 14.6 KB

「system」はシステムルートアカウントです。ユーザーアカウントが表示されないのはなぜですか？別のバリエーションは次のとおりです。

image
image1187×188 14.8 KB

これはまだシステムに割り当てられていますが、「xyによって編集済み」という追加情報が付いています。奇妙です。

「いいね！」 1
17

こんにちは @Ralf_Stockmann さん :slight_smile:

トピックのタイムアウトで失われないように、投稿を新しい UX トピックに分割しました。いくつか別々に追跡する価値のある問題があるように思われます（@Johani さんの修正でいくつか対処されたと思いますか？）。もしそうなら、お知らせください。新しいトピックを作成できます。 :+1:

「いいね！」 3
18

ありがとうございます。しかし、このトピックに関する同僚の @literarymachine による投稿が現在見当たりません。彼はこのプラグインのネットワーク関連の競合状態について指摘していましたが、a) それらはまだ修正されておらず、b) このそうでなければ素晴らしいプラグインを真剣な作業にはほとんど役に立たないものにしています。

「いいね！」 3
Test our new composer!
19

これで全部だと思います。:crossed_fingers:

「いいね！」 3
20

これは私たちにとっても課題となっており、非常に役立つでしょう。

PR（プルリクエスト）は役に立ちますか？公式プラグインのPRは、私のようなハッカーにとっては非常に困難です。なぜなら、私がすぐに利用できる以上のセットアップと専門知識が必要だからです！

21

Tl4は共有編集の切り替えが可能になり、より柔軟性が向上しました。

PRはサイト設定をグループベースに変更できます。

「いいね！」 2
22

モデレーターはどうですか？それともTL4に昇格する必要がありますか？

彼らはすでにTL4に自分で昇格できるため、共有編集を有効にするすべての権限を付与するのが理にかなっています。

「いいね！」 1