Bonsoir
Dans certains de mes formulaires, je définis un message de retour.
Il s’affiche bien, mais s’y ajoutent le(s) message(s) par défaut de Formidable, alors que je voudrais que mon message retour remplace le(s) message(s) par défaut.
Ces derniers ne sont pas désactivables quand on saisit un message retour ?
Merci
@+
Luc
Le 23/02/2021 à 19:44, Luc Mamin a écrit :
Bonsoir
Dans certains de mes formulaires, je définis un message de retour.
Il s'affiche bien, mais s'y ajoutent le(s) message(s) par défaut de Formidable, alors que je voudrais que mon message retour remplace le(s) message(s) par défaut.Ces derniers ne sont pas désactivables quand on saisit un message retour ?
Merci
@+
Luc
Pour certains cas les messages de retours sont nécessaires car contiennent du JS. On a changé le comportement en ce sens il y a peu.
Pour l'heure on a encapsulà en css chacun des messages individuels, ce qui fait qu'avec des règles css tu pourrais choisir de n'afficher que le premier message, le message general, en masquant les autres
Peut être devrait-on tout de même prévoir une option permettant de choisir précisement ce qu'on veut, car le masquage css c'est pas forcément optimal.
Mais je t'invite à en discuter sur spip-dev, ou mieux, ouvrir un ticket 
Oui, pour l’instant j’ai masqué en css la div « retour_email », mais ce serait mieux si c’était configurable.
Pour spip-dev ou l’ouverture d’un ticket, je n’ai jamais réussi à m’inscrire…
@+
Luc
Le 23/02/2021 à 20:49, Luc Mamin a écrit :
Oui, pour l'instant j'ai masqué en css la div "retour_email", mais ce serait mieux si c'était configurable.
Pour spip-dev ou l'ouverture d'un ticket, je n'ai jamais réussi à m'inscrire...
@+
Luc
https://listes.rezo.net/mailman/listinfo/spip-dev pour t'inscrire à la liste spip-dev
ensuite tu pourras demander (après avoir accepté la charte : Charte d’accueil de SPIP - SPIP) à avoir un compte.
Le 23/02/2021 à 20:01, Maïeul Rouquette a écrit :
Le 23/02/2021 à 19:44, Luc Mamin a écrit :
Bonsoir
Dans certains de mes formulaires, je définis un message de retour.
Il s'affiche bien, mais s'y ajoutent le(s) message(s) par défaut de Formidable, alors que je voudrais que mon message retour remplace le(s) message(s) par défaut.Ces derniers ne sont pas désactivables quand on saisit un message retour ?
Pour certains cas les messages de retours sont nécessaires car contiennent du JS. On a changé le comportement en ce sens il y a peu.
Pour l'heure on a encapsulà en css chacun des messages individuels, ce qui fait qu'avec des règles css tu pourrais choisir de n'afficher que le premier message, le message general, en masquant les autres
Peut être devrait-on tout de même prévoir une option permettant de choisir précisement ce qu'on veut, car le masquage css c'est pas forcément optimal.
Mais je t'invite à en discuter sur spip-dev, ou mieux, ouvrir un ticket
J'ai noté le même problème, qui est en fait apparu récemment, et on en a discuté sur IRC
Il y a un ticket de Formidable avec l'explication du pourquoi le problème réapparait, et une solution/bidouille temporaire faute de mieux (mes deux commits).
--
nicod_
Le 24/02/2021 à 13:14, nicod_ a écrit :
Le 23/02/2021 à 20:01, Maïeul Rouquette a écrit :
Le 23/02/2021 à 19:44, Luc Mamin a écrit :
Bonsoir
Dans certains de mes formulaires, je définis un message de retour.
Il s'affiche bien, mais s'y ajoutent le(s) message(s) par défaut de Formidable, alors que je voudrais que mon message retour remplace le(s) message(s) par défaut.Ces derniers ne sont pas désactivables quand on saisit un message retour ?
Pour certains cas les messages de retours sont nécessaires car contiennent du JS. On a changé le comportement en ce sens il y a peu.
Pour l'heure on a encapsulà en css chacun des messages individuels, ce qui fait qu'avec des règles css tu pourrais choisir de n'afficher que le premier message, le message general, en masquant les autres
Peut être devrait-on tout de même prévoir une option permettant de choisir précisement ce qu'on veut, car le masquage css c'est pas forcément optimal.
Mais je t'invite à en discuter sur spip-dev, ou mieux, ouvrir un ticket
J'ai noté le même problème, qui est en fait apparu récemment, et on en a discuté sur IRC
Il y a un ticket de Formidable avec l'explication du pourquoi le problème réapparait, et une solution/bidouille temporaire faute de mieux (mes deux commits).
Inconsistance des messages de retour dans les traitements supplémentaires (#44) · Tickets · spip-contrib-extensions / formidable · GitLab
Ce qui peut être envisagé, c'est pour chaque formulaire avoir le choix entre
- afficher le message de retour general + les messages spécifiques
- afficher le message de retour general uniquement
- afficher uniquement les messages spécifiques
Sachant que dans tous les cas si pas de message spécifiques on affiche le general, et si pas de message general on affiche les spécifique
Le 24/02/2021 à 14:07, Maïeul Rouquette a écrit :
Ce qui peut être envisagé, c'est pour chaque formulaire avoir le choix entre
- afficher le message de retour general + les messages spécifiques
- afficher le message de retour general uniquement
- afficher uniquement les messages spécifiques
Trop compliqué à comprendre à mon avis.
Si on remplit le message manuel, c'est qu'on veut qu'il s'affiche, sinon on ne le remplit pas, ya pas cette troisième option pour moi. Et entre les deux qui restent, l'une est forcément celle par défaut, ce qui fait que l'autre peut être juste une case à cocher. À définir laquelle doit être par défaut.
Ce qui permet de juste afficher une simple case à cocher en plus *si* le message est non vide (afficher_si). J'ai plutôt l'impression que ce qui est attendu par défaut, c'est que ce soit notre propre message qui s'affiche, et que afficher tous les ajouts des traitements c'est pour les gens qui savent que ça doit être obligatoire à cause de JS, enfin des cas très particuliers plus rares.
Donc :
Message de retour
Blabla bla mon message
(Explication plus longue éventuellement ici au-dessus)
Afficher le message en supplément des retours par défaut des traitements
Et c'est tout, c'est simple et ça permet bien les trois, avec une seule case en plus.
--
RastaPopoulos
RastaPopoulos a écrit le 24/02/2021 à 15:05 :
J'ai plutôt l'impression que ce qui est attendu par défaut, c'est que ce soit notre propre message qui s'affiche, et que afficher tous les ajouts des traitements c'est pour les gens qui savent que ça doit être obligatoire à cause de JS, enfin des cas très particuliers plus rares.
Et si le Js était traité à part au lieu d'être un vilain hack ?
--
RealET
Le 24/02/2021 à 15:17, RealET a écrit :
RastaPopoulos a écrit le 24/02/2021 à 15:05 :
J'ai plutôt l'impression que ce qui est attendu par défaut, c'est que ce soit notre propre message qui s'affiche, et que afficher tous les ajouts des traitements c'est pour les gens qui savent que ça doit être obligatoire à cause de JS, enfin des cas très particuliers plus rares.Et si le Js était traité à part au lieu d'être un vilain hack ?
Non tu peux avoir des cas où tu veux afficher aussi les messages de retour individualisé aussi en plus du message general.
Par exemple "Votre demande a bien été recu" (message général).
"VOus avez été inscrit à tel evenement" (trautement 1)
"Vous avez été inscrit à telle liste" (traitement 2)
Le 24/02/2021 à 15:05, RastaPopoulos a écrit :
Le 24/02/2021 à 14:07, Maïeul Rouquette a écrit :
Ce qui peut être envisagé, c'est pour chaque formulaire avoir le choix entre
- afficher le message de retour general + les messages spécifiques
- afficher le message de retour general uniquement
- afficher uniquement les messages spécifiquesTrop compliqué à comprendre à mon avis.
Si on remplit le message manuel, c'est qu'on veut qu'il s'affiche, sinon on ne le remplit pas, ya pas cette troisième option pour moi. Et entre les deux qui restent, l'une est forcément celle par défaut, ce qui fait que l'autre peut être juste une case à cocher. À définir laquelle doit être par défaut.
Ce qui permet de juste afficher une simple case à cocher en plus *si* le message est non vide (afficher_si). J'ai plutôt l'impression que ce qui est attendu par défaut, c'est que ce soit notre propre message qui s'affiche, et que afficher tous les ajouts des traitements c'est pour les gens qui savent que ça doit être obligatoire à cause de JS, enfin des cas très particuliers plus rares.
Donc :
Message de retour
Blabla bla mon message(Explication plus longue éventuellement ici au-dessus)
Afficher le message en supplément des retours par défaut des traitementsEt c'est tout, c'est simple et ça permet bien les trois, avec une seule case en plus.
oui, simplifions mais le cœur de mon message était de dire que cela pourrait être une option.
par contre " Afficher le message en supplément des retours par défaut des traitements" je comprend pas
"Afficher en outre les message de retours des traitements spécifiques" me parait plus clair
(notes : qui ne sont pas nécessairement des messages par défaut, ca peut être selon les traitements des messages régler au cas par cas...)
Le 24/02/2021 à 15:05, RastaPopoulos a écrit :
Le 24/02/2021 à 14:07, Maïeul Rouquette a écrit :
Ce qui peut être envisagé, c'est pour chaque formulaire avoir le choix entre
- afficher le message de retour general + les messages spécifiques
- afficher le message de retour general uniquement
- afficher uniquement les messages spécifiquesTrop compliqué à comprendre à mon avis.
Si on remplit le message manuel, c'est qu'on veut qu'il s'affiche, sinon on ne le remplit pas, ya pas cette troisième option pour moi. Et entre les deux qui restent, l'une est forcément celle par défaut, ce qui fait que l'autre peut être juste une case à cocher. À définir laquelle doit être par défaut.
Ce qui permet de juste afficher une simple case à cocher en plus *si* le message est non vide (afficher_si). J'ai plutôt l'impression que ce qui est attendu par défaut, c'est que ce soit notre propre message qui s'affiche, et que afficher tous les ajouts des traitements c'est pour les gens qui savent que ça doit être obligatoire à cause de JS, enfin des cas très particuliers plus rares.
Donc :
Et donc c'est intégré et publié avec la dernière version de formidable
Bonsoir
Merci pour cet ajout.
Je remarque un pb pour un champ dans lequel j’ai configuré une validation par : Comparaison ; Champ « input_x » ; Comparaison « == » :
@+
Luc
Le 28/02/2021 à 20:22, Luc Mamin a écrit :
Bonsoir
Merci pour cet ajout.
Je remarque un pb pour un champ dans lequel j'ai configuré une validation par : Comparaison ; Champ "input_x" ; Comparaison "==" :
- Sur un premier site, avec Formidable 4.10, la comparaison est reconnue : erreur affichée, et validation du formulaire bloquée. C'est le comportement attendu.
- Sur un second site, avec Formidable 4.11, la comparaison semble ignorée : la validation du formulaire va à son terme...
- Sur ce second site, impossible de réinstaller une version antérieure de Formidable : "version obsolète".@+
Luc
heu... je sais pas de quoi tu parle. Mais envoie moi un .yaml minimum du problème. Mais on a rien changé sur la validation entre la 4.10.0 et la 4.11.0. Ca doit plutot vebnir d'ailleurs
Le 28/02/2021 à 20:59, Maïeul Rouquette a écrit :
Le 28/02/2021 à 20:22, Luc Mamin a écrit :
Bonsoir
Merci pour cet ajout.
Je remarque un pb pour un champ dans lequel j'ai configuré une validation par : Comparaison ; Champ "input_x" ; Comparaison "==" :
- Sur un premier site, avec Formidable 4.10, la comparaison est reconnue : erreur affichée, et validation du formulaire bloquée. C'est le comportement attendu.
- Sur un second site, avec Formidable 4.11, la comparaison semble ignorée : la validation du formulaire va à son terme...
- Sur ce second site, impossible de réinstaller une version antérieure de Formidable : "version obsolète".@+
Luc
Merci Luc pour l'envoi du CVT. Mea culpa. Ce n'était pas formidable (qui ne s'occupe pas des vérifications), ni verification (qui n'avait pas bougé sur ce point), mais saisies, où j'avais fait un correctif erronnée sur la vérification côté PHP de la condition MATCH. Si bien que ton deuxième champ qui était conditionné par un MATCH était considéré comme null ... et donc non vérifié.
La v3.48.2 de saisies corrige cela.
Super !
Merci
Luc
Le 28/02/2021 à 14:54, Maïeul Rouquette a écrit :
Et donc c'est intégré et publié avec la dernière version de formidable
Aprs discussion, on a encore changé !
Plus de case à cocher. Chaque traitement décide de manière intelligente si il affiche son message ou pas.
Ex :
- les traitements emails et enregistrrement ne mettent le message qui si pas de message general (if (!$args['message_retour_general'])
- formidable_mailsubscriber affiche systématiquement son message car c'est une info importante.