Development #24635
Générer un identifiant pour un formdata dès la saisie
0%
Description
Peut-être que conserver magic_token suffirait ? L'exposer dans les variables de substitution ?
Je ne propose pas de manière d'implémenter, le seul résultat fonctionnel que j'espère c'est d'avoir un form_uuid accessible ensuite pour différents usages (principalement obtenir une référence globalement unique pour appeler des WS, ou stocker des données en relation avec le formulaire sans trop réfléchir).
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
- Lié à Development #17685: "préblocage" d'une réservation ajouté
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
- Lié à Development #24567: Connecteur IWS ajouté
Mis à jour par Frédéric Péters il y a presque 6 ans
- Sujet changé de Générer un uuid pour un formdata dès l'ouverture du brouillon à Générer un identifiant pour un formdata dès la saisie
(tu parles de brouillon alors que le problème est de fonctionner également quand les brouillons ne sont pas activés, j'ai modifié un peu l'intitulé du ticket)
Ma perspective est de ne surtout pas étendre l'utilisation de magictoken, de simplifier le code en ayant un chemin unique qu'on passe par brouillons ou pas, que la question de brouillon/code de suivi soit juste une question d'UI.
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
Aucun souci avec ça bien sûr; mais plus embêté sur le fait que tu es la seule personne a bien comprendre l'enchaînement du code de saisie des formulaires (magic_token&etc..), donc si c'est quelqu'un qui n'est pas toi qui va/doit prendre ce ticket il faudra que tu pointes ici où tout ça devrait s'insérer AMHA.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Assigné à mis à Frédéric Péters
Basiquement, (et maintenant qu'on a les brouillons tout le temps activés), le plan ici serait de commencer la saisie par :
- si GET → création d'un formdata, draft, etc.
- ça créerait une entrée dans la db dès la visite, ça serait donc à accompagner de code qui supprimerait régulièrement les formdata vides
- le magictoken devient genre signed(formdata_id) (ça peut tout à fait changer de nom, aussi, pour éviter les confusions, mais c'est pareil tapé en input hidden)
- si POST → on pioche le formdata, il prend la place de ce qui s'appelle aujourd'hui "transient formdata" créé à la volée, etc.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Lié à Development #58219: Éviter d'écraser la session quand seulement une clé d'un dico a changé ajouté
Mis à jour par Benjamin Dauvergne il y a presque 2 ans
- Lié à Bug #65004: Ticket chapeau champs obligatoires vides à la soumission ajouté