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).
Related issues
History
Updated by Benjamin Dauvergne over 6 years ago
- Related to Development #17685: "préblocage" d'une réservation added
Updated by Benjamin Dauvergne over 6 years ago
- Related to Development #24567: Connecteur IWS added
Updated by Frédéric Péters over 6 years ago
- Subject changed from Générer un uuid pour un formdata dès l'ouverture du brouillon to 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.
Updated by Benjamin Dauvergne over 6 years ago
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.
Updated by Frédéric Péters almost 6 years ago
- Assignee set to 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.
Updated by Benjamin Dauvergne almost 3 years ago
- Related to Development #58219: Éviter d'écraser la session quand seulement une clé d'un dico a changé added
Updated by Benjamin Dauvergne over 2 years ago
- Related to Bug #65004: Ticket chapeau champs obligatoires vides à la soumission added