On voudrait pouvoir être sûr qu’on a bien fait la demande d’affectation sans avoir à aller fouiller dans les mails envoyés de notre client perso
Je n’ai pas bien compris je pense : je croyais que tu voulais qu’au clic, ça ouvre le client mail (équivalent formule mailto dans colonne). Donc il faudra un clic manuel pour envoyer le mail, donc je ne comprends pas comment tu seras sûr d’avoir fait la demande (tu ne pourras pas vérifier que quelqu’un a bien cliqué « Envoyer » dans le client ?)
Oui, on ne pourra pas être sûr qu’on a fini par envoyer le mail dans le client, mais on voudrait au moins se dire que quelqu’un a pensé à le faire (et qu’il est probablement allé jusqu’au bout de la démarche).
J’ai fait le mailto pré-rempli avec des champs, mais je voudrais juste mettre en valeur le fait qu’on a déjà cliqué, comme on pourrait le faire en HTML/css pour un lien a:visited
Pour ce qui est des pieces jointes, j’aurais tendance à dire que const temp_token = grist.docApi.getAccessToken({readOnly: false}) pour l’utiliser ensuite via l’API http fonctionne, où est le problème ? Est-ce à ce moment que le problème CORS intervient ?
Merci pour les précisions !
Comme cela peut complexifier le formulaire, j’aimerais savoir si d’autres personnes ont le même besoin.
N’hésitez-pas à liker ce post si vous souhaitez aussi qu’au moment du clic sur le bouton « Valider », cela déclenche l’ouverture de votre client mail, avec un même destinataire pour toutes les soumissions, et dans le contenu du mail, les réponses soumises via le form ?
Vous pouvez ajouter des liens, du gras, italique, liste à puces, emojis, couleur, surlignage, style (3 titres disponibles, ou paragraphe).
Ce sont les mêmes options que le Custom widget “Clean Text”
corrections
il n’est plus possible de rajouter directement des titres - devenu inutile car les titres sont disponibles dans l’éditeur de texte libre. Cependant, les titres que vous auriez déjà ajoutés au custom widget sont préservés
les colonnes formule ne sont plus disponibles à l’ajout, vu qu’elles ne peuvent pas être éditées par l’utilisateur·ice final
les colonnes PJs ne sont plus dispos à l’ajout en attendant de débloquer le souci de chargement dans la table (cf ici)
Je vois que les « jolies police » sont fournies par Google Fonts, avec appel à fonts.googleapis.com
Problème : cet appel enfreint le RGPD et il y a déjà eu une jurisprudence en Europe à ce sujet. Donc je déconseillerais cette fonctionnalité dans un widget destiné à l’administration et un outil scruté de près par nos DPO…
J’aimerais aider pour l’ajout de pièces jointes dans le formulaire (nous avons un cas d’usage où ce serait très utile).
Je n’arrive pas à comprendre d’où vient la limitation. En particulier, je suis très surpris que les pièces jointes fonctionnent sur les formulaire grist classiques. Comme si il y avait moins de restrictions de sécurité pour communiquer avec l’API via un site externe que depuis la même page. (Il est possible que le formulaire utilise un mécanisme complètement différent, mais je trouve cela surprenant tout de même). J’ai ajouté un commentaire dans la discussion github.
Dans le cas où cela nécessite réellement de changer les headers côté infrastructure, quel stratégie penses-tu adopter ? Est-ce que tu ajouterais les champs de type « attachment » dans ton widget avec un warning expliquant la configuration nécessaire ?
Merci @audezu pour la correction et la réactivité, ça marche nickel.
L’affichage conditionnel « ne permet » (c’est déjà très bien) qu’une condition ‹ est égal à ›, je pensais peut être à une condition supplémentaire ‹ est différent de › voire du multi conditions avec ‹ et ›/‹ ou ›.
J’ai contourné mon problème en modifiant mon formulaire (j’avais une liste de choix unique avec 3 possibilités et je voulais l’affichage conditionnel d’un champ pour 2 de ces choix).
Bonjour,
Je n’ai pas ce besoin dans l’immédiat, mais je trouve la fonctionnalité intéressante. Peut-être pourrait-on y adjoindre un bouton d’activation / désactivation ou bien deux boutons , « Valider » et « Valider avec mail » ?
Bonjour
Bravo pour commencer, beaucoup d’éléments intéressants dans cette proposition.
je constate un comportement différent entre les formulaires de grist et celui-ci.
Dans le formulaire de grist, lorsqu’on insère un booléen et qu’on le rend obligatoire, le formulaire ne peut être validé tant que le booléen n’est pas modifié. C’est pratique pour faire accepter une règle de fonctionnement par exemple.
Dans le votre, le formulaire est accepté, même si le booléen n’est pas modifié.
Y aurait-il moyen d’avoir une option qui rendrait obligatoire la mise à true de ce champ ?
Merci encore pour tout ce travail
@audezu
je viens d’utiliser ton widget (trop bien)
Une remarque : je l’utilise pour de la saisie de remontées de notes et si je saisis 4,5 ça ne passe que 4 il me faut saisir 4.5
ça peut être bloquant pour les utilisateurs .
N’hésitez-pas à me signaler en cas de bugs/régressions.
