Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

La rédaction collaborative fait perdre le texte rédigé si le co-auteur valide son texte avant le mien #3251

Open
firm1 opened this issue Dec 21, 2015 · 22 comments
Open

La rédaction collaborative fait perdre le texte rédigé si le co-auteur valide son texte avant le mien #3251

firm1 opened this issue Dec 21, 2015 · 22 comments
Labels
C-Back Concerne le back-end Django S-Régression Corrige un problème sur un composant qui fonctionnait auparavant

Comments

@firm1
Copy link
Contributor

firm1 commented Dec 21, 2015

Scénario :

  • Je co-écrit un aticle avec un auteur
  • Le co-auteur est en train de modifier une section pendant que moi je suis en train de mettre à jour l'introduction et la conclusion tous les deux depuis l'interface en ligne
  • Le co-auteur valide son message avant le mien.
  • quand j'essaye de valider le mien j'ai un message qui me dit qu'une autre version est passée avant la mienne ==> bien. Le problème c'est que dans les zone de rédaction, j'ai perdu tout le contenu que j'avais commencé à rédiger dans les zones d'intro et de conlusion.

Il me semble pourtant que c'était possible avant (j'avais déjà rencontré ce cas et c'était géré correctement), je note donc en regression.
@firm1 firm1 added S-Régression Corrige un problème sur un composant qui fonctionnait auparavant C-Back Concerne le back-end Django labels Dec 21, 2015
@GerardPaligot
Copy link
Member

Il y a un mécanisme qui tente de sauvegarder le contenu rédigé dans l'éditeur non soumis de ZdS ? oO

@pierre-24
Copy link
Member

Non. Et je suis presque sur qu'il n'y en a jamais eu. Ceci dit, il en faudrait un parce que ce que décrit firm1 est un peu pénible ^^

@artragis
Copy link
Member

Faudra surtout que firm1 apprenne la différence entre regression et bug. Ce comportement a été ajouté lors de la version 1 et ce de manière volontaire car on n'avait pas le temps de faire un truc bien propre !

@GerardPaligot
Copy link
Member

Ce comportement a été ajouté lors de la version 1 et ce de manière volontaire car on n'avait pas le temps de faire un truc bien propre !

Ca veut dire qu'il y avait quelque chose avant ?

@artragis
Copy link
Member

des erreurs.

Le 22 décembre 2015 à 12:22, Gérard Paligot notifications@github.com a
écrit :

Ce comportement a été ajouté lors de la version 1 et ce de manière
volontaire car on n'avait pas le temps de faire un truc bien propre !

Ca veut dire qu'il y avait quelque chose avant ?

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@firm1
Copy link
Contributor Author

firm1 commented Dec 22, 2015

La différence entre avant et apres la régression est qu'avant, lorsque le
système te répondais qu'il y'a eu un nouvelle version pendant que je
rédigeais la mienne, le contenu de la zone de rédaction restait inchangé.
Donc on garde tout de même son texte sous la main que l'on peut resoumettre
si l'on juge la soumission légitime. Comme sur les forums quoi.

Le fonctionnement aujourd'hui (post zep12) ne remet pas notre texte dans la
zone de rédaction. C'est la que se situe la régression.

Le mar. 22 déc. 2015 11:56, artragis notifications@github.com a écrit :

Faudra surtout que firm1 apprenne la différence entre regression et bug.
Ce comportement a été ajouté lors de la version 1 et ce de manière
volontaire car on n'avait pas le temps de faire un truc bien propre !

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@GerardPaligot
Copy link
Member

A mon avis, cela dépendait surtout de ton navigateur parce qu'il n'y a rien dans le code de ZdS qui te garantit cette sauvegarde de tes écrits.

@firm1
Copy link
Contributor Author

firm1 commented Dec 22, 2015

@GerardPaligot: si si. Il suffit, lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

C'est le même principe qui est utilisé pour gérer les conflits de
soumission sur le forum.

Le mar. 22 déc. 2015 12:28, Gérard Paligot notifications@github.com a
écrit :

A mon avis, cela dépendait surtout de ton navigateur parce qu'il n'y a
rien dans le code de ZdS qui te garantit cette sauvegarde de tes écrits.

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@GerardPaligot
Copy link
Member

lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

Commence par là dude. :)

@artragis
Copy link
Member

en plus ce que tu dis est faux firm1 avant la zep-12 on te disait "une
nouvelle version est a été postée" et c'est CE TEXTE LÀ qu'on te redonnait.
Et on avait dit "un jour mon mettra une interface de merge !

Mais voilà, ce jour n'est pas venu.

Le 22 décembre 2015 à 12:35, Gérard Paligot notifications@github.com a
écrit :

lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

Commence par là dude. :)

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@firm1
Copy link
Contributor Author

firm1 commented Dec 22, 2015

Ça ne sert a rien de s'énerver. Si ça s'arrange de penser que le
comportement était le même avant tant mieux (même si ce n'est pas ce que me
dis le code). Le plus important est de se concentrer sur la résolution du
problème. Et normalement il suffit de faire ce que @GerardPaligot a cité ci
dessus.

Le mar. 22 déc. 2015 12:51, artragis notifications@github.com a écrit :

en plus ce que tu dis est faux firm1 avant la zep-12 on te disait "une
nouvelle version est a été postée" et c'est CE TEXTE LÀ qu'on te redonnait.
Et on avait dit "un jour mon mettra une interface de merge !

Mais voilà, ce jour n'est pas venu.

Le 22 décembre 2015 à 12:35, Gérard Paligot notifications@github.com a
écrit :

lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

Commence par là dude. :)

—
Reply to this email directly or view it on GitHub
<
#3251 (comment)

.

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@artragis
Copy link
Member

Ce n'est pas une question d'énervement mais de justesse. Car justement le
code (que j'avais fait...) dit ceci :

Donc c'est pas que ça "m'arrange" c'est que le code est comme ça.

Le 22 décembre 2015 à 13:03, firm1 notifications@github.com a écrit :

Ça ne sert a rien de s'énerver. Si ça s'arrange de penser que le
comportement était le même avant tant mieux (même si ce n'est pas ce que me
dis le code). Le plus important est de se concentrer sur la résolution du
problème. Et normalement il suffit de faire ce que @GerardPaligot a cité ci
dessus.

Le mar. 22 déc. 2015 12:51, artragis notifications@github.com a écrit :

en plus ce que tu dis est faux firm1 avant la zep-12 on te disait "une
nouvelle version est a été postée" et c'est CE TEXTE LÀ qu'on te
redonnait.
Et on avait dit "un jour mon mettra une interface de merge !

Mais voilà, ce jour n'est pas venu.

Le 22 décembre 2015 à 12:35, Gérard Paligot notifications@github.com a
écrit :

lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

Commence par là dude. :)

—
Reply to this email directly or view it on GitHub
<

#3251 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#3251 (comment)

.

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@artragis
Copy link
Member

et j'ajouterai que NON il ne "suffit" pas de faire ce que dit andro : car
là on écraserait la version qui a été générée.

Pour les tutos et articles, c'est compliqué de faire un truc qui soit
vraiment utile. Si on règle ça, on aura une killer feature par rapport à OC
mais en attendant, on n'a pas ça.

Le 22 décembre 2015 à 13:11, francois dambrine artragis@gmail.com a écrit
:

Ce n'est pas une question d'énervement mais de justesse. Car justement le
code (que j'avais fait...) dit ceci :

Donc c'est pas que ça "m'arrange" c'est que le code est comme ça.

Le 22 décembre 2015 à 13:03, firm1 notifications@github.com a écrit :

Ça ne sert a rien de s'énerver. Si ça s'arrange de penser que le
comportement était le même avant tant mieux (même si ce n'est pas ce que
me
dis le code). Le plus important est de se concentrer sur la résolution du
problème. Et normalement il suffit de faire ce que @GerardPaligot a cité
ci
dessus.

Le mar. 22 déc. 2015 12:51, artragis notifications@github.com a écrit :

en plus ce que tu dis est faux firm1 avant la zep-12 on te disait "une
nouvelle version est a été postée" et c'est CE TEXTE LÀ qu'on te
redonnait.
Et on avait dit "un jour mon mettra une interface de merge !

Mais voilà, ce jour n'est pas venu.

Le 22 décembre 2015 à 12:35, Gérard Paligot notifications@github.com
a
écrit :

lorsque ton formulaire n'est pas valide
(c'est a la validation du formulaire qu'on verifiait la possibilité de
conflit) de rebalancer ton formulaire avec son ancien contenu.

Commence par là dude. :)

—
Reply to this email directly or view it on GitHub
<

#3251 (comment)

.

—
Reply to this email directly or view it on GitHub
<
#3251 (comment)

.

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@SpaceFox
Copy link
Contributor

En première approche, je dirais qu'il faudrait pouvoir avoir sur chaque champ :

  • Un gros avertissement type « Ceci a été modifié entre-temps »
  • « Votre version »
  • « La version modifiée »

Donc soit doublonner le champ, soit trouver une combine… dans tous les cas ce n'est pas simple.

@firm1
Copy link
Contributor Author

firm1 commented Dec 23, 2015

Donc c'est pas que ça "m'arrange" c'est que le code est comme ça.

effectivement, mes yeux lisaient le morceau qui concerne l'affichage de la preview plutôt que la soumission du formulaire. Dans ce cas, le comportement existait déjà (c'est bizarre parce que je suis certain d'être déjà tombé sur ce cas et que le comportement était bon).

Sinon, en ce qui concerne la résolution de l'issue. Qu'est ce qui fait que l'on soit obligé d'écraser la version qui a été générée si on vérifie le formulaire avant ? Lorsque le formulaire est soumis, il ne faudrait créer le commit que si le formulaire est valide (et donc si on a pas de conflit sur le hash des fichiers modifiés).

@artragis
Copy link
Member

Sinon, en ce qui concerne la résolution de l'issue. Qu'est ce qui fait que l'on soit obligé d'écraser la version qui a été générée si on vérifie le formulaire avant ? Lorsque le formulaire est soumis, il ne faudrait créer le commit que si le formulaire est valide (et donc si on a pas de conflit sur le hash des fichiers modifiés).

si tu remets à l'utilisateur ce que lui a entré, alors tu ne lui donnes pas
ce qui a été modifié, il n'a aucune conscience de l'état du commit. Il
faudrait a la limite lui proposer un "diff view" en plus du formulaire.
diff view où on aurait appliqué son "patch" avec les conflits de merge.

Le 23 décembre 2015 à 09:27, firm1 notifications@github.com a écrit :

Donc c'est pas que ça "m'arrange" c'est que le code est comme ça.

effectivement, mes yeux lisaient le morceau qui concerne l'affichage de la
preview plutôt que la soumission du formulaire. Dans ce cas, le
comportement existait déjà (c'est bizarre parce que je suis certain d'être
déjà tombé sur ce cas et que le comportement était bon).

Sinon, en ce qui concerne la résolution de l'issue. Qu'est ce qui fait que
l'on soit obligé d'écraser la version qui a été générée si on vérifie le
formulaire avant ? Lorsque le formulaire est soumis, il ne faudrait créer
le commit que si le formulaire est valide (et donc si on a pas de conflit
sur le hash des fichiers modifiés).

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@pierre-24
Copy link
Member

On peut "facilement" présenter une "diff view" puisqu'on a déjà du code pour ça pour l'historique d'un contenu (y'a un templatetag, non ?)

@pierre-24
Copy link
Member

(en effet)

@artragis
Copy link
Member

omagad, on se met à faire du peugeot "et ce module? oui, zds l'a".

2015-12-23 10:13 GMT+01:00 Pierre Beaujean notifications@github.com:

(en effet
http://zds-site.readthedocs.org/fr/latest/front-end/template-tags.html#le-module-htmldiff
)

—
Reply to this email directly or view it on GitHub
#3251 (comment)
.

@artragis artragis mentioned this issue Jan 11, 2016
Open
3 tasks
@Anto59290
Copy link
Contributor

Anto59290 commented Jan 10, 2017 •
edited
Loading

En première approche, je dirais qu'il faudrait pouvoir avoir sur chaque champ :

- Un gros avertissement type « Ceci a été modifié entre-temps »
- « Votre version »
- « La version modifiée »

Donc soit doublonner le champ, soit trouver une combine… dans tous les cas ce n'est pas simple.

Ayant un peu de temps libre en ce moment, je me suis penché la dessus. J'aime bien l'approche itérative proposée par @SpaceFox . Je propose le plan d'action suivant :

V1 :

  • On affiche le diff grâce au templatetag, à l'utilisateur de faire son merge à la main. C'est un peu long pour le cas où chaque auteur à écrit un pavé, mais c'est une première solution satisfaisante. On a le minimum viable.

V2 :

  • On peut merger à la main avec une interface qui propose un split screen avec les options classique d'un merger-tool. Plus complexe mais on peut s'en sortir. Si il n'y a pas d'outil libre satisfaisant il faut prévoir une bonne dose de JS.

V3 :

  • On ajoute les options genre Auto merge, All yours, All Mine, etc. On détecte si le merge auto est possible grâce à des infos que l'on récupère d'un outils externe (git-merge). On gère les cas d'édition très complexe (edit par 3 ou + utilisateurs en même temps ?). On a une killer feature.

Je bosse en ce moment sur la V1 et j'ai réussi à avoir un POC en environ 30 minutes. Je pense que l'on problème est pas si complexe que ça. Aujourd'hui je récupère les deux versions d'éditions et affiche la différence. Ça reste un POC il faut donc que je démultiplie sur plusieurs champs par page, réalise un front correct et ajoute des tests.

Je pense que pour l'éditeur : http://www.mergely.com/editor fait un bon candidat (merci aux notes @artragis )

@pierre-24
Copy link
Member

N'hésite pas à proposer ton POC qu'on puisse y regarder :)

@Anto59290
Copy link
Contributor

Alors je suis passé un peu à l'étape 1.5 en intégrant Mergely. Le repo de travail est dispo ici : https://github.com/Anto59290/zds-site/tree/3251_git_diff_2 si tu veux tester @pierre-24 .

Je suis pas méga familié de l'ajout de lib dans le projet donc j'espère que ça marche bien. Sinon il suffit de faire npm install mergely pour tester ;)

Procédure de test

  • Créer un tuto
  • Editer le tuto (le contenu, sinon ça ne marchera pas, c'est la seule page ou c'est implémenté pour le moment) dans deux onglets différents. Ca ne marche que pour l'introduction pour l'instant
  • Onglet A : valider le text A.
  • Onglet B : valider le text B --> Erreur : apparition de l'interface de merge. Possiblité de merger à la main. A la fin du merge, cliquer sur Merger puis sur valider tout en bas du formulaire.
  • Eat pop corn !

Avantage de cette méthode : je n'ai pas touché à Git. Inconvénient : l'historique sera un peu moins précis, puisque la notion de merge (du point de vue Git) n'apparait pas.

La lib est pas mal foutu, on a accès à des callbacks et des méthodes qui permettent de faire plus ou moins ce qu'on veut... sauf l'auto merge.

merge

@Anto59290 Anto59290 mentioned this issue Jan 12, 2017
Closed
@Arnaud-D Arnaud-D moved this to À trier in Suivi des tickets Dec 17, 2022
@Arnaud-D Arnaud-D mentioned this issue Oct 12, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-Back Concerne le back-end Django S-Régression Corrige un problème sur un composant qui fonctionnait auparavant
Projects
Suivi des tickets
Status: À trier
Milestone
No milestone
Development

No branches or pull requests
6 participants
@artragis @GerardPaligot @SpaceFox @firm1 @Anto59290 @pierre-24