Je ne suis pas sûr s’il s’agit de Discourse Shared Edits ou de la fonctionnalité wiki-posts, car les deux ont été activées sur ce post particulier pour éviter qu’un éditeur ne rende obsolètes les modifications des autres.
Donc, un post avec les modes wiki et shared edits activés…
Description du bug
L’éditeur A effectue la révision 55 et clique sur « Terminé ».
L’éditeur B se rend directement dans l’historique des révisions pour voir les modifications. Le compteur de révisions affiche 54 / 55, mais il n’y a aucun moyen d’accéder à la révision 55. Une fois que l’éditeur B a effectué une modification, elle s’est faite contre la révision 54, supprimant ainsi complètement la révision 55.
Résolution du bug
Il n’y a aucun moyen de contourner cela. Avoir plusieurs éditeurs en même temps pour un seul post n’est pas pris en charge par le mode wiki, mais les shared edits semblent créer ce bug avec les révisions wiki. Il serait souhaitable de pouvoir utiliser les deux (de la manière dont HedgeDoc le fait), ou de neutraliser les incompatibilités potentielles entre les deux modes d’édition.
C’est un problème délicat, le problème est que cela a un énorme potentiel pour gonfler les décomptes de révisions à des niveaux énormes si 2 éditeurs modifient simultanément.
Je vais voir si je peux ajouter un paramètre de site au plugin pour désactiver l’effondrement des modifications par plusieurs utilisateurs.
Je pense avoir vu un autre aspect de ce bug - mais il pourrait ne pas être lié.
Lorsque les modifications partagées sont activées pour un article, s’il est modifié trop tôt (environ 20 secondes), un conflit semble se produire où seule l’une ou l’autre des modifications est enregistrée. En d’autres termes, la fonctionnalité de modification partagée ne s’active pas réellement malgré son apparence active. Les choses deviennent très confuses si l’un ou l’autre auteur ferme et rouvre l’article, avec des modifications apparaissant et disparaissant.
Si on le laisse tranquille pendant un moment, tout semble se régler (bien qu’avec une perte de contenu). Peut-être qu’un bref verrouillage de 30 secondes des articles lorsque les modifications partagées sont activées pourrait éviter cela ?
Après avoir constaté à nouveau ce problème aujourd’hui avec un article “Éditions partagées + Wiki” bien établi, il semble que le problème réside définitivement dans l’interaction entre les deux fonctionnalités.
J’utilise les Éditions partagées depuis un certain temps entre personnes ayant des privilèges d’administrateur sans que cela ne se produise. C’est seulement lorsque le Wiki est activé sur le même article que nous rencontrons le problème.
La solution évidente consiste à faire de tous les participants des modérateurs de catégorie ou TL4 afin que le Wiki ne soit pas nécessaire, mais cela a des conséquences.
Hm. Cela semble être la raison pour laquelle nous perdons des modifications sur les publications où les modifications partagées sont activées sur un wiki. J’ai naïvement utilisé le mode wiki pour étendre la plage des éditeurs autorisés. Je suppose qu’étendre la plage des éditeurs simultanés autorisés à tous les lecteurs sans les fonctionnalités de sauvegarde du mode wiki n’est pas une bonne idée, alors que d’autres possibilités de sauvegarde (comme un bouton « Enregistrer une révision ») font défaut ?
Je pense que c’est toujours un problème - cela a certainement semé le chaos lors d’une réunion importante hier !
Le problème est qu’il est très courant que plusieurs personnes aient besoin d’un accès de modification sur un article avec modifications partagées, de sorte que la combinaison Wiki + Modifications partagées est très utile.
De plus, il est très courant de vouloir « mettre à niveau » un article wiki vers un article avec modifications partagées pendant de courtes périodes d’activité synchrone intense. Personnellement, je pense que c’est la meilleure façon de voir les choses, et l’interface utilisateur devrait correspondre à cela - c’est-à-dire que les modifications partagées sont une extension de la fonctionnalité wiki, pas une alternative.
Ou peut-être que les modifications partagées pourraient simplement inclure l’accès de modification à l’article dans le cadre du package, et cela deviendrait un choix exclusif (les deux étant impossibles à sélectionner). Je ne vois vraiment pas pourquoi cela causerait des problèmes.
Depuis que nous avons été touchés par ce bug, nous utilisons un pad externe (HedgeDoc) et nous copions-collons le résultat dans Discourse par la suite. C’est un peu gênant car le markdown de Commonmark et celui de HedgeDoc présentent quelques différences (par exemple, HD a des notices, de nombreux plugins de diagrammes, etc. que Discourse n’a pas, et vice-versa, certaines fonctionnalités markdown de Discourse ne sont pas disponibles pour HedgeDoc, par exemple, les flèches : - + => → et certains emojis). Mais c’est beaucoup mieux que de perdre des modifications !