Tout d’abord, un grand merci pour votre aide ! C’est néanmoins un bug intéressant.
Le problème, c’est que je devrai peut-être modifier le nom d’utilisateur directement dans la base de données, car la route n’est pas disponible
Pourriez-vous me fournir une requête ?
Je pense que cela n’est pas possible, car cela interdirait tous les noms commençant par Σ en Grèce (et je casserais essentiellement les connexions via Facebook pour ces utilisateurs). Puis-je interdire un motif regex spécifique ? Ainsi, je pourrais m’assurer que le Σ se trouve au moins à la fin.
Un autre membre s’est inscrit avec exactement le même problème. Mon point est que, pour nous, ce n’est pas un cas limite. Il existe littéralement des milliers de prénoms en grec qui utilisent le Σ (ou ς) à la fin du nom.
Et malheureusement, étant donné notre groupe d’âge principal (> 40 ans), de nombreux membres ont leur nom écrit en majuscules sur Facebook (). Ainsi, lorsqu’ils se connectent via Facebook, leur nom est copié dans le champ du nom d’utilisateur…
Je ne m’inquiéterais pas pour Postgres. Nous devrions toujours comparer avec username_lower en SQL et ne pas nous fier à LOWER(), car username_lower n’est pas simplement la version en minuscules du nom d’utilisateur. Nous appliquons également une normalisation Unicode.
Je suis d’accord. Ajouter une solution de contournement à User.normalize_username devrait suffire pour l’instant. Il y a déjà des discussions dans le rapport de bogue Ruby et il semble qu’il n’existe pas de solution simple. Cependant, nous avons de la chance, car tout ce que nous devons faire est de vérifier le dernier caractère d’un nom d’utilisateur. C’est beaucoup plus facile que de le faire dans une phrase complète.
D’accord. Pourtant, cela devrait être beaucoup plus simple qu’une implémentation complète, car nous n’avons à nous soucier que de certains symboles comme le tiret bas, le tiret et peut-être les chiffres ? Cela devrait être réalisable.
Je sais que je m’éloigne de la discussion spécifique sur ce bug, mais quand je pense à ce problème, je ne peux pas ignorer le fait qu’il pourrait être évité.
J’ai découvert qu’il existe certaines routes API dans Discourse qui référencent un utilisateur par son userId, tandis que d’autres le font par son nom d’utilisateur. Ne devrait-on pas harmoniser cela (en faveur du userId) ?
Peut-être en implémentant quelque chose de similaire à ce qui se fait actuellement avec les catégories et les tags ? Avoir à la fois le nom d’utilisateur et le userId dans l’URL, par exemple : https://meta.discourse.org/u/chrispanag/4387
En 2016, @eviltrout était contre cette idée ; je ne sais pas où il en est aujourd’hui.
Quoi qu’il en soit, j’ai proposé une solution de contournement dans Discourse via cette PR :
Elle résoudra le problème de la nouvelle inscription Facebook en convertissant en minuscules tout nom d’utilisateur commençant par une sigma. Cela signifie que vous n’aurez qu’à corriger le nom d’utilisateur de Spiros et ceux des autres utilisateurs avec une sigma finale en les passant en minuscules, et le problème devrait être réglé à long terme.
Un grand merci à toi, @sam ! Ton aide a été immense.
Y a-t-il un moyen de le faire depuis la console Rails ? (Comme le compte utilisateur est cassé, il n’est pas possible de le faire via le panneau d’administration…)
Je n’aime toujours pas utiliser des identifiants partout, mais je comprends qu’il existe de nombreux cas où cela a du sens.
Dans ces situations, je préférerais quelque chose comme id-nomutilisateur, où nomutilisateur est ce que nous pouvons mettre dans une URL. Cela pourrait même être ignoré par le routeur. Mais au moins, lorsque vous partagez le lien, vous aurez une idée de ce à quoi vous faites référence.
Personnellement, je suis un grand partisan du routage de style Stack Overflow pour les utilisateurs :
https://stackoverflow.com/users/17174/sam-saffron
Dans l’univers de Discourse, cela donnerait :
https://meta.discourse.org/u/17174/sam-saffron
Cela vous permet d’avoir le meilleur des deux mondes. Mais oui, je comprends tout à fait l’objection : « Je n’aime pas voir 17174 dans l’URL ; les noms d’utilisateur sont stables ».
Cela dit, nous avons survécu jusqu’à présent avec nos routes existantes ; il arrive simplement que, tous les quelques années, certains cas limites apparaissent.
Je pense qu’il serait utile d’utiliser l’identifiant (id) plutôt que le nom d’utilisateur (ou les deux, mais en se fiant uniquement à l’identifiant, comme expliqué ci-dessus) au moins sur la page de profil de l’utilisateur, afin que l’administrateur puisse modifier le nom d’utilisateur via l’interface Discourse sans avoir à exécuter une commande dans la console Rails si un problème survient avec le nom d’utilisateur.
Nous devons uniquement nous soucier des caractères où l’implémentation JavaScript et Ruby de la conversion en minuscules diffère. Pas l’inverse.
Il n’existe aucune règle définissant comment la lettre minuscule allemande « ß » est convertie en majuscule. Cela pourrait être « SS », « SZ » ou même la nouvelle lettre majuscule « ẞ » (oui, il y a une nuance subtile). Inverser ce processus n’est possible que pour « ẞ », et cela fonctionne correctement dans Ruby et JavaScript.
Je pense que nous devrions faire ce qui suit :
Fusionner la solution de contournement de @sam pour résoudre le problème immédiat
Supprimer LOWER(username) des requêtes SQL, car c’est une mauvaise pratique (par exemple, absence de normalisation Unicode)
Espérer que Ruby corrige le problème sous-jacent
À long terme : Réfléchir à l’ajout des identifiants d’utilisateur dans les routes. Je suppose que la partie la plus difficile sera de déterminer comment gérer les guillemets et les mentions.
Pas sûr que ce soit lié, mais nous avons plusieurs utilisateurs avec des noms Unicode, dispersés dans le fichier /log
ActionView::Template::Error (Aucune route ne correspond à {:action=>"show", :controller=>"users", :username=>"ζηεδψ"}, contraintes non correspondantes possibles : [:username])
