Améliorations des Shared-Edits

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 « J'aime »
2

Des nouvelles à ce sujet ? Nous l’avons « corrigé » en ajoutant

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

au CSS, mais il est évident que c’est une solution de contournement, pas une solution…

3 « J'aime »
3

Vous avez clairement expliqué comment la fonctionnalité wiki et les modifications partagées interagissent. Et ce n’est pas joli. Merci pour la solution de contournement / correction !!

Je l’ai intégrée dans mon petit composant Wikified Posts Component car c’est une petite amélioration agréable de la fonctionnalité wiki.

1 « J'aime »
5

Ah - je ne connaissais pas notre Composant, très utile (j’ai juste utilisé l’ancien pour colorer les Wiki-posts et je vais changer maintenant)

2 « J'aime »
7

Vous pouvez ajouter ceci à l’onglet common > header de votre thème (ou dans /common/header.html dans un composant distant), et cela ajoutera une classe shared-edits-post aux publications de modifications partagées si l’utilisateur actuel peut les modifier.

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

puis en CSS

.shared-edits-post {
  // faire quelque chose
}
5 « J'aime »
8

C’est fait !! Tout est maintenant intégré dans le composant Wikified Posts :

Merci Joe - tu as rendu tout cela possible !!

Ce que je dois vraiment cibler, c’est le premier bouton revision-footer-button (avec le texte « Modifier le Wiki ») et le masquer uniquement pour les publications avec des modifications partagées. Y a-t-il un moyen de faire en sorte que cette classe couvre également le panneau / la boîte de dialogue de révision ?

3 « J'aime »
9

J’ai poussé quelques modifications.

Ceci est corrigé. L’activation/désactivation du mode wiki sur un post de modification partagée affichera désormais le libellé correct.

Ceci est également corrigé. Si vous cliquez sur le bouton depuis la modale de l’historique des révisions ET que le post est défini sur shared-edit, le compositeur de modifications partagées s’ouvrira au lieu du compositeur par défaut.

J’ai ajouté la classe dans le plugin. Vous pouvez donc supprimer l’extrait que vous avez ajouté. Le plugin ajoutera désormais cette classe sans nécessiter de modification.

Je suppose que vous vouliez cela parce que le bouton ouvrait auparavant le compositeur par défaut ? C’est maintenant corrigé, vous n’aurez donc plus besoin de le masquer.

6 « J'aime »
10

C’est toujours un obstacle pour nous : nous essayons d’avoir le moins de modérateurs possible pour des raisons de confidentialité. Par conséquent, nous aimerions avoir une option permettant à quiconque peut démarrer un wiki de démarrer également les modifications partagées - en gros, c’est la même chose. D’ailleurs : nous avons nommé ce mode “WikiPad” - c’est plus frappant que les modifications partagées.

4 « J'aime »
11

Bien sûr, totalement ouvert à l’ajout d’un paramètre pour « les groupes autorisés à démarrer des modifications partagées », par défaut « personnel », mais vous permettant de le changer en ce que vous voulez.

8 « J'aime »
13

Quelles sont les chances que cela se produise ? Encore une fois, ce petit ajustement changerait la donne dans notre travail quotidien.

5 « J'aime »
14

Merci pour ce super plugin, qui s’intègre très bien à nos cas d’utilisation pour utiliser Discourse afin de prendre des notes collaborativement, de faire du brainstorming, etc. En examinant le plugin, j’ai cependant rencontré occasionnellement des bugs, qui sont malheureusement difficiles à reproduire de manière cohérente.

Ce que j’ai constaté, c’est qu’un changement effectué par l’utilisateur A est annulé lorsque l’utilisateur B met à jour le document, les deux changements étant explicitement sauvegardés à l’aide du bouton Enregistrer. Je suppose que cela pourrait être dû à la connectivité réseau et j’ai réussi à reproduire le comportement comme suit :

Je sais que cela semble assez artificiel, mais c’était la seule façon de reproduire le comportement que je rencontre de temps en temps. D’autres personnes ont-elles rencontré ce problème ? Y a-t-il peut-être même une solution ?

5 « J'aime »
15

Oui, je suis tombé sur un problème similaire avec une mauvaise connexion Internet, perdant parfois un tas d’éditions. C’est très frustrant. Peut-être qu’une détection de déconnexion pourrait fonctionner et passer à un tampon localStorage ou quelque chose comme ça. Peut-être utiliser un système basé sur localStorage d’abord et synchroniser plus tard… Je ne suis pas sûr de la façon dont c’est implémenté techniquement, mais il y a certainement des moments où avoir la synchronisation retardée de quelques millisecondes serait mieux que de perdre du texte.

3 « J'aime »
16

C’est toujours un problème énorme sur notre site. Peut-être que ces informations peuvent aider : voir cette modification dans l’historique :

image
image1177×229 14.6 KB

« system » est le compte racine du système. Pourquoi aucun compte utilisateur n’est-il affiché ? Une autre variante est la suivante :

image
image1187×188 14.8 KB

Il est toujours attribué au système, mais avec une information supplémentaire « modifié par xy ». Étrange.

1 « J'aime »
17

Salut @Ralf_Stockmann :slight_smile:

J’ai divisé vos publications dans un nouveau sujet UX pour éviter qu’elles ne soient supprimées par le timer de sujet. Je pense qu’il y a peut-être quelques problèmes qui méritent d’être suivis séparément (je pense que la correction de @Johani s’en est occupée ?). Si c’est le cas, faites-le moi savoir et nous pourrons créer un ou plusieurs nouveaux sujets pour eux. :+1:

3 « J'aime »
18

Merci - mais il me manque maintenant les publications de @literarymachine sur ce sujet (un de mes collègues) où il a souligné certaines conditions de concurrence liées au réseau de ce plugin, qui a) ne sont toujours pas corrigées et b) rendent ce plugin par ailleurs fantastique plutôt inutile pour un travail sérieux… ?

3 « J'aime »
19

Je pense que ce sera tout. :crossed_fingers:

3 « J'aime »
20

Cela s’est déjà présenté pour nous et serait très utile.

Une PR serait-elle utile pour cela ? Les PR de plugins officiels sont assez difficiles pour les pirates comme moi car elles nécessitent plus de configuration et d’expertise que ce que j’ai à portée de main !

21

Les Tl4 sont désormais autorisés à activer les modifications partagées, ce qui vous offre beaucoup plus de flexibilité.

Les RP sont invités à le transformer en un paramètre de site basé sur les groupes.

2 « J'aime »
22

Qu’en est-il des modérateurs ? Ou doivent-ils être promus au TL4 ?

Comme ils peuvent se promouvoir eux-mêmes au TL4 de toute façon, il serait logique de leur accorder à tous la capacité d’activer les modifications partagées.

1 « J'aime »