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

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.

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" ?

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 ?

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

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

formidable_options_globales.png

65 KiB

formidable_recapitulatif.png

46 KiB

Ça a l'air cool :)

faut tester maintenant :-p.

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.".

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)

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.

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).

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

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.

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

Labels Milestones

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