Permettre de choisir explictement de ne pas avoir de traitement

hop @touti @tcharlss @rastapopoulos

cette PR répond aux issues #106 (closed) et #160 (closed), en tenant compte de vos remarques, mais aussi du fait que je n'ai pas reussi à bien faire comprendre mon point.

ELle se compose de deux commits :

• 1 qui fait consensus : da42de5, qui supprime le message d'erreur côté public en l'absence de traitement
• 1 peut être moins consensuel 2cc4a9c a. Affiche une case "Pas de traitement (demande explicite)" pour distingue de "Pas de traiment" (parce que par le passé je n'avais pas cohcé la case traitement). b. Si cette case est cochée on ne propose pas les traitements standards et il n'y aucun mail d'alerte envoyé au/à là webmestre c. Si cette n'est pas cochée, et bien on s'assure qu'au moins un traitement est activé, et dans le cas contraire on provoque un message d'erreur à la config des traitements d. Compatibilité historique Dans tous les cas pour les anciens formulaires sans traitement cochée et sans case "pas de traitement", lorsque le formulaire est soumis, un message d'erreur est envoyé par mail à la / au webmestre avec les valeurs soumise.

Avec ces choix on répond à 3 contraintes : -* Continuer de prevenir les webmestre pour les sites avec des formulaires sans traitements cochés (compat historique). -* Permettre de choisir explicitement de ne pas avoir de traitement -* S'assurer que les personnes ne créent pas de formulaire sans traitements par étourderie.

@maieul a ajouté 2 révisions : da42de56face41e1a26eeda0c68cc7617024fed7 2cc4a9c6bba1265a1b76121bbac95361f323425a

@maieul a remplacé le titre issues_106_160_pas_de_traitement par Permettre de choisir explictement de ne pas avoir de traitement

Tu veux pas rajouter aussi

Pas de traitement (demande explicite) (VOUS ÊTES VRAIMENT SûR ?) (Non mais certain certain ?)

Moi je trouve que c'est prendre les gens pour plus bêtes qu'ils ne le sont et que c'est vraiment trop.

Afficher un message en haut qui alerte "Attention ce formulaire n'a aucun traitement configuré", en rouge si tu veux le rendre méchant pourquoi pas, mais ne bloquant aucune utilisation, bah ça suffit.

Si les gens savent pas lire ce qui est sous leur yeux en haut de page, en rouge, en gras, on va pas leur tenir la main non plus.

Bah on peut, mais alors pourquoi dans le passé à ton décider d'envoyer un message d'erreur et un mail de notif en cas de traitement non coché :)

J'ai tendance à penser que soit on guide vraiment, soit on ne guide pas du tout et on laisse le message "aucun traitement" tel qu'il est actuellement sur la page ?exec=formulaire

Et crois moi des gens qui ont besoin d'etre guidé sur un formulaire formidable, j'en connais un paquet (les "je suis allergique à l'nformatique, mais je veux quand même creer mon propre formulaire")

Je n'ai pas testé la PR mais ce qui est décrit me parait très bien sur le principe, avec une case à cocher explicite pour lever toute ambiguïté, incompréhension ou étourderie.

pareil que nicod_

C'est quand même un peu dommage de regrouper dans une même PR un truc qui fait consensus avec un truc qui le fait pas, ça fait un peu passage en force pour le 2ème...

J'entends bien ce qui motive ce changement, mais ça me semble juste une mauvaise solution à la fois en terme d'UX et de comportement.

Qui se souviendra des cas où ça envoie une notifs aux webmestres ou pas avec toutes ces conditions compliquées ?

Si je me mets à la place de quelqu'un qui tombe là-dessus pour la première fois, on comprend pas pourquoi on devrait cocher cette case.

Edit : il manque une chaîne de langue au fait

Ce qui me semblait le plus simple et compréhensible : mettre explicitement cette option de notification du webmestre (cochée par défaut à la rigueur).

Et éventuellement un message d'info ou de mise en garde si aucun traitement n'est coché. Et c'est tout.

Ce qui me semblait le plus simple et compréhensible : mettre explicitement cette option de notification du webmestre (cochée par défaut à la rigueur).

Et éventuellement un message d'info ou de mise en garde si aucun traitement n'est coché. Et c'est tout.

+1

@maieul a force-pushed 2 révisions : 2cc4a9c6bba1265a1b76121bbac95361f323425a f2d6894dee3d3dfaf79d826880b4c547a6436b92

@maieul a force-pushed 2 révisions : f2d6894dee3d3dfaf79d826880b4c547a6436b92 f581bdde5f06bae612c43cdf21a45f9b2f1014dd

C'est quand même un peu dommage de regrouper dans une même PR un truc qui fait consensus avec un truc qui le fait pas, ça fait un peu passage en force pour le 2ème...

tu est de mauvaise fois là : si j'avais voulu passé en force j'aurais tout mis dans le même commit et pas détaillé

Ce qui me semblait le plus simple et compréhensible : mettre explicitement cette option de notification du webmestre (cochée par défaut à la rigueur).

Cela n'a aucun sens : la notification webmestre, elle a été prévue uniquement pour les gens qui n'ont pas pensé à activer un traitement. C'est une sécurité. Donc si on dit qu'il faut activer manuellement ce mail de notif, on enlève son intérêt sécuritaire.

Qui se souviendra des cas où ça envoie une notifs aux webmestres ou pas avec toutes ces conditions compliquées ?

personne, car précisement la notif au webmestre est là pour pallier un défaut historique et ne serait conservé qu'à titre historique. A la rigueur on pourrait même la faire sauter, en considérant que depuis le tps, les webmestre concernés ont été prevenus

Et éventuellement un message d'info ou de mise en garde si aucun traitement n'est coché. Et c'est tout.

Bah c'est un peu la question sur le niveau de mise en garde que l'on veut. Personnellement je préfère avoir une mise en garde un peu plus strict que de faire du dépannage utilisateurice après coup.

Edit : il manque une chaîne de langue au fait

corrigé. J'en ai profité pour ameliorer le deuxième commit, pour faire que la case "Pas de traitement (choix explicite) ne s'affiche plus si on choisit un traitement".

Bah on peut, mais alors pourquoi dans le passé à ton décider d'envoyer un message d'erreur et un mail de notif en cas de traitement non coché :)

J'avais pas répondu à ça : bah j'ai jamais décidé ça perso, je me rappelais même pas que ça faisait ça, et si je l'avais su j'aurais dit pareil que dans ce fil : un message très explicite, très visible, et bien placé au bon endroit (ou bons endroits si plusieurs), suffit largement à rendre très clair le fait que le formulaire ne va rien faire. Pas besoin d'embêter plus que ça.

A la rigueur on pourrait même la faire sauter, en considérant que depuis le tps, les webmestre concernés ont été prevenus

Et donc +1, moins de code à maintenir, et par ailleurs on pourrait aussi parfaitement avoir un form qui n'a pas besoin de faire des traitements exprès (par ex qui sert juste à calculer ou simuler des choses), sans recevoir un mail infantilisant à chaque fois ("attention t'as pas bien fait les choses")

Bah c'est un peu la question sur le niveau de mise en garde que l'on veut. Personnellement je préfère avoir une mise en garde un peu plus strict que de faire du dépannage utilisateurice après coup.

Comme on le dit plus haut, une phrase bien rédigée, mise en avant un peu fortement, et placée aux bons endroits, c'est DEJA super visible et super explicite. Si quelques personnes n'ont pas pigé et sont surpris que ça ne fasse rien, c'est plutôt alors que le message n'est pas placé au bon endroit, pas assez gros, etc. Mais pas qu'on doit forcer la majorité à faire des actions en plus ou qu'on doit remplir leurs boites de notifs.

@maieul a fait référence à cette PR depuis un commentaire de spip-contrib-extensions/saisies#170 Saisie explication : proposer les classes de différent boite de spip

@maieul a force-pushed 2 révisions : f581bdde5f06bae612c43cdf21a45f9b2f1014dd fc783d385d5530d9d17ca1a2fcc9ccad870b5f32

Bon. Je suis vraiment pas convaincu du simple message d'alerte, mais je crois qu'autant parler à un mur parfois (sachant que pour le coup nous étioms 3 pluto en faveur d'une option "dur).

bref du coup nouvelle version de la branche, qui s'appuie sur https://git.spip.net/spip-contrib-extensions/saisies/pulls/316

In fine je me suis remis dans une étape de création de formulaire.

Et donc :

• un simple message en bleu lorsqu'on arrive à la configuration des traitements

• sur la page de formulaire, par contre, une vrai alert/notice (j'avoue que je me perd dans la terminologie des boites d'alerte entre le role et le type).

Hello, j'ai pas testé, tant mieux si tu as réussi à simplifier @maieul

Par contre, la phrase "le formulaire ne fait rien" n'est pas bonne.

Si par exemple j'ai un formulaire constitué d'une case à cocher pour valider la charte et rediriger vers l’article xxx

Ici, le formulaire va faire quelque chose d'important en fait :) à la validation il redirige. Est-ce que ce serait pas le problème d'UX qu'on découvre là ?

"Aucun traitement n'est activé, le formulaire ne traitera aucune donnée"

Sinon résultat enregistré, données stockées.

Ou sinon, refonte UX en considérant les actions de redirection comme un traitement ?

j'ai pas testé, tant mieux si tu as réussi à simplifier @maieul

je ne sais pas si c'est simplifié. C'est différent.

"Aucun traitement n'est activé, le formulaire ne traitera aucune donnée"

Je comprend ta remarque. Mais j'hésite encore sur la formulation. Après tout vérifier que la case est coché, c'est pas deja un traitement (du point de vue UX, je dis pas en terme de CVT).

Ou sinon, refonte UX en considérant les actions de redirection comme un traitement ?

Pas convaincu,pour 3 raisons:

• UX -> on a une réglage "afficher après", et je vois mal mettre "le formulaire à nouveau" comme un traitement
• terminologique : en soit rediriger ne fait aucun traitement sur les données (même si bon, de facto on emt cela dans la fonction formulaires_formidable_traiter()
• de code :
  • il y a sans doute du code dans la nature qui vérifie si redirection ou pas, ca risque de casser (a minima : formidable_mailsubscriber, qui selon que redirection ou non, fait l'inscripton via script JS ou pas, mais sans doute aussi tout ce qui implique l'appel à un service externe, comme la banque)
  • il faudrait s'assurer que le traitement redirection arrive à la toute fin dans tous les cas, ce qui implique du code dérogatoire, etc. pas top

Un retour d'autres personnes sur la nouvelle version ? et sur la phrase à utiliser ?