Development #30536
form_tracking_code en mode lazy lors de la saise d'une demande
0%
Description
get_static_substitution_variables fait :
if self.tracking_code:
d['form_tracking_code'] = self.tracking_code
elif not self.status and self.data and 'future_tracking_code' in self.data:
d['form_tracking_code'] = self.data['future_tracking_code']
mais en lazy on ne gère la situation de la seconde partie.
Fichiers
Révisions associées
formdata: revert extended support for form_tracking_code in static mode (#30536)
Historique
Mis à jour par Frédéric Péters il y a environ 5 ans
- Fichier 0001-formdata-handle-form_tracking_code-of-unsaved-data-i.patch 0001-formdata-handle-form_tracking_code-of-unsaved-data-i.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a environ 5 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a environ 5 ans
- Fichier 0001-formdata-handle-form_tracking_code-of-unsaved-data-i.patch 0001-formdata-handle-form_tracking_code-of-unsaved-data-i.patch ajouté
- Statut changé de Solution validée à Solution proposée
Il y a en fait une situation supplémentaire, gérée uniquement dans l'affichage de la zone du code de suivi,
draft_formdata_id = data.get('draft_formdata_id')
if draft_formdata_id:
formdata = self.formdef.data_class().get(draft_formdata_id)
tracking_code = formdata.tracking_code
else:
tracking_code = data.get('future_tracking_code')
Le patch attaché gère ça, y compris désormais dans le get_static_substitution_variables() mais à vrai dire j'éviterais bien cette partie du patch, pour éviter d'introduire un accès db supplémentaire là, pour une variable dont on a visiblement jamais eu besoin.
(elle apparait dans une utilisation chez moi où j'ai un template django contenant un appel à un objet webservice, contenant lui-même en paramètre un {{form_tracking_code}}).
Bref, patch proposé, et si ça va, j'en retire la partie touchant wcs/formdata.py.
Mis à jour par Thomas Noël il y a environ 5 ans
Si j'ai bien suivi, la partie wcs/formdata.py c'est au cas où on voudrait jouer avec form_tracking_code dans une condition ou une expression, dans le formulaire, ie sur un brouillon ?
Mis à jour par Frédéric Péters il y a environ 5 ans
Si j'ai bien suivi, la partie wcs/formdata.py c'est au cas où on voudrait jouer avec form_tracking_code dans une condition ou une expression, dans le formulaire, ie sur un brouillon ?
Je ne sais à vrai dire pas très bien quand on tombe pile sur ce moment. (à suivre le moment où je le produis, ça arriverait sur un template de widget modifié, qui appelle un webservice, qui ferait [form_tracking_code]).
Mis à jour par Thomas Noël il y a environ 5 ans
Ok, donc oui pour ne rien poser dans formdata.py, ça me parait vraiment un cas de mauvais usage qu'on n'a pas envie de faire fonctionner, non ? (Je demande cette précision pour comprendre, parce que tu dis l'utiliser... je suis un peu perdu)
Mis à jour par Frédéric Péters il y a environ 5 ans
Ok, donc oui pour ne rien poser dans formdata.py, ça me parait vraiment un cas de mauvais usage qu'on n'a pas envie de faire fonctionner, non ? (Je demande cette précision pour comprendre, parce que tu dis l'utiliser... je suis un peu perdu)
J'utilise la syntaxe django, et donc sans le patch à formdata.py ça marche.
Mis à jour par Thomas Noël il y a environ 5 ans
- Statut changé de Solution proposée à Solution validée
J'ai donc enfin tout compris et ack, sans la modif au formdata.py parce qu'il faut passer le plus possible en Django, oui.
Mis à jour par Frédéric Péters il y a environ 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 9520fa5d0291f362af33bf98b71537ff848f45e6
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sun Feb 10 12:50:43 2019 +0100
backoffice: remove doubled parenthesis around "deleted" on inspect page (#30505)
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
formdata: handle form_tracking_code of unsaved data in lazy mode (#30536)