Je ne sais pas si quelqu’un d’autre que @haydenjames pourrait être intéressé par ceci, mais j’étais curieux au sujet d’une demande secondaire dans un sujet par ailleurs résolu concernant les boîtes de réception des MP de groupe :
Puisque les champs équivalents pour les « noms » d’utilisateur et de groupe se chevauchent de manière déroutante, je les catégorise ici comme @ identifiant et nom propre. Les identifiants n’autorisent pas les espaces ; les noms propres le permettent.
@ identifiant
nom propre
utilisateurs
champ Username (Agent_007)
champ Name (James Bond)
groupes créés par l’admin
champ Name (poke_pros)
champ Full Name (Pokemon Pros)
groupes automatiques
codé en dur (trust_level_2)
pas vraiment…
Les groupes automatiques, par exemple les modérateurs, les niveaux de confiance, etc., n’ont pas de champs « identifiant » et « nom propre » modifiables.
Mais les groupes automatiques ont des noms de texte du site qui peuvent être modifiés :
Je ne sais pas combien de travail il faudrait pour récupérer les champs de nom propre à afficher ici au lieu de l’identifiant, mais si c’est mineur, ce serait une belle touche de finition.
EDIT : Je réalise que même si cela pourrait être joli d’utiliser le nom propre dans la boîte de réception, il est logique qu’il affiche l’identifiant qui est utilisé pour les @-mentions.
Si vous souhaitez renommer un groupe automatique et lui donner un nouvel identifiant correspondant, le nouveau titre du groupe dans les textes du site doit être valide à cette fin, c’est-à-dire ne pas contenir d’espaces.
Eh bien, c’est intéressant..! La réponse de JammyDodger m’a conduit à d’autres expériences.
Renommer les groupes automatiques via le paramètre de texte du site a créé une certaine confusion lorsque des espaces étaient impliqués, car les espaces empêchent leur utilisation comme handles (identifiants). Si le handle dérivé actuel n’est pas remplacé par le paramètre de texte du site à cause des espaces, il reste tel quel. J’ai découvert cela lorsque j’ai brièvement eu un titre de groupe sans espaces figé comme handle.
La prise de conscience de l’impact des espaces et l’utilisation du travail Sidekiq EnsureDbConsistency ont clarifié les choses.
Je vais modifier ma suggestion dans le message original concernant l’affichage des noms complets dans la boîte de réception, car cela ne serait pas compatible avec l’utilisation des @-mentions, qui nécessitent le handle.
Étapes de test détaillées
En partant de ma situation ci-dessus, j’ai confirmé que le travail Sidekiq avait été exécuté, et je l’ai exécuté à nouveau de toute façon. En effet, il n’a pas pris en compte les changements de nom pour la boîte de réception – à cause des espaces, comme vous l’avez expliqué.
J’ai changé le texte du site pour TL2 de “Trust Level 2” à “Sophomores” et j’ai exécuté le travail Sidekiq :
Le changement de nom s’est alors propagé, à la fois pour le titre du groupe et pour le handle de la boîte de réception – car il n’y avait pas d’espaces :
J’ai ramené le texte du site à “Trust Level 2” et j’ai exécuté le travail Sidekiq. Le handle assigné lors de l’opération précédente est maintenant bloqué là – apparemment parce que les espaces dans ce titre de texte de site ne constituent pas un handle valide :
J’ai rétabli le texte du site à la valeur par défaut “trust_level_2” et je n’ai pas exécuté le travail Sidekiq. Cela a mis à jour le titre mais pas le handle :
champ 
champ 
champ 
codé en dur (trust_level_2)
pas vraiment…
Il m’arrive de réaliser que j’ai sauté trop vite et d’avoir des « remords de l’auteur ». 
Je vais la remettre pour la postérité. 
