"Modération" des modifs dans un BDD

"Modération" des modifs dans un BDD - SQL/NoSQL - Programmation

Marsh Posté le 29-09-2011 à 15:46:44    

Bonjour à tous,
 
Prenons un exemple pour illustrer mon problème :
 
Je souhaite développer un site où les membres peuvent publier une annonce décrivant leur voiture. Leur du processus de création de l'annonce, ils sont amenés à remplir tout un tas de champs/cocher tout un tas de cases, etc, pour pouvoir entrer tout ce qui est nécessaire (description, critères, ...) dans la base de données.
 
On en vient à ma question : je souhaiterai que, une fois ce processus terminé, cette annonce ne soit pas publiée sur le site tant que l'administrateur ne l'approuve pas.
Bon a priori le plus simple est juste d'ajouter un champ dans ma bdd spécifiant si oui ou non cette annonce est validée. OK.
 
On en vient maintenant au vrai "problème". L'utilisateur aura toujours la possibilité d'éditer lui même son annonce (après publication sur le site), pour y modifier la photo, la description, que sais-je encore ... Mais encore une fois, ces modifications seront sujettes à la validation de l'administrateur, et en attendant cette validation l'annonce (dans son ancienne version) doit toujours etre disponible sur le site.
 
Du coup a priori il y a plusieurs possibilités : dupliquer chaque champ susceptible d'etre edité, ou alors avoir un duplicata de cette bdd (de ces tables) qui ferait tampon, i.e. stockerait les annonces apres modifs mais avant validation.
J'imagine qu'il y a d'autres solutions, possiblement encore meilleures.
 
Il me semble que ce genre de 'modération de modifications' est quelque chose qui est assez répandu, pourtant j'ai farfouillé des heures sur le net sans rien trouver de convaincant ... Un grand merci si vous avez la clé !
 
 
PS: Question subsidiaire : le top serait a la fin de voir immédiatement ce qui a été modifié par une opération qui trouverait la différence entre deux champs avant et apres modifs (pour voir par exemple quel mot a été changé). J'imagine que c'est possible en MySQL mais je sais pas trop quelle fonction utiliser. Mais bon, c'est accessoire, et c'est peut etre plus a voir coté javascript.
 
Merci encore

Reply

Marsh Posté le 29-09-2011 à 15:46:44   

Reply

Marsh Posté le 29-09-2011 à 16:09:43    

avoir deux tables : celle de tous les articles et une des articles publiées  
avoir une seul table et un moteur de template et générer le template html lors de la validation de la publication ou de la maj  
 
ou alors, plus simple : le fait de modifier l'annnonce la met hors ligne


---------------

Reply

Marsh Posté le 29-09-2011 à 16:28:06    

Faire comme dans SPIP : un statut pour l'article (ici, l'annonce) : brouillon, soumise à approbation, approuvée, publiée, supprimée... En fonction du statut, t'affiches ou pas l'annonce :/ Et comme proposé par flo850, si l'utilisateur modifie l'annonce, elle repasse dans un statut qui la retire temporairement de la publication.
 
Tu peux aussi mettre en cache les annonces publiées ce qui évite d'aller chercher les infos en base...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 29-09-2011 à 16:37:10    

Merci pour vos réponses, mais le but c'est justement de ne pas retirer l'annonce, et que en cas de refus des modifications, l'annonce reste comme avant.
 
J'essaye de m'inspirer des gestions de versions mais pas sûr que ce soit super pratique ...

Reply

Marsh Posté le 29-09-2011 à 16:59:11    

Comprends pas : l'admin ne veut pas que l'annonce soit publiée en l'état et toi, tu laisses le dernier mot à l'utilisateur :??:


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 29-09-2011 à 17:07:52    

Bah non :
 
1- L'utilisateur publie une annonce
 
2- L'admin valide. La version 1.0 de l'annonce est sur le site
 
3- L'utilisateur modifie son annonce. Version 1.1
 
4- L'administrateur n'apprécie pas les changements, il les refuse. La Version 1.0 reste sur le site et la 1.1 passe à la trappe

Reply

Marsh Posté le 03-10-2011 à 09:53:44    

Comme dit plus haut, travailles avec 2 tables, une tables avec toutes les annonces et une autre avec les annonces visible (publique).
 
L'utilisateur ne peut modifier que la table avec toutes les annonces et seul l'admin/moderateur peut faire passer les annonces d'une table a l'autre.
 
Si la modification est refusée la table publique ne change pas et la table avec toutes les annonces est mise a jour avec l'annonce publique.
Si c'est accepté la table publique est mise a jour avec les infos de l'annonce modifée.
Si l'utilisateur veut modifer 10x sont annonce avant que l'admin ai le temps d'y jetter un oeuil, pas de probleme l'admin ne verra jamais que la derniere version modifée sans avoir 10 copies qui traine.


Message édité par Oliiii le 03-10-2011 à 09:53:54
Reply

Marsh Posté le 03-10-2011 à 20:27:30    

Autre approche, avoir dans la table 2 enregistrements pour chaque annonce, celle validée et celle modifiée mais non validée (il peut y avoir les 2 simultanément ou une seule des 2) :)  
Avec les changement d'état suivants :
- à la création : 1 ligne est enregistrée, à l'état "modifiée"
- à la validation : l'annonce précédemment validée est supprimée (si elle existe) et celle à l'état "modifiée" passe à l'état "validée".
- lors d'une modification : on insère 1 ligne à l'état "modifiée" ou on modifie celle qui est déjà à cet état. L'annonce précédemment validée (si elle existe) n'est pas touchée
 
Après, on peut raffiner les choses en ajoutant des états (en particulier un état correspondant à l'envoi d'une annonce devant être validée, pour distinguer les demandes en cours de modification et celles que l'utilisateur estime terminées et en attente de validation).


Message édité par mrbebert le 03-10-2011 à 20:29:16

---------------
Doucement le matin, pas trop vite le soir.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed