Les lettres majuscules dans le nom d'utilisateur cassent la vérification des mentions accessibles dans le compositeur

En enquêtant sur Private Topics Plugin - #109 by thoka, j’ai découvert qu’une mention d’un utilisateur dans une catégorie restreinte n’est pas signalée lorsque le nom d’utilisateur contient des lettres majuscules.

Si je mentionne @SomeUser, l’éditeur effectue une requête vers
/composer/mentions.json?names[]=SomeUser&topic_id=10728
Dans le résultat, le nom d’utilisateur est renvoyé en minuscules, sans que user_reasons soit défini.

Une requête pour le nom d’utilisateur en minuscules renvoie "user_reasons": {"someuser":"category"}.

Si j’utilise des lettres minuscules pour les noms d’utilisateur dans le compositeur, des avertissements sont affichés pour les personnes ne disposant pas de droits suffisants.

Si l’on utilise la saisie semi-automatique fournie par l’éditeur, les noms d’utilisateur en minuscules saisis sont remplacés par des noms en majuscules et ne sont donc pas signalés.

3 « J'aime »

Bonne trouvaille @thoka !

Le problème se trouve ici

users retourne {"username_lower" => objet User }

Cependant, si name n’est pas en minuscules, users[name] n’existe pas.

Correction :

if user = users[name.downcase]
...
elsif group = groups[name.downcase]
...

Ou mieux : mettez tous les noms en minuscules au début de la méthode, car il y a beaucoup de problèmes. groups utilise correctement .where("lower(name) IN (?)", @names.map(&:downcase)), mais des fonctions comme visible_group_ids_for_allowed_check, topic_allowed_group_ids, mentionable_group_ids et members_visible_group_ids utilisent toutes where(name: @names), ce qui introduit également des problèmes de sensibilité à la casse.

3 « J'aime »

La correction appropriée se trouve ici :

mais c’est un changement trop important pour que je me sente à l’aise de le fusionner à ce stade :grimacing:

À la place, je vais corriger chaque « endpoint » un par un afin de simplifier la revue et de réduire les risques.

Voici la première étape :

4 « J'aime »