Verbesserungen an Shared-Edits

[Ralf_Stockmann]

Wir haben weitere Tests zu seltsamen Verhaltensweisen des – ansonsten großartigen – geteilten Bearbeitungsmodus durchgeführt. Hier sind einige Erkenntnisse:

Hinweis: Das Plugin aktiviert nicht per se den Bearbeitungszugriff. Das bedeutet, dass Sie, wenn Sie möchten, dass Nicht-Moderatoren Beiträge gemeinsam bearbeiten können, den Beitrag auch als Wiki markieren müssen (grün, optional):

Wenn ich „Geteilte Bearbeitungen" aktiviere, habe ich die Option, den Beitrag auch als Wiki zu markieren. Wenn ich dies jedoch über die Option „Als Wiki markieren" tue, steht dort weiterhin „Als Wiki markieren". Der Beitrag wechselt zwar in den Wiki-Modus, aber es gibt keine Möglichkeit, das Wiki-Status wieder zurückzunehmen.

Moderatoren können geteilte Bearbeitungen in einem Thema (rot) über das Zahnrad-Symbol in der Composer-Leiste ein- oder ausschalten

Ich würde gerne eine Option sehen, bei der das Recht, geteilte Bearbeitungen zu starten/beenden, mit dem Recht verknüpft ist, ein Wiki zu starten/beenden. Die Funktionalität ist ziemlich ähnlich, warum also unterschiedliche Rechte wählen (nur für Moderatoren)?

Nun kommt der kritische Punkt:

1. Ich setze einen Beitrag in den Wiki-und geteilten Bearbeitungsmodus.
2. Einige Leute beginnen, im Composer für geteilte Bearbeitungen zu editieren.
3. Einige andere Leute nutzen gleichzeitig den „klassischen" Wiki-Editor – über den Link „Revisionen" am selben Beitrag:

und dann unten auf „Beitrag bearbeiten":

Jetzt wird es schnell richtig hässlich. Wirklich hässlich. Viele überschriebene Inhalte, nicht gespeicherte Änderungen, Versionskonflikte. Meines Wissens ist der geteilte Bearbeitungsmodus nicht dafür ausgelegt, gleichzeitig mit der klassischen Wiki-Bearbeitung zu funktionieren (technisch absolut nachvollziehbar).

Ich denke, der beste Weg, dies zu lösen, wäre, den Button „Beitrag bearbeiten" zum neuen Composer für geteilte Bearbeitungen umzuleiten.

Da der Composer für geteilte Bearbeitungen keine Option bietet, die Metadaten des Beitrags (Titel, Tags usw.) zu bearbeiten, muss auch dafür eine Lösung gefunden werden.

Man könnte einwenden: „Sagen Sie Ihren Nutzern einfach, sie sollen den Stift für Revisionen nicht anfassen", aber so funktioniert es nicht – viele unserer Nutzer bevorzugen diese Methode, anstatt zu einem langen WikiPad-Beitrag nach unten zu scrollen.

Ich sehe ein, dass dies nicht einfach zu beheben sein wird, aber aktuell ist die Funktion „Geteilte Bearbeitungen" ziemlich kaputt. Wir haben es an mehreren Beiträgen mit verschiedenen Personen ausprobiert, und immer traten Konflikte auf.

[Ralf_Stockmann]

Gibt es Neuigkeiten dazu? Wir haben es „behoben“, indem wir

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

zu den CSS hinzugefügt haben, aber offensichtlich ist das eine Behebung und keine Lösung …

[nathank (Nathan Kershaw)]

@Ralf_Stockmann

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

Sie haben wirklich klar artikuliert, wie die Wiki-Funktionalität und die gemeinsamen Bearbeitungen interagieren. Und es ist nicht schön. Danke für den Workaround / die Lösung!!

Ich habe es in meine kleine Wikified Posts Component integriert, da es eine nette kleine Verbesserung der Wiki-Funktionalität ist.

[Ralf_Stockmann]

Ah – das wusste ich nicht über unsere Komponente, sehr nützlich (ich habe gerade die alte verwendet, um Wiki-Beiträge zu färben und werde jetzt wechseln)

[Johani (Joe)]

Sie können dies zu Ihrem Thema auf der Registerkarte common > header (oder in /common/header.html in einer Remote-Komponente) hinzufügen. Dies fügt der Klasse shared-edits-post Beiträge mit gemeinsam genutzten Bearbeitungen hinzu, wenn der aktuelle Benutzer diese bearbeiten kann.

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

dann in CSS

.shared-edits-post {
  // do some work
}

[nathank (Nathan Kershaw)]

@m4ur1c3

Möchte eine Theme-Komponente wie „Wikified Posts Component“ dafür erstellen können.

Erledigt!! Es ist jetzt alles in der Wikified Posts Component zusammengefasst:

Wikified Posts Component

Have just updated the component to better cater for Shared Edits posts. This includes adapting it for the Shared Edits changes here:

---

@Johani

.shared-edits-post

Danke Joe – du hast alles möglich gemacht!!

Ich muss wirklich den ersten revision-footer-button (mit dem Text „Edit Wiki“) ansprechen und ihn nur für Shared Edits-Posts ausblenden. Gibt es eine Möglichkeit, diese Klasse auch auf das Revisionsfenster/-dialogfeld anzuwenden?

[Johani (Joe)]

Ich habe ein paar Änderungen vorgenommen.

DEV: improve interaction between wiki and shared-edit posts

@Ralf_Stockmann

Wenn ich Shared Edits aktiviere, habe ich auch die Möglichkeit, es zu einem Wiki zu machen. Aber wenn ich dies über die Option Make Wiki tue, steht dort immer noch „Make Wiki“. Es wird zwar in den Wiki-Modus wechseln. Aber es gibt keine Möglichkeit, das Wiki zu widerrufen.

Dies ist behoben. Das Umschalten von Wiki auf einem Shared Edits-Beitrag zeigt nun die richtige Beschriftung an.

@Ralf_Stockmann

Ich denke, der beste Weg, dies zu lösen, wäre, den Button Edit Post zum neuen Shared Edits-Composer umzuleiten?

Dies ist ebenfalls behoben. Wenn Sie auf den Button aus dem Revisionsverlauf-Modal klicken UND der Beitrag auf shared-edit gesetzt ist, wird der Shared Edits-Composer anstelle des Standard-Composers geöffnet.

@nathank

Wenn Sie herausfinden, wie Sie Shared Edits-Beiträge ansprechen können

Ich habe die Klasse im Plugin hinzugefügt. Sie können den von Ihnen hinzugefügten Snippet also entfernen. Das Plugin fügt diese Klasse nun hinzu, ohne dass Änderungen erforderlich sind.

@nathank

Was ich wirklich ansprechen muss, ist der erste revision-footer-button (mit dem Text Edit Wiki) und ihn nur für Shared Edits-Beiträge ausblenden

Ich vermute, Sie wollten das, weil der Button früher den Standard-Composer geöffnet hat? Das ist jetzt behoben, sodass Sie ihn nicht mehr ausblenden müssen.

[Ralf_Stockmann]

[Zitat=“Ralf_Stockmann, Beitrag:1, Thema:232713”]
Ich würde gerne eine Option sehen, bei der das Recht, gemeinsame Bearbeitungen zu starten/stoppen, an das Recht zum Starten/Beenden eines Wikis gekoppelt ist. Die Funktionalität ist recht ähnlich, warum also unterschiedliche Rechte wählen (nur Mods)?
[/Zitat]

Das ist für uns immer noch ein Dealbreaker: Wir versuchen, aus Datenschutzgründen so wenige Moderatoren wie möglich zu haben. Daher würden wir es LIEBEN, eine Option zu haben, bei der jeder, der ein Wiki starten kann, auch die gemeinsamen Bearbeitungen starten kann - im Grunde ist es dasselbe. Übrigens: Wir haben diesen Modus “WikiPad” genannt - er ist einprägsamer als gemeinsame Bearbeitungen.

[sam (Sam Saffron)]

Sicher, ich bin absolut offen dafür, eine Einstellung für „Gruppen, denen das Starten gemeinsamer Bearbeitungen gestattet ist“ hinzuzufügen. Standardmäßig ist diese auf „Mitarbeiter“ eingestellt, aber Sie können sie nach Belieben ändern.

[Ralf_Stockmann]

Wie hoch sind die Chancen, dass dies geschieht? Nochmals – diese kleine Änderung wäre ein Wendepunkt in unserer täglichen Arbeit.

[literarymachine]

Vielen Dank für dieses großartige Plugin, das sich sehr gut in unsere Anwendungsfälle einfügt, um Discourse für gemeinsame Notizen, Brainstorming usw. zu nutzen. Bei der Untersuchung des Plugins habe ich jedoch gelegentlich Störungen erlebt, die leider schwer konsistent zu reproduzieren sind.

Was ich erlebt habe, ist, dass eine Änderung von Benutzer A rückgängig gemacht wird, wenn Benutzer B das Dokument aktualisiert, wobei beide Änderungen explizit mit der Schaltfläche “Speichern” gespeichert werden. Ich gehe davon aus, dass dies durch Netzwerkprobleme verursacht werden könnte, und es ist mir gelungen, das Verhalten wie folgt zu reproduzieren:

• Beide Browser starten mit einem gemeinsamen Zustand des Dokuments:
  
  
• Browser 2 verliert die Verbindung (aber der Benutzer bemerkt dies nicht):
  
  
• Browser 1 speichert eine Änderung:
  
  
• Browser 2 nimmt eine Änderung vor, während er noch offline ist:
  
  
• Browser 2 ist wieder online und speichert die Änderung:
  
  
• Die in Browser 2 vorgenommene Änderung wird gespeichert und macht die vorherige Änderung von Browser 1 rückgängig:
  
  

Ich weiß, dass dies ziemlich künstlich erscheint, aber es war die einzige Möglichkeit, das Verhalten zu reproduzieren, das ich immer wieder erlebe. Ist dieses Problem schon bei anderen aufgetreten? Gibt es vielleicht sogar eine Lösung dafür?

[hellekin]

@literarymachine

Ist das schon jemandem aufgefallen?

Ja, ich bin auf ein ähnliches Problem mit einer schlechten Internetverbindung gestoßen, manchmal gehen dabei ziemlich viele Bearbeitungen verloren. Das ist sehr frustrierend. Vielleicht könnte eine Art Disconnect-Erkennung funktionieren und auf einen localStorage-Puffer oder so etwas umgeschaltet werden. Vielleicht erst localStorage und später synchronisieren… Ich bin mir nicht sicher, wie es technisch umgesetzt ist, aber es gibt sicherlich Zeiten, in denen es besser wäre, die Synchronisierung um ein paar Millisekunden zu verzögern, als Text zu verlieren.

[Ralf_Stockmann]

Dies ist immer noch ein riesiges Problem auf unserer Website. Vielleicht helfen diese Informationen: siehe diese Änderung im Verlauf:

„system“ ist das System-Root-Konto. Warum wird kein Benutzerkonto angezeigt? Eine weitere Variante ist diese:

Es ist immer noch dem System zugeordnet, aber mit zusätzlichen Informationen „bearbeitet von xy“. Seltsam.

[JammyDodger]

Hallo @Ralf_Stockmann

Ich habe deine Beiträge in ein neues #ux-Thema verschoben, damit sie nicht vom Thema-Timer gefressen werden. Ich glaube, es gibt ein paar Probleme, die es wert sind, separat verfolgt zu werden (ich glaube, @Johani’s Fix hat sich mit einigen befasst?). Wenn ja, lass es mich wissen und wir können ein oder mehrere neue Themen dafür erstellen.

[Ralf_Stockmann]

Danke – aber mir fehlen jetzt die Beiträge von @literarymachine zu diesem Thema (ein Kollege von mir), in denen er einige netzwerkbezogene Race Conditions dieses Plugins aufzeigte, die a) immer noch nicht behoben sind und b) dieses ansonsten fantastische Plugin für ernsthafte Arbeiten eher nutzlos machen…?

[JammyDodger]

Ich glaube, das sollte alles sein.

[nathank (Nathan Kershaw)]

@sam

Sicher, ich bin absolut offen dafür, eine Einstellung für „Gruppen, denen das Starten gemeinsamer Bearbeitungen gestattet ist“ hinzuzufügen, standardmäßig auf „Mitarbeiter“ gesetzt, aber Sie können sie nach Belieben ändern.

Das ist auch bei uns aufgetaucht und wäre sehr hilfreich.

Wäre ein PR hierfür nützlich? Offizielle Plugin-PRs sind für Hacker wie mich ziemlich herausfordernd, da sie mehr Einrichtung und Fachwissen erfordern, als ich zur Verfügung habe!

[sam (Sam Saffron)]

Tl4 dürfen jetzt gemeinsam genutzte Bearbeitungen umschalten, was Ihnen deutlich mehr Flexibilität gibt.

Pr kann dies in eine gruppenbasierte Website-Einstellung ändern.

[nathank (Nathan Kershaw)]

@sam

Tl4 dürfen jetzt gemeinsame Bearbeitungen umschalten

Wie sieht es mit Moderatoren aus? Oder müssen sie auf TL4 hochgestuft werden?

Da sie sich ohnehin auf TL4 hochstufen können, wäre es sinnvoll, ihnen die Möglichkeit zu geben, gemeinsame Bearbeitungen zu aktivieren.