Afficher un récapitulatif des étapes avant de valider le formulaire #96

Closed
opened 2 years ago by nicod_ · 13 comments
nicod_ commented 2 years ago
Collaborator

Règle Opquast n° 81 - Lors de la saisie d'un formulaire réparti sur plusieurs pages, un récapitulatif global est affiché avant l'envoi définitif.

https://checklists.opquast.com/fr/assurance-qualite-web/lors-de-la-saisie-dun-formulaire-reparti-sur-plusieurs-pages-un-recapitulatif-global-est-affiche-avant-lenvoi-definitif

Ce n'est pas géré actuellement, ce serait bien.

Règle Opquast n° 81 - Lors de la saisie d'un formulaire réparti sur plusieurs pages, un récapitulatif global est affiché avant l'envoi définitif. https://checklists.opquast.com/fr/assurance-qualite-web/lors-de-la-saisie-dun-formulaire-reparti-sur-plusieurs-pages-un-recapitulatif-global-est-affiche-avant-lenvoi-definitif Ce n'est pas géré actuellement, ce serait bien.
Owner

concrètenment ce serait quoi : après la dernière étape, un affichage de l'ensemble des étapes ? du coup ce serait peut être au core de gerer cela, en fournissant un truc genre "formulaires_etapes_recapitulatif" ?

concrètenment ce serait quoi : après la dernière étape, un affichage de l'ensemble des étapes ? du coup ce serait peut être au core de gerer cela, en fournissant un truc genre "formulaires_etapes_recapitulatif" ?
Poster
Collaborator

Un affichage de l'ensemble des étapes oui, en tenant compte de afficher_si, et en n'affichant que les saisies effectivement remplies.

Ça permet de relire tout ce qu'on a saisi avant de valider.

A mettre en option cochée par défaut, éventuellement, pour que la bonne pratique s'applique mais qu'on puisse débrayer pour un usage particulier ?

Un affichage de l'ensemble des étapes oui, en tenant compte de afficher_si, et en n'affichant que les saisies effectivement remplies. Ça permet de relire tout ce qu'on a saisi avant de valider. A mettre en option cochée par défaut, éventuellement, pour que la bonne pratique s'applique mais qu'on puisse débrayer pour un usage particulier ?
Owner

oki, bah du coup je pense que ce serait encore un truc à coder d'abord dans le core... j'essaierai ce week-end

oki, bah du coup je pense que ce serait encore un truc à coder d'abord dans le core... j'essaierai ce week-end
maieul referenced this issue from a commit 1 year ago
maieul referenced this issue from a commit 1 year ago
maieul referenced this issue from a commit 1 year ago
Owner

Donc pareil, j'ai mis dans issue_96 (on peut tester avec formidable avec la branche issuer_96).

Finalement j'ai renoncé pour l'instant à mettre dans le core, car je me dit qu'on devrait commencer par saisies, et ensuite voir à généraliser.

Pour les détails de l'implémentation technique, voir le message de commit sur la branche.

En avant premier des captures d'écran

Donc pareil, j'ai mis dans issue_96 (on peut tester avec formidable avec la branche issuer_96). Finalement j'ai renoncé pour l'instant à mettre dans le core, car je me dit qu'on devrait commencer par saisies, et ensuite voir à généraliser. Pour les détails de l'implémentation technique, voir le message de commit sur la branche. En avant premier des captures d'écran
Owner

Ça a l'air cool :)

Ça a l'air cool :)
Owner

faut tester maintenant :-p.

faut tester maintenant :-p.
maieul referenced this issue from a commit 1 year ago
maieul referenced this issue from a commit 1 year ago
maieul referenced this issue from a commit 1 year ago
Owner

Un point ergo tout de même : pour permettre à une personne de revenir à une étape X lorsqu'elle a le recapitulatif final des étapes, je provoque une vrai/fausse erreur.

Le message d'erreur globale est alors mis en vide. Je me demande si on devrait pas mettre un message tout de même, du style "Vous avez signalé une erreur à cette étape. À vous de la corriger.".

Un point ergo tout de même : pour permettre à une personne de revenir à une étape X lorsqu'elle a le recapitulatif final des étapes, je provoque une vrai/fausse erreur. Le message d'erreur globale est alors mis en vide. Je me demande si on devrait pas mettre un message tout de même, du style "Vous avez signalé une erreur à cette étape. À vous de la corriger.".
Owner

Euh alors j'ai dû rater quelque chose : qu'est-ce que signifie "Vous avez signalé une erreu" ? à quel moment c'est aux gens de définir ça ? (protip : aucun :p )

Le récapitulatif, c'est censé être juste de l'affichage, un récap quoi, il ne doit y avoir aucune fonctionnalité particulière, juste de la lecture. Après les gens valident finalement, ou reviennent en arrière s'ils sont pas contents (y a déjà un chemin d'étapes exprès pour ça)

Euh alors j'ai dû rater quelque chose : qu'est-ce que signifie "Vous avez signalé une erreu" ? à quel moment c'est aux gens de définir ça ? (protip : aucun :p ) Le récapitulatif, c'est censé être juste de l'affichage, un récap quoi, il ne doit y avoir aucune fonctionnalité particulière, juste de la lecture. Après les gens valident finalement, ou reviennent en arrière s'ils sont pas contents (y a déjà un chemin d'étapes exprès pour ça)
Owner

bah justement la phrase est pas bonne. Mais s'ielles reviennent en arrière, c'est bien que quelque part iellls se se trompées non ?

Donc c'est bien une erreur, mais pas au sens "technique" (genre les erreurs déclenché normalement par verifier), mais au sens "le contenu est pas correcte". Mais du coup faudrait trouver (ou pas) la bonne phrase en cas de retour arrière suite au recap de de ce qui a été saisie.

bah justement la phrase est pas bonne. Mais s'ielles reviennent en arrière, c'est bien que quelque part iellls se se trompées non ? Donc c'est bien une erreur, mais pas au sens "technique" (genre les erreurs déclenché normalement par `verifier`), mais au sens "le contenu est pas correcte". Mais du coup faudrait trouver (ou pas) la bonne phrase en cas de retour arrière suite au recap de de ce qui a été saisie.
Owner

Je ne comprends toujours pas :)

Ya aucune phrase à leur affiche du tout, ya aucune erreur : à tout moment n'importe qui a le droit de revenir en arrière tant qu'on n'a pas validé l'envoi final : c'est prévu de base dans l'API CVT multi étapes avec le aller_a_etape = X. Et c'est l'API qui se déplace au bon endroit, ya aucune fausse erreur à y mettre (ni erreur vide ni rien).

Je ne comprends toujours pas :) Ya aucune phrase à leur affiche du tout, ya aucune erreur : à tout moment n'importe qui a le droit de revenir en arrière tant qu'on n'a pas validé l'envoi final : c'est prévu de base dans l'API CVT multi étapes avec le aller_a_etape = X. Et c'est l'API qui se déplace au bon endroit, ya aucune fausse erreur à y mettre (ni erreur vide ni rien).
Owner

tant qu'on n'a pas validé l'envoi final : c'est prévu de base dans l'API CVT multi étapes avec le aller_a_etape = X.

bah le problème c'est que la feature que j'ai ajouté ne rentre pas dans ce schema au niveau de l'API (qui soit dit en passant utilise en interne aussi des fausses erreurs !). En effet, le principe de l'API c'est que si la dernière étape est validée (= sans erreur) et qu'il n'y pas demande de retour en arrière, bah on repasse la validation globale, et zou on envoie.

Du coup pour implémenter cette feature sans réécrire toute l'API, et surtout pour la tester avant une future implémentaton dans l'API, saisies fonctionne ainsi:

  • après la dernière étape, déclenche une fausse erreur qui permet d'afficher le recapitulatif final
  • si dans le recap final on demande à retourner à l'étape X, alors on declenche une fausse erreur sur cette étape

cf 1cbe6acf91

> tant qu'on n'a pas validé l'envoi final : c'est prévu de base dans l'API CVT multi étapes avec le aller_a_etape = X. bah le problème c'est que la feature que j'ai ajouté ne rentre pas dans ce schema au niveau de l'API (qui soit dit en passant utilise en interne aussi des fausses erreurs !). En effet, le principe de l'API c'est que si la dernière étape est validée (= sans erreur) et qu'il n'y pas demande de retour en arrière, bah on repasse la validation globale, et zou on envoie. Du coup pour implémenter cette feature sans réécrire toute l'API, et surtout pour la tester avant une future implémentaton dans l'API, saisies fonctionne ainsi: - après la dernière étape, déclenche une fausse erreur qui permet d'afficher le recapitulatif final - si dans le recap final on demande à retourner à l'étape X, alors on declenche une fausse erreur sur cette étape cf https://git.spip.net/spip-contrib-extensions/saisies/commit/1cbe6acf91e0df201ded5d0b62cae8ae32dd3f3a
Owner

qu'on déclanche une fausse erreur pour ne pas lancer la validation traitement, pour pouvoir afficher le récap, ça ok je pige

mais ce que je pige pas c'est pourquoi il y aurait une fausse erreur pour retourner en arrière, puisque justement l'API de base prévoit bien ça : pouvoir revenir en arrière à tout moment (donc y compris quand on est à la fin). Tu dis justement que ça passe au traitement si y a pas d'erreurs ni de retour en arrière. Bah là ya pas d'erreurs à mettre, mais ya bien un envoi de aller_a_etape avec une étape arrière, donc pas de fausse erreur à mettre.

qu'on déclanche une fausse erreur pour ne pas lancer la validation traitement, pour pouvoir afficher le récap, ça ok je pige mais ce que je pige pas c'est pourquoi il y aurait une fausse erreur pour retourner en arrière, puisque justement l'API de base prévoit bien ça : pouvoir revenir en arrière à tout moment (donc y compris quand on est à la fin). Tu dis justement que ça passe au traitement si y a pas d'erreurs *ni de retour en arrière*. Bah là ya pas d'erreurs à mettre, mais ya bien un envoi de aller_a_etape avec une étape arrière, donc pas de fausse erreur à mettre.
Owner

mais ce que je pige pas c'est pourquoi il y aurait une fausse erreur pour retourner en arrière, puisque justement l'API de base prévoit bien ça : pouvoir revenir en arrière à tout moment (donc y compris quand on est à la fin). Tu dis justement que ça passe au traitement si y a pas d'erreurs ni de retour en arrière. Bah là ya pas d'erreurs à mettre, mais ya bien un envoi de aller_a_etape avec une étape arrière, donc pas de fausse erreur à mettre.

Parce que l'API ne permettait pas aller_a_etape qui corresponde à la fois à l'étape courante et au nombre totale d'étape. Et je me suis embrouillé avec la correction d'un autre bug.

Du coup spip/spip#165

et https://git.spip.net/spip-contrib-extensions/saisies/commit/d02573c

> mais ce que je pige pas c'est pourquoi il y aurait une fausse erreur pour retourner en arrière, puisque justement l'API de base prévoit bien ça : pouvoir revenir en arrière à tout moment (donc y compris quand on est à la fin). Tu dis justement que ça passe au traitement si y a pas d'erreurs ni de retour en arrière. Bah là ya pas d'erreurs à mettre, mais ya bien un envoi de aller_a_etape avec une étape arrière, donc pas de fausse erreur à mettre. Parce que l'API ne permettait pas `aller_a_etape` qui corresponde à la fois à l'étape courante et au nombre totale d'étape. Et je me suis embrouillé avec la correction d'un autre bug. Du coup https://git.spip.net/spip/spip/pulls/165 et https://git.spip.net/spip-contrib-extensions/saisies/commit/d02573c
maieul referenced this issue from a commit 1 year ago
maieul closed this issue 1 year ago
maieul referenced this issue from a commit 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.