Merci, je vois que le badge est toujours présent après avoir relancé le job BadgeGrant.
Cependant, il semble y avoir un autre problème lié à ce job BadgeGrant. J’avais l’habitude d’attribuer manuellement en masse certains badges (par exemple, le premier « j’aime » donné ou reçu) à des utilisateurs qui ne pouvaient pas les obtenir automatiquement, car ce type de « j’aime » avait été donné ou reçu dans une catégorie restreinte.
Mais lorsque le job BadgeGrant est déclenché, tous les utilisateurs ayant reçu un tel badge par attribution manuelle en masse le perdent.
Mes tests :
-
Attribution manuelle d’un badge par défaut qu’un utilisateur ne peut pas obtenir automatiquement en raison d’une catégorie restreinte, bien qu’il remplisse les conditions. Le badge est supprimé après l’exécution de
BadgeGrant. -
Création d’un badge personnalisé avec du SQL, par exemple : attribuer ce badge lorsqu’un utilisateur publie un nouveau sujet dans une catégorie spécifique. Attribution manuelle de ce badge à un utilisateur qui ne peut pas l’obtenir automatiquement en raison d’une catégorie restreinte, bien qu’il remplisse les conditions. Le badge est supprimé après l’exécution de
BadgeGrant. -
Création d’un badge personnalisé sans SQL. Attribution manuelle de ce badge à un utilisateur qui ne peut pas l’obtenir automatiquement en raison d’une catégorie restreinte, bien qu’il remplisse les conditions. Le badge reste après l’exécution de
BadgeGrant.
Je suppose que c’est le comportement attendu, car tous ces utilisateurs ayant reçu le badge manuellement ne satisfont pas la requête SQL et sont donc exclus du groupe de candidats. Mais dans ce cas, la plupart des discussions dans le sujet ci-dessous deviennent beaucoup moins pertinentes pour les forums disposant de catégories restreintes très actives. De plus, à ma connaissance, une solution à court terme devient impossible.
Avez-vous des suggestions à ce sujet ? Je pourrais simplement arrêter de le faire, mais je suis curieux de savoir s’il existe un moyen de gérer cela.