Suppression du système de notation des messages

Pour info rapide : J'ai pris en charge le dev' de la desanomysation cette aprem' des +1/-1 et c'est quasi fini.

<HS> Va falloir finir ça demain pour qu'on puisse fêter ça alors ! </HS>

En fait à un placement CSS prêt c'est Ok.

Dans ce cas là c'est limite le signalement qui s'impose. Mais ton arguments est tout à fait valable, tu me poses une colle

Honnêtement, je ne pense pas que cela apporte grand chose dans un tel cas : une réponse devra être donnée de toute manière pour donner une bonne solution et pour expliquer en quoi la précédente est mauvaise. Que la mauvaise solution soit diminuée ou non, le débutant sera quand même dans le flou en attendant.

Je pense que tu as oublié d'ajouter un lien.

Je sais et je n'ai pas l'intention de faire une nouvelle suggestion à ce sujet pour l'instant.

Qu'est-ce que tu entends par là ?

Cf. les posts de Kje ici et suivants : https://zestedesavoir.com/forums/sujet/2235/1-1-avec-affichage-des-votants/?page=2#p40540

Sachant que la fonctionnalité (d'afficher les pseudos) a été votée depuis longtemps, est-ce que ça vaut vraiment le coup d'anonymiser tout ça ? Du moins avant janvier/février…

Perso quand je vote, anonymement ou pas, j'assume pleinement, j'ai rien contre le fait que d'anciens votes se retrouvent publics (et puis au pire, on peut dire qu'il y a prescription) si techniquement c'est problématique autrement

Cf. les posts de Kje ici et suivants : https://zestedesavoir.com/forums/sujet/2235/1-1-avec-affichage-des-votants/?page=2#p40540

J'ai bien compris que c'était en rapport avec ça, c'est la mise en œuvre technique qui m'inquiète. Kje parlait de vérifier que le +1/-1 a été donné avant une certaine date : de ce que je vois du code en Python, tu ne fais rien de tel.

Si je comprends bien ta phrase, tu voudrais que tous les votes pré-existants soient attribués au compte utilisateur « anonyme ». Y'a deux problèmes.

• Les votes seront affichés, mais tous avec l'avatar d'anonyme. Genre, sur ce message, on va avoir 37 petites boites « anonyme », ce qui serait juste abominable.
• Si les votes sont attribués à anonyme, ça veut dire qu'on peut tous revoter là où on a déjà voté, vu qu'il n'y aura plus de vote attaché à notre compte. Et ça, ce serait vraiment gênant.

Les votes seront affichés, mais tous avec l'avatar d'anonyme. Genre, sur ce message, on va avoir 37 petites boites « anonyme », ce qui serait juste abominable.

Autant ca je m'étais fait à l'idée…

Si les votes sont attribués à anonyme, ça veut dire qu'on peut tous revoter là où on a déjà voté, vu qu'il n'y aura plus de vote attaché à notre compte. Et ça, ce serait vraiment gênant.

Autant ca j'avais zappé et ca va risquer de faire chi**

Depuis ce message, j'ai vu un rageur qui était impatient de savoir qui l'avait moinssé et un bonhomme qui attend aussi pour savoir (même s'il y a une dose d'humour dans son message). Et je suis très loin de lire tout le forum.

Pensez-vous vraiment qu'il ne va pas y avoir de soucis si on affiche le nom des votants antérieur à la MàJ ? Indépendamment des questions de justice ou de contrat implicite, de manière purement pragmatique, j'ai de bonnes raisons de penser que c'est un nid à emmerdes.

TODO : Faire un script qui attribue tout les anciens +1/-1 à anonyme lors de la mise en prod' pour ne pas fausser les utilisateurs ayant voté AVANT la feature.

Nope.

tu ajoutes un champ "is_new" qui vaut False par défaut, comme ça lors de la migration, il vaut False pour les vieux message. Et à chaque fois qu'on fait un like maintenant, il suffit de le mettre à True.

Comme ça tu as juste à faire un .filter(is_new=True) dans ta requête pour l'affichage et basta. En plus, pas d'effet de bord à signaler.

Plutot qu'un is_new pas du tout explicit, il vaudrait mieux un is_anonymous à True pour les anciens et False pour les nouveaux. Ce sera beaucoup plus clair et explicite ("le vote est marqué anonyme")

Pour ma part, je pense plutôt le contraire. Outre le fait que je suis curieux de connaitre les motivations de l'auteur du « moinssage » de mon message https://zestedesavoir.com/forums/sujet/3752/allumage-tres-long/?page=3#p68203 ce qui ne serait possible qu'en d'« désanonymisant » les appréciations message utile / message inutile au cas où il ne me répond pas, il me semble que dans la vraie vie, les affaires de corbeaux / lettres anonymes n'ont jamais eu d'effet apaisant, bien au contraire.

Par contre, et il faut bien distinguer le cas, si une fonctionnalité de vote était mise en place en sus de la notation de messages en utile / inutile, comme dans tout scrutin, l'anonymat devrait être respecté.

Peut-être faudrait-il envisager les possibilités simultanées suivantes (je ne fais que proposer, libre à vous d'en débattre ou de jeter aux orties directement ce qui suit ; par ailleurs, c'est peut-être HS par rapport au sujet du topic, ou trop tard car des décisions ont déjà été prises) :

• indiquer si le message nous parait utile / inutile (c'est actuellement le sens des pouces ; peut-être qu'un symbole type

Edit : (snif… la suite de mon beau message a disparu dès l'insertion d'un emoji ; pourtant à la prévisualisation, ça s'affichait ; y a-t-il espoir que la base de donnée contienne le reste de mon message ?)

La communauté a voté pour que les votants des +/-1 soit public. Soit. La seule question maintenant est de savoir comment doit se passer la transition. Je n'ai pas envie que des gens règlent leur compte a posteriori. Un -1 inique sera oublié dans une semaine.

De l'autre côté, mettons qu'il y ai perte de l'anonymat sur les anciens votes. Que vas-tu faire ? Que se passera-t-il si une dizaine de personne fait comme toi ?

Attention coté perf sur la table des likes/dislike. Ajouter une colonne dans une table aussi sollicitée (et encore plus avec la feature) et avec autant de lignes peut degrader anonymesr du SELECT * (qui est utilisé un peu partout dans le code). Surtout quand je vois l'utilité reelle de la colonne.

Perso au lieu de rajouter une colonne j'aurai plutot rajouté dans le fichier settings un parametre PK_END_LIKE_ANONYMOUS et PK_END_DISLIKE_ANONYMOUS qui designent les pk des derniers like/dislikes anonymes.

On garder ainsi une table avec un minimum de colonnes.

c'est vrai que ça peut très bien marcher comme ça firm1

Comment ça peut marcher ton truc ? À priori rien ne te garantit que les clés primaires sont séquentielles, et la dernière fois qu'on a supposé que ces clés primaires avaient un comportement défini, on s'est retrouvé avec le problème User vs Profile.

Une pk django est par defaut en autoincrement (cf la doc). Etant donné que le delete de django fait une DELETE SQL et pas un TRUNCATE on sait qu'à moins de faire un TRUNCATE explicite (qui n'est jamais une bonne idée), pour toute ligne x inserée apres une ligne x0, la valeur de la pk de x sera toujours >= la valeur de la pk de x0.

Je suis de l'avis de firm1.

Pour le coup, le gain en perfs apporté écrase le très faible risque qu'on observe un jour une désynchro. Et si jamais désynchro il y a (bien que cela semble bien improbable), il suffira de modifier les valeurs dans le fichier settings, et la seule perte éventuelle sera d'avoir désanonymisé des vieux votes.

Puisque Django nous garantit que ses clés primaires automatiques sont en séquentielles et que ces modèles utilisent les clés primaires automatiques, on peut faire comme ça.