Anomalie #1534
fermé
Permettre des identifiants plus longs
100%
Description
Merci de permettre des identifiants plus longs.
Cas d'utilisation :
ma convention de nommage des identifiants est "prenom.nom" (ce qui ne semble pas relever d'une créativité incongrue ?).
Aujourd'hui j'ai un nouvel adhérent nommé "Pierre-Yves Bakalémian" : Impossible de créer l'adhérent avec l'identifiant "pierre-yves.bakalemian" .
Dans les logs : ERROR - Something went wrong :'( | SQLSTATE22001: String data, right truncated: 1406 Data too long for column 'login_adh' at row 1
Donc, j'ai renommé l'identifiant "pybakal" et l'adhérent est bien créé.
Mais peut-être qu'un logiciel plus récent que les années 60 pourrait accepter que les gens ont des noms longs et que c'est normal ? (humour caustique, j'avoue. C'est dû au fait que je viens de passer 1h à deboguer un problème qui ne devrait même pas exister…)
Mis à jour par Johan Cwiklinski il y a presque 4 ans
Tu aurais certainement pu conserver ton humour pour toi.
Par ailleurs, je te rappelle que Galette est un logiciel libre ; et que le code est modifiable par et pour tous.
Mis à jour par Loïs Taulelle il y a presque 4 ans
Johan Cwiklinski a écrit (#note-1):
Tu aurais certainement pu conserver ton humour pour toi.
Par ailleurs, je te rappelle que Galette est un logiciel libre ; et que le code est modifiable par et pour tous.
Oui bon ben ça va... J'étais jeune, j'étais con, je connaissais pas encore les patronymes malgaches...
(on peut garder les mot de passe à 8 caractères ? sinon, ça foire mes rainbowtables ;o) <:humour grinçant:>
Mis à jour par Thierry Mouchaud il y a presque 4 ans
Tu aurais certainement pu conserver ton humour pour toi.
C'est pour ça que j'ai précisé que c'est de l'humour.
Par ailleurs, je te rappelle que Galette est un logiciel libre ; et que le code est modifiable par et pour tous.
C'est vrai.
Je ne suis pas sûr que tu apprécierais de recevoir une PR qui modifie une caractéristique de la DB venant de quelqu'un qui ne connaît rien à la base de code de Galette et n'a aucune idée des endroits où ça peut péter.
D'où l'intérêt de cette anomalie : ouvrir une discussion sur la faisabilité de la chose avec les personnes compétentes pour en juger, à ma connaissance : toi Johan.
J'étais jeune, j'étais con, je connaissais pas encore les patronymes malgaches...
Ca fait plus de 20 ans que je ne comprends pas pourquoi les cours de développement ne comprennent pas des sections dédiées à l'histoire de l'IT.
Genre "eh les jeunes, on a fait les cons, on a compris dans les années 1960/70/80/1990 ce qu'il ne faut pas faire, faites pas comme nous". Entre les limites de longueur de champs ridicules (je parle même pas des noms indiens en Unicode, hein…), les buffer overflows à ne plus savoir lequel choisir pour un exploit, et les injections SQL parce que sanitizer les entrées de l'utilisateur ça prend du temps… D'où ma réaction un poil épidermique en face de cette limitation d'un autre temps.
Notez que la remontée d'erreur vers l'utilisateur sur ce problème n'est pas bien meilleure : à part le message d'erreur générique, galette entoure en rouge les champs de mot de passe, pas le champ d'identifiant…
Oui Johan, j'ai compris, je devrais coder moi-même. :(
Mis à jour par Johan Cwiklinski il y a presque 4 ans
- Sujet changé de Permettre des identifiants plus longs car les gens ont le droit d'avoir des noms longs… à Permettre des identifiants plus longs
- Catégorie mis à Database
- Assigné à mis à Johan Cwiklinski
Thierry Mouchaud a écrit (#note-3):
Oui Johan, j'ai compris, je devrais coder moi-même. :(
C'est soit ça, soit avoir un discours constructif. Tu as repéré une limitation dans la base qui n'aurait pas lieu d'être ; soit. Tu déclares une anomalie, très bien, merci (vraiment, merci, les bogues corrigés font avancer le projet, et profitent à tous...).
Le coup des modifications de la base ne tient pas vraiment : il ne s'agit pas de modifier le type du champ ou de réduire sa capacité (ce qui pourrait effectivement affecter le comportement du logiciel), augmenter la taille d'un champ, ça n'impactera pas (ou très peu au pire des cas, mais j'en doute) le fonctionnement.
Par contre, faire une vraie proposition, du type « monter la taille à x caractères », avec pourquoi pas une requête qui va bien. Parce que là, je n'ai pas vu de proposition de correction.
Par ailleurs, sans avoir à entrer la moindre ligne de code que ce soit, tu pourrais aussi "inspecter" la base et voir s'il y a d'autres choses qui semblent bizarres voire aberrantes ; et proposer de corriger le tout. Ça éviterai qu'un problème similaire ne se pose alors qu'il pourrait être identifié au préalable.
Quand aux remontées d'erreur de Galette, les solutions se trouvent dans les logs lorsqu'il n'y a pas de bug (ça peut arriver) et aussi lorsque le moteur de base de données renvoie une erreur (c'est le cas de postgresql), mais en mysql, il s'agit de warnings (dans ce cas) ; et donc rien ne remonte. Il est possible de faire autrement, à base de ponte de code... ... ... Moi, j'ai pas le temps de traiter ça (et du temps sur Galette, j'en passe déjà pas mal).
Mis à jour par Thierry Mouchaud il y a presque 4 ans
il ne s'agit pas de modifier le type du champ ou de réduire sa capacité (ce qui pourrait effectivement affecter le comportement du logiciel), augmenter la taille d'un champ, ça n'impactera pas (ou très peu au pire des cas, mais j'en doute) le fonctionnement.
Eh bien voilà justement pourquoi j'ai fait cette demande :) Merci Johan de cette information cruciale !
Parce que là, je n'ai pas vu de proposition de correction.
C'est parce que je n'avais pas encore d'avis compétent sur la faisabilité d'une correction !
tu pourrais aussi "inspecter" la base et voir s'il y a d'autres choses qui semblent bizarres voire aberrantes
OK, je m'y colle dès que possible.
Quand aux remontées d'erreur de Galette
Ben là ce qui m'a gêné c'est qu'il y a bien une erreur affichée : les champs de mot de passe en rouge ! Mais, en fait, c'est pas ça l'erreur. J'ai perdu 50min à me battre avec des mots de passe pour comprendre ce qui se passait, pour finir par aller dans les logs et repérer la ligne pertinente. Bon, c'est ma faute de ne pas avoir bondi dans les logs dès le 3ème essai…
Est-ce possible d'entourer en rouge le bon champ de l'UI sur cette erreur ?
Mis à jour par Johan Cwiklinski il y a plus de 3 ans
- Statut changé de Nouveau à Fermé
- Version cible mis à 0.9.5
- % réalisé changé de 0 à 100