Suivi — Étiquettes Décrémenter le taggings_count en cas de suppression d'étiquette

#1964 Posté par  (site web personnel) . État de l’entrée : corrigée. Assigné à Adrien Dorsaz. Licence CC By‑SA.
Étiquettes : aucune
0
28
déc.
2020

Les étiquettes elle-mêmes sont gérées par la table SQL tags et les étiquetages (une étiquette pour un utilisateur sur un contenu) via taggings. tag.taggings_count décompte le nombre d'étiquetages (quel que soit le contenu et l'utilisateur).

Normalement Ruby On Rails devrait gérer l'incrémentation et la décrémentation du compteur.

L'incrémentation marche bien. La décrémentation (dans le cas où l'étiquetage est supprimé par son utilisateur), voire le cas où le seul étiquetage existant est supprimé par son utilisateur ne fonctionne pas correctement.

./models/tag.rb:

#  taggings_count :integer          default(0), not null
  has_many :taggings, dependent: :destroy, inverse_of: :tag
  has_many :nodes, -> { distinct }, through: :taggings

./models/tagging.rb:


  validates_uniqueness_of :tag_id, :scope => [:node_id, :user_id]
  validates :tag_id, presence: true

./models/node.rb:

  has_many :taggings, -> { includes(:tag) }, dependent: :destroy
  has_many :tags, -> { distinct }, through: :taggings

La détection est faite via le script ./check-sql-database.sh

$ ./check-sql-database.sh
90  56  55  wrong taggings count
(...)

La correction facile mais si on pouvait s'en passer…

UPDATE tags SET taggings_count=55 WHERE id=90 AND taggings_count=56;
  • # Solution trouvée pour la suppression du tag sur un contenu

    Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

    Hello !

    J'ai trouvé la solution et j'ai proposé la modification ici: https://github.com/linuxfrorg/linuxfr.org/pull/289

    Il est à noter que le compteur garde dans son compte les contenus "supprimés":

    En effet, les contenus ne sont pas vraiment supprimés, mais uniquement cachés et du coup les méthodes de callback de counter_cache ne sont pas appelées.

    D'un côté, ça serait logique d'enlever les contenus supprimés des compteurs, car ils ne sont plus accessibles.

    Mais d'un autre côté, ça voudrait dire que l'on doit supprimer les tags au moment où on supprime le contenu et, du coup, on ne pourrait plus "restaurer" en l'état le contenu en changeant le flag node.public à true.

    • [^] # Re: Solution trouvée pour la suppression du tag sur un contenu

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

      Pour le cas des contenus cachés, on pourrait utiliser la gem counter_culter qui permet de mettre à jour le cache aussi sur des mises à jour de valeur.

    • [^] # Re: Solution trouvée pour la suppression du tag sur un contenu

      Posté par  (site web personnel) . Évalué à 4 (+0/-0).

      Le statut actuel :

      Si l'étiquette est jugée inutile, elle est masquée. Elle existe toujours mais n'est plus visible ni suggérée, mais elle reste accessible.

      L'utilisateur peut supprimer son propre étiquetage. Mais l'étiquette reste avec son état affiché oui/non et son compteur (qui n'est pas décrémenté actuellement). Il est possible que l'étiquette n'ait plus aucun étiquetage.

      Un contenu peut être masqué, ça ne change pas l'état ou le compteur de ses étiquettes mais l'étiquette peut ne plus rien afficher si tous les contenus sont masqués. Ça peut être une étiquette pertinente sur un contenu masqué pour doublon. Ça peut être une étiquette de spammeur si on a masqué tous ses contenus de spam (a priori on va masquer aussi ses étiquettes, maintenant on a accès à l'info facilement depuis ma modifié de fin d'année).

      Il y a aussi les cas d'anonymisation d'un compte à gérer en base : réaffecter les étiquetages d'un compte à Anonyme, en gérant les collisions éventuelles avec ceux existants et en mettant à jour les compteurs. Ou la purge d'un compte : retirer des étiquetages et mettre à jour les compteurs.

      Finalement on pourrait aussi vouloir virer les contenus masqués en base au bout d'un certain temps, vu que personne ne les voit. Donc virer les étiquetages dessus, décrémenter les compteurs, virer les étiquettes à compteur nul.

      Dernier point : garder une étiquette inutile masquée plutôt que la détruire est un moyen de la garder masquée. Sinon elle pourrait être recréée plus tard et serait visible par défaut. C'est devenu moins utile avec ma modif de fin d'année qui notifie la modération des nouvelles étiquettes (c'est limite mieux de supprimer l'étiquette pour être notifié d'un nouveau pénible plus tard).

    • [^] # Re: Solution trouvée pour la suppression du tag sur un contenu

      Posté par  (site web personnel) . Évalué à 3 (+0/-0).

      J'ai clos le ticket et je te l'ai attribué manuellement en base, vu qu'actuellement on ne peut choisir que parmi les gens ayant les droits d'admin.

      Ce qui amène deux choix pour la suite :
      1) veux-tu être admin ?
      et/ou
      2) modifier le système pour choisir parmi les admins ou ceux ayant déjà eu un ticket attribué et un compte encore ouvert (ça résoudrait pas la première fois, juste les suivantes)

      • [^] # Re: Solution trouvée pour la suppression du tag sur un contenu

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        Super, merci pour la clôture et pour l'assignation :)

        1) veux-tu être admin ?

        Merci, mais je ne voudrais pas être admin, parce que ça active beaucoup trop de droits sur le site.

        2) modifier le système pour choisir parmi les admins ou ceux ayant déjà eu un ticket attribué et un compte encore ouvert (ça résoudrait pas la première fois, juste les suivantes)

        Ça c'est une idée intéressante, je vais regarder pour essayer de proposer une modification de ce genre.

        Mais, si je ne me trompe pas, on pourrait aussi créer un rôle "mainteneur" qui ajoute juste la gestion du système de suivi à un utilisateur. Ça serait plus propre, mais je me demande si ça compliquerait trop la vie aux admins du site ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.