Produits Entr'ouvert » Passerelle

Je suis pas sûr de la détection automatique, c'est beaucoup de demie mesure. Le bon côté c'est que ça résout #38279 sans toucher à rien, et que potentiellement ça résout ce type de problème dans d'autres connecteurs. Le mauvais c'est que renseigner le type des paramètres dans @endpoint fait bénéficier de validation, et ce genre de bidouille dissuade à tord de le faire.

Le mauvais c'est que renseigner le type des paramètres dans @endpoint fait bénéficier de validation.

Mais il devrait là aussi y avoir validation; je dirais que @endpoint() doit alimenter son self.parameters de la manière la plus automatique possible, et que cette info soit ensuite exploitée.

Vite fait à peine testé :

--- a/passerelle/views.py
+++ b/passerelle/views.py
@@ -320,10 +320,12 @@ class GenericEndpointView(GenericConnectorMixin, SingleObjectMixin, View):
                 d[key] = other_params[key]
         if self.endpoint.endpoint_info.parameters:
             # check and convert parameter values
-            for parameter, parameter_info in self.endpoint.endpoint_info.parameters.items():
+            import pdb; pdb.set_trace()
+            for parameter_info in self.endpoint.endpoint_info.get_params():
+                parameter = parameter_info['name']
                 if parameter not in d:
                     continue
-                if parameter_info.get('type') == 'bool':
+                if parameter_info.get('type') in ('bool', 'boolean'):
                     if d[parameter].lower() in ('true', 'on'):
                         d[parameter] = True
                     elif d[parameter].lower() in ('false', 'off'):

(la vérif sur bool & boolean étant malheureuse, mais vu que ça a gagné un second nom sur la route…)

Bonne idée. Juste que lier ce type de détection à la validation comporte un risque (genre un coord_x=1 qu'on détecte en int mais qui peut prendre des floats, voire des strings si on joue aux échecs ('1A'), bref des risques de régressions difficilement prévisibles qui seront découvertes en prod, à moins de faire le tour de tous les connecteurs).

À part ça tant qu'à faire, j'étends la déduction à example_value.

(avec un #todo survivant en moins)

Bien que le code soit couvert, il n'a aucun impact sur les tests.
Aussi, je me serais attendu à y trouver un nouveau test, puisque ce patch résout #38279.