Bug #17375
Gestion des champs de traitement : problème sur le type d'une donnée (suite à changement de wf ou manip sur les fbo)
0%
Description
On a de temps en temps ce genre de soucis :
LINE 1: ...les_array = NULL, fbo3 = 'Agent TRAITANT', fbo2 = '0', f8_di...
^
HINT: Perhaps you need a different "datestyle" setting.
parce qu'une attribution de valeur a été mal faite sur un champ de traitement (ici "0" pour un champ de type date).
Pourrait-on essayer de forcer le bon type de valeur avant l'enregistrement ? Genre, avec un "def cast(self, value)" présent sur chaque type de donnée wcs, qui serait appelé après le calcul des valeur dans l'action Set Backoffice Fields ?
Fichiers
Révisions associées
Historique
Mis à jour par Thomas Noël il y a presque 7 ans
- Sujet changé de Gestion des champs de traitement : vérifier le type de la donnée Python à Gestion des champs de traitement : problème sur le type d'une donnée (suite à changement de wf ou manip sur les fbo)
Après analyse, ça pourrait plutôt être lié à une succession d'ajouts/suppressions de champs de traitement, ou de changement de workflow associé à un formulaire.
Sur ajout/suppression de champs de traitement :- j'ajoute un champ, il porte l'id 3
- je le supprime
- j'ajoute un nouveau champ, il porte l'id 3
=> il manque la notion de max_field_id qui évite cela.
Sur changement de workflow associé à un formulaire : que faire ?... (à part refuser le changement de workflow, dans un premier temps)
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Assigné à mis à Frédéric Péters
- Priorité changé de Normal à Haut
Faut que je regarde ça.
Mis à jour par Frédéric Péters il y a environ 5 ans
- Fichier 0001-misc-give-unique-identifiers-to-backoffice-fields-17.patch 0001-misc-give-unique-identifiers-to-backoffice-fields-17.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Frédéric Péters il y a environ 5 ans
(à noter que toute la partie dans sql.py aurait pu être zappée en tapant à la base des underscore dans l'uuid généré, ou en virant les tirets, et parce que le seul truc que je voulais c'était des tirets par d'underscore dans l'url, avoir la transformation inverse dans un _q_lookup)
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
- Statut changé de Solution proposée à Solution validée
C'est ok pour moi comme cela, mais des changements possibles.
Par exemple un simple str(uuid.uuid4().hex[:12]), ça donne 48bits d'entropie c'est largement suffisant, pas de tirets pas d'underscore.
Sinon pour le fun j'ai vu ça sur hackernews récemment :- https://arxiv.org/html/0901.4016
- https://github.com/dsw/proquint/blob/master/python/proquint/proquint.py
Sur des IPv4 ça donne ça :
127.0.0.1 lusab-babad
63.84.220.193 gutih-tugad
63.118.7.35 gutuk-bisog
140.98.193.141 mudof-sakat
64.255.6.200 haguz-biram
128.30.52.45 mabiv-gibot
147.67.119.2 natag-lisaf
212.58.253.68 tibup-zujah
216.35.68.215 tobog-higil
216.68.232.21 todah-vobij
198.81.129.136 sinid-makam
12.110.110.204 budov-kuras
C'est plus agréable à lire que des uuid, pour 48bits ça ferait 3 groupes de 5 lettres, et tant qu'à garder des tirets je garderai l'identifiant séquentiel pour avoir une idée de l'ordre de création.
Mis à jour par Frédéric Péters il y a environ 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
J'ai pas mal hésité pour finalement pousser avec les uuid full, en me rappelant qu'on les utilisait déjà complets comme identifiants pour les actions globales.
commit 9e9b5e1463ecd6f72ab1c654b40f234d6d28f48c
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Mon Apr 8 19:19:35 2019 +0200
misc: give unique identifiers to backoffice fields (#17375)
Mis à jour par Frédéric Péters il y a environ 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
misc: give unique identifiers to backoffice fields (#17375)