Ajouter le bordel avec les titres, trophées, etc. #10

Ajouter ça dans la classe Member. Éventuellement créer d'autres classes pour gérer ça facilement, typiquement avec une méthode unlock overidée pour chaque trophée, qui vérifie si l'utilisateur a débloqué le trophée/titre.

Après réflexion, on aurait juste une classe Trophy et une relation pour savoir qui a débloqué quoi.

Ensuite, on aurait une fonction update_trophies(*args) qui testerait les trophées pour savoir si de nouveaux ont été obtenus. On l'appelle à chaque fois qu'un trophée peut être débloqué, avec éventuellement une liste d'actions indiquant le type de trophées concernés pour limiter le nombre de tests. Typiquement :

current_user.update_trophies("new-post")

Je suis dessus, par contre je me rends compte que c'est pas spécialement une bonne idée de séparer les titres des trophées. Je pense qu'on peut juste mettre un flag is_title dans la classe Trophy, ça fera bien l'affaire (et ça simplifiera grandement le code).

À ce point-là ? Et comment tu gères le CSS alors, un champ vide pour les trophées ?

Bon j'ai gardé les deux classes distinctes, même si je ne suis pas particulièrement satisfait par ma solution.

Actuellement les admins peuvent lister les trophées/titres, en ajouter, les modifier et les supprimer.

Il reste à faire :

la fonction pour checker si l'utilisateur en a validé
l'option pour valider un trophée à la main pour ceux non-automatiques. Pour les autres ça risque d'être overridé par un update automatique.
le support des icones de trophées (y'a quelques bouts d'implémentation qui ont été faits, pas tous)

J'ai relu ton code et poussé quelques modifications très mineures. Merci beaucoup 😀

Je pense que tu as oublié, lors de la suppression d'un trophée, de retirer ce trophée à tous les utilisateurs qui en disposaient.

Edit : Au temps pour moi, c'est automatique.

Pourquoi ajouter un nom spécial pour les titres ? Il suffirait d'afficher le nom du trophée, en plus ça porterait moins à confusion.

Par rapport à l'automatisme, est-ce que du coup ça vaut pas le coup de virer cette méthode delete de la classe Member ?

Je ferais bien un test de plus, mais s'il s'avère que les privilèges spéciaux disparaissent tous seuls alors effectivement cette méthode n'est pas justifiée dans l'immédiat.

Toutefois elle le sera dans le futur car on ne veut pas que la suppression d'un membre entraîne la suppression de tous les contenus qu'il a postés sur le site. (!!!)

Heu, c'est pas très RGPD ce que tu dis là… 😕

Il faudrait au moins que ce soit une option de conserver les contenus anonymement...

Le commit du dessus résout :

la fonction pour checker si l’utilisateur en a validé
l’option pour valider un trophée à la main pour ceux non-automatiques. Pour les autres ça risque d’être overridé par un update automatique.
le support des icones de trophées (y’a quelques bouts d’implémentation qui ont été faits, pas tous)

Je passe ce dernier point en nouveau ticket, de même que l'ajout des règles pour l'update automatique. Je pense qu'avec ça on peut clore le ticket actuel.

J'ai un problème/bug/? avec le formulaire de suppression de trophée, il semble avoir du retard. Lorsque j'ajoute le premier trophée la liste déroulante reste vide. Lorsque je supprime le dernier trophée elle le propose encore après soumission du formulaire.

Il y a peut-être un effet de cache de navigateur, mais ça me surprendrait parce que c'est du HTML. Y'a-t-il un commit bdd au mauvais endroit par rapport à la génération du formulaire ?

Petit ping, sinon l'issue va rester fermée et le bug va rester.

Mmm, je regarde ça ce soir.

Comme l'issue était fermée et que le bug en question a été de nouveau repéré dans #16 puis corrigé dans 1cb2623 , je considère ce fil comme résolu.