Development #68379
{{form_user}} vide lors d'une requête live en backoffice
0%
Description
Ci-joint un workflow & formulaire minimal pour reproduire le problème. Créer une demande avec le champs "form_user" vide, puis aller en BO, éditer la demande : le champs form_user est initialement bien renseigné, mail il est vidé suite à une requête live.
Fichiers
Révisions associées
Historique
Mis à jour par Corentin Séchet il y a plus d'un an
- Fichier form-68328.wcs form-68328.wcs ajouté
- Fichier workflow-68328.wcs workflow-68328.wcs ajouté
Mis à jour par Corentin Séchet il y a plus d'un an
wcs/forms/common.py:856
value = field.get_prefill_value()[0]
Retourne None pour le champ avec {{form_user}} comme gabarit de préremplissage. Je n'ai pas trouvé la cause.
Mis à jour par Frédéric Péters il y a plus d'un an
- Fichier 0001-backoffice-allow-form_user-usage-in-live-prefills-du.patch 0001-backoffice-allow-form_user-usage-in-live-prefills-du.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Assigné à changé de Corentin Séchet à Frédéric Péters
- Patch proposed changé de Non à Oui
Je n'ai pas trouvé la cause.
Pas sûr de l'assignation que tu t'es laissée, peut-être que tu voulais continuer à creuser, mais comme c'est délicat j'ai regardé.
Basiquement ce qui se passe c'est que le rendu initial c'est .../management/slug/id/wfedit-x et ça positionne des attributs edit_mode et edited_data, ce qui permet à get_transient_formdata d'alimenter le formdata temporairement créé pour l'édition avec le bon usager, ce qui assure le préremplissage. Par contre l'appel à /live qui réévalue les champs se fait sur .../management/slug/live, une URL qui ne contient ni l'id ni indication d'édition et donc get_transient_formdata crée un formdata temporaire ordinaire, et comme on est en backoffice, sans usager associé.
La correction dans la branche c'est au niveau du dictionnaire "magictoken" (à la base utilisé pour stocker temporairement les données des champs, exploité aussi pour ajouter des informations supplémentaires) l'ajout de l'id de la demande éditée, ce qui permettra au get_transient_formdata de retrouve la demande d'origine et d'alimenter le formdata éphémère.
Mis à jour par Corentin Séchet il y a plus d'un an
Frédéric Péters a écrit :
Pas sûr de l'assignation que tu t'es laissée, peut-être que tu voulais continuer à creuser, mais comme c'est délicat j'ai regardé.
J'avais oublié de me le désassigner, j'avais laissé ça de côté en effet.
Basiquement ce qui se passe c'est que le rendu initial c'est .../management/slug/id/wfedit-x et ça positionne des attributs edit_mode et edited_data, ce qui permet à get_transient_formdata d'alimenter le formdata temporairement créé pour l'édition avec le bon usager, ce qui assure le préremplissage. Par contre l'appel à /live qui réévalue les champs se fait sur .../management/slug/live, une URL qui ne contient ni l'id ni indication d'édition et donc get_transient_formdata crée un formdata temporaire ordinaire, et comme on est en backoffice, sans usager associé.
La correction dans la branche c'est au niveau du dictionnaire "magictoken" (à la base utilisé pour stocker temporairement les données des champs, exploité aussi pour ajouter des informations supplémentaires) l'ajout de l'id de la demande éditée, ce qui permettra au get_transient_formdata de retrouve la demande d'origine et d'alimenter le formdata éphémère.
Compris, merci pour les explications.
Mis à jour par Corentin Séchet il y a plus d'un an
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a plus d'un an
- Statut changé de Solution validée à Résolu (à déployer)
commit ca061dfac48b867ac98a0975727a485bbf8737e9
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sat Aug 27 17:58:02 2022 +0200
backoffice: allow {{form_user}} usage in live prefills during edition (#68379)
Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
backoffice: allow {{form_user}} usage in live prefills during edition (#68379)