Development #42429
Affichage d'un message d'erreur quand deux champs ont le même varname
0%
Description
C'était bien avant mais maintenant c'est autorisé d'avoir 2 champs avec le même varname.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Pierre Cros il y a presque 4 ans
- Fichier varname-bijoe.png varname-bijoe.png ajouté
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
Ce n'est pas vraiment autorisé, en vrai, il y a juste une sorte de contournement pour que de temps en temps ça fonctionne comme les gens espèremt que ça va fonctionner. Et ça ne marchera toujours pas dans wcs-olap sauf si les APIs change pour n'afficher qu'un champ; je reçois une valeur pour le champ "varname=x" qui existe deux fois en type bool et item, je le met dans quelle colonne de ma table des statistiques ?
Mis à jour par Frédéric Péters il y a presque 4 ans
Ce n'est pas vraiment autorisé,
C'est totalement autorisé et le comportement est désormais défini : en cas de plusieurs champs portant la même variable, c'est le premier rempli, par ordre d'apparition dans le formulaire, qui vaut.
Alors oui il reste que ça n'a sans doute que peu de sens d'utiliser le même identifiant pour des champs sans rapport / de types différents, et très bien que ces cas soient toujours exposés en erreur, mais ce n'est pas le cas exposé ici.
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
- Projet changé de BiJoe à OLAP / Business Intelligence pour Publik
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
Frédéric Péters a écrit :
Ce n'est pas vraiment autorisé,
C'est totalement autorisé et le comportement est désormais défini : en cas de plusieurs champs portant la même variable, c'est le premier rempli, par ordre d'apparition dans le formulaire, qui vaut.
Oui mais l'API ne fonctionne pas comme cela, wcs.formdata.get_json_dict() ne garde que la dernière valeur.
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
- Lié à Bug #42468: API : la règle « premier varname arrivé, premier servi » n'est pas respectée ajouté
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
- Fichier 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch ajouté
- Tracker changé de Bug à Development
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Voilà, les tests devraient passer quand w.c.s. renverra les bonnes valeurs; ce serait bien si w.c.s. respectait la même règle au niveau du type (i.e. qu'un champ ne prenne la place d'un autre que s'il vient après, que le premier n'a pas de valeur et qu'ils sont du même type).
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Rebasé sur master, le patch fonctionne maintenant que #42468 est passé.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Fichier 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch ajouté
Rebasé.
Mis à jour par Nicolas Roche il y a plus de 3 ans
J'ai l'impression que le second champ remplace le premier,
contrairement à ce qui est mentionné :
if field.varname in good_fields and good_fields[field.varname].type != field.type: # duplicate found, but type is not coherent add_warning('Le champ ... sera ignoré') del self.good_fields[field.varname] self.good_fields[field.varname] = field
(à la place de "del" j'aurais mis "continue")
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Solution proposée à En cours
Ce n'est pas l'objet du ticket intialement mais tu as raison que le dernier champ trouvé avec un varname va cacher le premier (et ça se voit dans le schéma JSON pour bijoe où c'est le label du mauvais doublon qui est repris). Je corrige ça.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Et je me suis auto-induit en erreur encore une fois, il faut ignorer tous les exemplaires du doublon dans ce cas, même le premier.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Fichier 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch 0001-misc-accept-duplicate-fields-with-the-same-type-4242.patch ajouté
- Statut changé de En cours à Solution proposée
Voilà, on ignore tout en cas d'incohérence sur les types.
Mis à jour par Nicolas Roche il y a plus de 3 ans
Il y a un "n apostrophe" en trop dans le message : "Le champ « %s » n\' est un doublon d\'un champ de type différent,"
Du coup je me demandais si ce n'était pas trop coûteux de rajouter un test pour couvrir aussi ce cas ?
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Mis à jour par Nicolas Roche il y a plus de 3 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit a16fb4ee98b452d84b8a4e650c693727e984d38d Author: Benjamin Dauvergne <bdauvergne@entrouvert.com> Date: Mon Aug 31 10:46:13 2020 +0200 misc: accept duplicate fields with the same type (#42429)
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
misc: accept duplicate fields with the same type (#42429)