search

zestedesavoir / zds-site

Cœur du projet technique de Zeste de Savoir
https://zestedesavoir.com
Other
268 stars 161 forks source link

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

Open firm1 opened 8 years ago

firm1 commented 8 years ago

Scénario :

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.

GerardPaligot commented 8 years ago

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

pierre-24 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166587469 .

firm1 commented 8 years ago

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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166580727 .

GerardPaligot commented 8 years ago

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 commented 8 years ago

@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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166589315 .

GerardPaligot commented 8 years ago

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 commented 8 years ago

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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166590495 .

firm1 commented 8 years ago

Ç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 < https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166590495

.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166593670 .

artragis commented 8 years ago

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 <

https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166590495

.

— Reply to this email directly or view it on GitHub < https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166593670

.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166596412 .

artragis commented 8 years ago

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 <

https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166590495

.

— Reply to this email directly or view it on GitHub < https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166593670

.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166596412 .

SpaceFox commented 8 years ago

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

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

firm1 commented 8 years ago

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 commented 8 years ago

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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166832787 .

pierre-24 commented 8 years ago

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 commented 8 years ago

(en effet)

artragis commented 8 years ago

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 https://github.com/zestedesavoir/zds-site/issues/3251#issuecomment-166839519 .

Anto59290 commented 7 years ago

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 :

V2 :

V3 :

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 commented 7 years ago

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

Anto59290 commented 7 years ago

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

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