[mcproposition] Garder un historique et signaler les changements sur les fiches

Problème/bug rencontré sur le site, évolution/amélioration à proposer
NicoM
Messages : 380
Enregistré le : 29 juin 2013, 16:39
Localisation : strasbourg

[mcproposition] Garder un historique et signaler les changements sur les fiches

Message par NicoM » 09 oct. 2013, 20:39

Sujet d'origine était : faire apparaître dans nouvelles le changement d'état d'une cabane

J'ai remarqué aujourd'hui que le nombre d'hébergement est passé à 1660 (-1) car l'un d'entres eux est passé dans la catégorie fermée ou détruite (passé de 153 à 154).
Ce n'est qu'une proposition mais serait il intéressant qu'un changement d'état de ouvert à fermé ou son contraire apparaisse dans la page Les nouvelles ?
L'intérêt peut sembler faible à priori mais comme un tel changement peut visiblement arriver sans qu'un nouveau commentaire soit apparu sur la fiche du point ou sur le forum du point cet intérêt n'est peut être pas nul, ou peut être que si


mcwiki mchistorique mcrevision mvsuivi

Avatar du membre
sly
Messages : 3470
Enregistré le : 29 févr. 2004, 18:59
Localisation : Chambéry - Savoie
Contact :

Message par sly » 10 oct. 2013, 13:54

Carrément, c'est une bonne idée et avec plusieurs avantages :

Je me rappel en avoir discuté il y a super longtemps (mais j'ai rien fait depuis et je retrouve plus la discussion sacre-bleu) de l'idée qui était de conserver les actions faites sur les fiches (que ça soit les modérateurs ou l'auteur d'origine de la fiche)

Cela permettait par exemple de revenir en arrière sur une modification si on avait fait une erreur, de revenir (par nostalgie !) sur l'histoire d'une fiche (construite, brulée, reconstruite, agrandie, renarde de chaumaillou abattue ;-(( ) mais aussi, comme tu le proposes, de faire figurer dans les nouvelles les changements sur les fiches.

Aujourd'hui, le seul truc qui se rapproche un tout petit peu de ça c'est l'info "date de dernière mise à jour" pour une fiche. Et bon, c'est pas que ça sert à rien, mais presque si on ne sait pas ce qu'a été la modification !

Plein de bonnes idées donc (13 idées d'amélioration, 8 bugs à corriger) mais il nous manque des développeurs avec du temps ;-(

Avatar du membre
Claude Mauguier
Messages : 1728
Enregistré le : 08 avr. 2011, 15:31
Localisation : Isére

Message par Claude Mauguier » 11 oct. 2013, 11:20

+1
C'est vrai qu'un historique, même laconique, depuis la création de la fiche avec toutes les modifs associées, éviterait déjà les conflits de "paternité" et permettrait de suivre au jour le jour (*) le travail effectué.
Je précise que c'est moi qui ai "fermé" la cabane du Roc de la Pêche, car le fonds de commerce est mis en vente. Ceci étant, les gérants actuels n'ont peut-être pas mis la clef sous la porte, mais j'ai préféré anticiper afin que personne n'aille se casser le nez sur une porte fermée.

P.S.
L'astérisque placé a posteriori à la suite de cette expression vise à faire remarquer l'omission, à laquelle je m'astreins, de l'expression favorite correspondante, utilisée par la langue de bois journalistico-communiquante : "au quotidien", déjà baveuse en soi et promue au rang d'unicum ineffable et bien "dans la ligne" du P.C.U.

Avatar du membre
leosw
Messages : 456
Enregistré le : 28 févr. 2013, 18:28
Localisation : Sud Ouest
Contact :

Message par leosw » 23 nov. 2015, 22:16

Salut à tous,

Je fais remonter le sujet.

Pour ce qui est de l'aspect technique (comme sly le proposait sur une discussion que j'ai effacé cause doublon), on a de la discussion.

Pour ma part, je pense que la méthode est d'ajouter deux tables : fiches_histo et commentaires_histo dans lesquels on a exactement la même topologie que la table normale mais avec l'ajout d'un champ "révision".

Du coup on peut, pour chaque fiche (ou commentaire) sortir toutes les versions précédentes ordonnées.

Léo

Avatar du membre
sly
Messages : 3470
Enregistré le : 29 févr. 2004, 18:59
Localisation : Chambéry - Savoie
Contact :

Message par sly » 23 nov. 2015, 22:27

Ma suggestion à moi serait de n'avoir qu'une seule table "point" et une seule table commentaire avec un champs qui s'appel "date de dernière modif" un champ binaire "actif/inactif", un champ "auteur de cette version" et un champ version

Par défaut, tout le site ne fait toujours que "and actif"

Et lorsque l'on veut revenir à une version antérieure on fait un :
update point set actif=false where id=x and actif
puis
update point set actif=true where version=y and id=x
sur la version vers laquelle on souhaite retourner.


A chaque modif on ferait un truc genre :
insert into point (select * from point where id=x and actif) -> copie de la version actuelle de la fiche


Un courageux pour regarder comment c'est fait par "les autres" dans le monde des wiki (genre mediawiki) ?

Avatar du membre
sly
Messages : 3470
Enregistré le : 29 févr. 2004, 18:59
Localisation : Chambéry - Savoie
Contact :

Re: [mcproposition] Garder un historique et signaler les changements sur les fiches

Message par sly » 21 déc. 2017, 02:08

A défaut de voir comment font les autres, en cherchant des idées et des "best practices" je suis tombé sur cet article que je note ici quand je me plongerais là dedans :
https://esj.com/articles/2011/03/01/fiv ... ables.aspx

L'idée suggérée (dans sa version simple) reprend le principe que j'évoquais avec une seule table : existence dans la même table d'autant de lignes qu'il y a eu de modification d'une fiche. Sauf que je n'avais pas pensé que l'id qui était unique allait être différent pour chaque version d'une fiche et qu'il faudrait donc ajouter un champ pour garder le lien vers la précédente version. Dans l'article, l'idée est que le clé primaire n'est plus le id_point mais le couple id_point,date_modification de sorte que l'on puisse garder le même id pour toutes les versions d'un point, seul le plus récent étant l'actif."Actif" n'ayant plus de raison d'être un champ puisque le plus récent étant l'actif. Une modif consiste alors à dupliquer l'actif et mettre à jour la date_modification, il devient alors automatiquement le nouvel actif.

Il y aurait donc a ajouter seulement 3 champs : un champ date_modif, auteur_modif et pourquoi pas un champs "raison_modif"
La clé primaire étant alors id/date_modif et le champs d'auto-incrément restant valable pour les ajouts de nouveaux points.

A creuser parce que ça n'est pas tout à fait fini: les commentaires sont rattachés à un id de de fiche, il faudrait voir ce qu'on fait lorsqu'un commentaire est modifié/supprimé et à quelle(s) version de fiche ancienne il se rattache.
Et p'tet que les messages forum on va pas trop y toucher !

Bref, structurellement je vois à peu près comment faire, le code existant passant tout par les fonctions (modèle ? ;-) ) spécial "points" ça devrait pas trop faire de code à corriger/tester. Mais alors coté interface, faut pouvoir voir les anciennes versions, afficher les différences, et pouvoir revenir à n'importe quelle ancienne version.

Y'a du taf

Avatar du membre
leosw
Messages : 456
Enregistré le : 28 févr. 2013, 18:28
Localisation : Sud Ouest
Contact :

Re: [mcproposition] Garder un historique et signaler les changements sur les fiches

Message par leosw » 21 déc. 2017, 15:31

Salut,

J'ai implémenté ce mécanisme dans feu Kabano (que j'essaye de recoder rapidement).
En gros, la méthode est d'avoir deux tables :

* Liste des points (contient les données qui ne changent pas entre les versions : id, date de création, ainsi qu'un champ archive qui permet de cacher un point)
* Versions de chaque point (contient les données qui peuvent être éditées, ainsi qu'un champ archive, qui est vrai pour toutes les versions anciennes)

Cette topologie permet de restaurer une ancienne version facilement, et d'avoir une recherche dans la base hyper efficace.

Comme c'est un peu lourd, les commentaires ne sont que dans une table, et un utilisateur ne pourra pas modifier un commentaire mais l'archiver et en publier un nouveau.

Léo

Avatar du membre
sly
Messages : 3470
Enregistré le : 29 févr. 2004, 18:59
Localisation : Chambéry - Savoie
Contact :

Re: [mcproposition] Garder un historique et signaler les changements sur les fiches

Message par sly » 21 déc. 2017, 16:01

leosw a écrit :
21 déc. 2017, 15:31
* Liste des points (contient les données qui ne changent pas entre les versions : id, date de création, ainsi qu'un champ archive qui permet de cacher un point)
* Versions de chaque point (contient les données qui peuvent être éditées, ainsi qu'un champ archive, qui est vrai pour toutes les versions anciennes)
Avec ta structure elle est où la date de modification ? J'imagine dans la table "versions des points" ?
En tout cas le principe est similaire, mais la méthode que j'ai indiqué économise une table. La date de création étant simplement la date de la première modif, et le flag "archive" étant implicite en se servant des dates anciennes.

Mais on reste sur le même principe. L'autre option que j'ai pu lire étant la solution de double table style "points_courant" "point_historique" qui fait maigrir la table des points actifs mais qui oblige dans chaque bout de code de définir une table qu'on attaque mutante.

Les débats ne tranchent pas, selon les cas les deux se font

Répondre

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité