accepter la virgule comme séparateur de décimales (merci @Bozon)
si un booléen est obligatoire, forcer la coche de la case / valeur True (merci @Arnault)
sécurisation des champs : Trim + suppression des caractères de contrôle invisibles + limite à 50000 caractères max
Audit du code
Nous avons commencé à relire le code avec @florent.fayolle, nous devons encore y travailler, on vous tiendra au courant dès que l’ajout à la bibli officielle sera fait !
Merci beaucoup, je l’utilise et c’est vraiment top pour les agents en interne qui ne sont pas familiarisés à Grist. Par contre, oups, j’ai voulu rajouter le champ date et heure pour une visualisation plus fine dans le calendrier, et… ça ne marche pas…
Bonjour
merci pour ce widget très pratique. il me reste un petit détail à régler : les conditions de mes colonnes ne remontent pas dans le formulaire (ni celui-ci ni le formulaire de base de Grist). ex : quand un des réseaux est sélectionné dans un menu déroulant, seules les structures appartenant à ce réseau s’affichent dans le menu déroulant suivant. cela fonctionne dans la table des données.
Merci Aude, je me suis débrouillée avec un calcul en ajoutant une case matin/après-midi :), ça marche, les collègues trouvent ça pratique! (c’est un bête tableau de recensement de congés pour remplacer les souhaits sur excel…)
Le widget est désormais audité, mais il faut l’importer dans la bibliothèque des instances DINUM et ANCT avec un peu de configuration, @florent.fayolle est sur le coup, ce sera probablement pour cette semaine. On vous tient au courant dès que c’est dispo.
Le widget « Formulaire interne » (aka « intra-form ») est officiellement disponible dans les bibliothèques des instances DINUM et ANCT Un très grand merci à @florent.fayolle
Vous pouvez l’ajouter en cliquant sur Nouveau > Ajouter une vue > Personnalisée > Formulaire interne. Il faut ensuite accepter l’accès au document dans le panneau de création (panneau latéral droit).
Et quoi de mieux pour annoncer sa disponibilité…qu’un formulaire interne ?
Hello !
J’ai une table à laquelle mes utilisateurs n’ont aucun droit. Pourtant, j’aimerai leur afficher un formulaire de saisie d’information. J’avais réussi à trouver une astuce via les formulaires Grist normaux : le formulaire à remplir était dans le widget webpage associé à une table auquel tout le monde a accès.
Est-ce possible d’arriver à mes fins avec ce nouveau formulaire ?
Hello non, comme le formulaire est interne il agit comme toute autre vue : il ne pourra pas alimenter une table sur laquelle l’utilisateur n’a pas les droits en écriture, il y aura une erreur « Blocked by access rules ».
Ce que tu pourrais faire par contre, si c’est acceptable pour toi que les utilisateurs puissent lire leurs propres données (mais tu peux même limiter cela en ne créant pas de vues de ta table, donc il faudrait qu’ils aient l’idée d’aller dans les données source) :
dans la table, ajouter une colonne pour récupérer le mail de l’utilisateur qui soumet sa réponse (formule d’initialisation user.Email)
créer des permissions sur la table pour donner un accès seulement en lecture et ajout de ligne (R et C) avec user.Email == rec.Email. Et ne pas donner les droits de modification et suppression (U et D)
Tu peux aussi utiliser l’id de session (user.SessionID) au lieu du mail, pour qu’ils n’aient accès qu’à leurs propres données de la session en cours uniquement.
C’est génial.
Il me manque bien quelques bricoles pour mon modèle de gestion de projet mais je vois que tout est dans le backlog sur github. Trop cool.
Cela risque de prendre du temps de relecture et corrections avant que tout soit disponible… S’il y a des volontaires pour nous aider et faire des premières relectures du code, vous êtes bienvenu·es !
Prise en compte des colonnes de type « Date & heure »
Possibilité d’ajouter un filtre/condition sur liste déroulante pour les colonnes de type référence/réf multiple .
Les cas pris en compte :
Ref vs Ref : choice.Departement == $Departement
Ref vs RefList : choice.Departement in $Departements
RefList vs Ref : $Departement in choice.Departements
RefList vs RefList : intersection
Spoiler : il faudra simplement choisir la colonne par rapport à laquelle on veut filtrer, et la vue générera la règle selon le type de colonne détecté dans la table référencée. Elle nous affichera la règle en python et gèrera même les intersections de liste (ie dans le cas de réf multiple de chaque côté, plus besoin de « colonne technique ») !
J’ai testé la fonctionnalité pour les questions conditionnelles mais elle semble opérationnelle qu’avec des colonnes type référence. C’est possible d’étendre son usage avec des colonnes booléenne également ?
Bonjour à tous,
Un grand merci à l’ensemble des contributeurs pour la mise à disposition et l’évolution constante de ce widget.
Ma maîtrise de l’anglais ne me permettant pas d’être certain que mes demandes sont prises en compte dans les tickets GitHub, je souhaiterais obtenir une confirmation sur deux points :
Les conditions pour les listes déroulantes sont-elles bien prévues dans la todo list (a priori, issue #5) ?
Je n’ai pas trouvé de ticket concernant la possibilité d’ajouter une valeur directement dans une liste de référence. Cette fonctionnalité est-elle envisagée ou existe-t-il déjà une issue dédiée ?
Je vous remercie par avance pour vos retours.
Cordialement,
avec plaisir, les questions conditionnelles fonctionnent avec réf ou choix, est-ce que ça pourrait t’aller de fonctionner avec un choix unique oui/non ?
Un très grand merci à 
pour mon modèle de gestion de projet mais je vois que tout est dans le backlog sur github. Trop cool.
