Bonjour l'usine à gaz par rapport à la problématique.

Pour ma part, l'idée la plus simple, ce serait de ne pas poster après x temps dans une annonce de la même série.Le seul problème serait pour quelqu'un qui voudrait remonter plusieurs suggestions après un marathon, par exemple.Et je pense qu'une minute de délai serait suffisant.Je sais pas si cette méthode n'est pas aussi une usine à gaz, mais ce serait peut-être plus possible, plutôt que de faire partir des timers.

Le type qui remercie tous les sujets fait une recherche, il me semble.Et je suis même pas sûr qu'il rentre dans les sujets.S'il faut attendre une minute pour reposter, ça m'étonnerait que quelqu'un se fasse chier à attendre 10 minutes pour pouvoir poster dans 10 épisodes, sauf les vicieux.

bb a dit non, alors chut.

Belle façon de me dire "ferme ta gueule" et délicate, en plus.

Je cache les sujets des séries que je regarde pas, mais c'est pas toujours le cas.T'as peut-être raison, la fonction pour cacher les sujets reste la meilleure.

Juste pour dire que je suis d'accord avec BB, modérer est fait pour ça dans ce genre de cas qui n'arrive quand même que très rarement. Perso, j'ai vu les sujets remontés, ai trouvé ça marrant et suis retourné à mon codage sans rien faire.

Ben ça dépend, si ce n'est qu'une partie de programme qui sert juste pour la catégorie "épisodes" ça ne devrait pas prendre trop de ressources, et ça ne serait utile que quand l'utilisateur floodeur posterait. Non ?Avec une valeur fixe spécifique attribuée à chaque post (alpha ou beta) qui ferait que seuls les posts auxquels le alpha (+ de 10 mots) est attribué font remonter le topic. La fonction de remontage serait sur l'ordi de chaque utilisateur tandis que la fonction d'attribution de la valeur serait sur le serveur.

Ca pourrait être utile plus tard aussi pour d'autres catégories à grosses discussions dans lesquels un simple "lol" éviterait de remonter aussi le truc pour rien.

Mais dans ce cas faudrait aussi prévoir une fonction "up" pour les sujets importants pour lesquels on désire lire une réponse mais dans lesquels on évite de mettre 10 mots juste pour remonter le topic. 'Fin toussa est à voir avec vous.

Franchement, j'ai envie de dire que ce n'est pas si grave.

Je pense que Titou résume tout.

Ce genre de trucs n'arrivent qu'une fois par mois ou presque donc franchement, pourquoi se faire chier pour si peu ?

Comme tu insistes, je vais t'expliquer certaines choses. Ce sont des suppositions, donc Sixe corrigera le cas échéant.

Chaque fois qu'un utilisateur affiche l'accueil du forum. Une requête assez lourde est lancée. Elle va chercher dans la base de données le nombre requis de sujets correspondants aux paramètres de l'utilisateur qui est identifié ou les paramètres par défaut, si c'est un anonyme. Cette requête comporte une instruction de tri antéchronologique, basée sur un champs de la table des sujets, lui même mis à jour à chaque fois que quelqu'un crée un nouveau message dans un sujet. Pour mettre en place une solution qui permette d'outrepasser ce tri pour éviter que ne remontent certains sujets, il faudrait :

- Mettre en place un algorithme de notation des messages complexe et fatalement imparfait qui va analyser la pertinence d'un message en prenant en compte différents facteurs : longueur du message, nature et proportion des termes utilisés, habitude de postage de l'auteur, catégorie du sujet, similitude avec les messages récents du posteur, note moyenne des messages du posteur, message privé ou non, statut de l'utilisateur, etc.

Ensuite, il faut :- Soit conserver le tri antéchronologique mais ne pas mettre à jour la date de dernier message des sujets quand cette note est inférieure à un certain seuil, ce qui au passage fausse les informations de la base de données, peut être déroutant pour l'utilisateur et aura un impact non seulement sur l'affichage de la page d'accueil, mais aussi sur les recherches, sur l'affichage par tag, etc.. Particulièrement emmerdant pour les messages qui auront été mal analysés par l'algo.Note que ça empêchera fatalement de remonter des sujets qui le devraient pourtant. Mais en allant très loin dans la R&D sur l'algo, on doit pouvoir obtenir un résultat probant. Note aussi que ce sera pour tout le monde pareil. Impossible de conserver le fonctionnement antérieur pour ceux qui le veulent.

- Soit conserver le tri antéchronologique actuel et la mise à jour du champs date du dernier message posté mais expurger de la liste des résultats les sujets dont le dernier message est en dessous du seuil déterminé par notre algo. Avantage de la solution, ça peut être paramétrable et celui qui veut conserver le fonctionnement antérieur peut le faire. Sur le papier, ça parait chouette comme solution. Suffit de requêter sur les sujets dont la note du dernier message est en dessous du seuil. Ah mais non, je t'arrête, ne te réjouis pas trop vite. Çà ne pouvait pas être aussi simple. Car le dernier message non lu n'est pas le même pour tout le monde... Concrètement. Si tu as un message non lu en dessous du seuil sur un sujet, tu ne veux pas le voir remonter, mais si moi, j'en ai deux et que l'antépénultième est pertinent, je veux le voir remonter. Donc la seule solution c'est de requêter sur tous les sujets et une fois les résultats obtenus, analyser la date du dernier message non lu pertinent de l'utilisateur pour le retirer des résultats avant d'afficher ou le reclasser à sa bonne place. Ok, c'est faisable. Mais alors on risque de se retrouver avec moins de sujets à afficher que ce que l'utilisateur a sur sa page d'accueil en temps normal. La tuile. Mais rien n'est impossible donc, on peut requêter à nouveau. C'est magique. En résumé, on récupère les 50 derniers sujets, on en vire par exemple 15 qui n'auraient pas du être là si on retire les messages non pertinents. Il nous en manque, donc on relance la requête sur les 50 messages suivants, et on complète le set de résultats. Avec un peu de chance et si un connard s'est pas amusé à poster 200 merci en 5 minutes, 2 requêtes (lourdes, je le rappelle) auront suffit.

Note que ce traitement qui consiste à retirer les messages qui n'auraient pas du remonter peut être effectué côté client en javascript, comme tu le suggérais, mais les requêtes de récupération, elles, sont bien effectuées par le serveur.

Note aussi qu'avec une jointure bien sentie dans la requête, ça doit peut-être être possible d'éviter cette requête multiple (tout dépend de la façon dont est stockée l'information sur le dernier message non lu de chaque topic par chaque utilisateur, mais ne connaissant pas la structure de la base je ne peux que supputer). Mais niveau performance j'imagine même pas l'impact, mais il est sans doute pas bon. Car on réalise un tri sur une table jointe et pas sur la table principale de la requête. Sachant qu'on parle d'une base MySQL avec plusieurs millions d'enregistrements.

Bref, une usine à gaz. Tu comprends ce que je voulais dire, ou tu as encore des propositions à faire ?

Je mise tout sur les propositions supplémentaires.

Tout le monde n'a pas ton talent pour les formules percutantes. :)