misc: handle decimal attributes when importing / exporting fields (#86531) #1093
fpeters
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/86531-decimal-field-attributes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Pas sûr de où mettre les tests, je veux bien un indice.
Dans tests/test_formdef_import.py.
44ad4e9c49to0997fe2dc7@ -88,0 +88,4 @@def init_with_json(self, elem, include_id=False):super().init_with_json(elem, include_id)self.min_value = self.convert_value_from_anything(self.min_value)self.max_value = self.convert_value_from_anything(self.max_value)convert_value_from_anything c'est pour la valeur du champ lui-même, ici ça pourrait juste être Decimal(self.min.value), il me semble.
0997fe2dc7to61116aad9661116aad96toea8a49dc19@ -88,0 +89,4 @@super().init_with_json(elem, include_id)self.min_value = decimal.Decimal(self.min_value)if self.max_value is not None:self.max_value = decimal.Decimal(self.max_value)min_value pourrait être None également (mais sa valeur par défaut est à 0); il me semble que le même if devrait existe pour ce cas. (après ça ok)
ea8a49dc19toa2b5f40911Il y a une asymétrie entre le code d'export, qui ne sérialise pas les attributs à None et le code d'import, qui ne sette pas les attributs qui ne sont pas sérialisés et donc les laisse à leur valeur par défaut s'ils ne sont pas dans le JSon ou le XML. Dans le cas de min_value, ce sont deux choses différentes : la valeur par défaut est 0, None a une signification particulière.
J'ai géré spécifiquement pour NumericField, mais ça peut créer des incohérences à l'import pour tous les champs qui peuvent prendre une valeur None, mais qui ont une valeur par défaut différente de None. (mais je n'ai pas trouvé d'autres cas que min_value, donc on s'en fout probablement).
ok top.