Remplir plusieurs tables avec un seul formulaire (Incident + Victimes)

Demandes d'aide
1

Bonjour à tous,

Je débute avec Grist et je cherche à mettre en place un formulaire permettant de saisir des données dans plusieurs tables en une seule fois.

Voici la structure actuelle de mon document :

Une table Incident (informations générales : lieu, date, type, etc.)

Une table Victime, liée à Incident via une référence multiple

Mon objectif serait que l’utilisateur puisse remplir un formulaire unique regroupant :

les données de l’incident,

et les données des victimes associées (nom, âge, etc.),

le tout en une seule soumission, avec création automatique des enregistrements et des liens entre les tables.

Est-ce que cela est possible nativement dans Grist ?
Sinon, existe-t-il un workflow recommandé ou une méthode de contournement (par exemple via un formulaire personnalisé utilisant l’API Grist) ?

Merci beaucoup pour votre aide !
Et bravo pour cet outil très intéressant :blush:

Bien cordialement,

2

Hello :smiling_face:
C’est un rêve !
En une seule soumission, nativement, je ne crois pas (ce qu’on fait d’habitude c’est créer 2 forms et à la première soumission, on redirige automatiquement vers l’url du 2e), mais curieuse aussi de savoir si d’autres personnes ont trouvé un contournement !

1 « J'aime »
3

@audezu avec un peu de Ex - alimenter la table référencée automatiquement - Grist je pense que c’est jouable (« 2 forms et à la première soumission, on redirige automatiquement vers l’url du 2e » ? :thinking: IDTS)
Je pense qu’on peut faire une table ‹ Réponses au formulaire › (= ce sera une table de jonction) et ensuite répartir les data incident dans une table ‹ Incidents › et les data victime dans la table ‹ Victimes › avec des lookupOrAddDerived (et lier les tables of course)

2 « J'aime »
4

coucou, je ne suis pas arrivée à faire fonctionner le lookupOrAddDerived malheureusement :confused: ça marchait bien pour mon exemple tout simple que tu as partagé, mais ça ne marchait plus dès que j’ajoutais une colonne…

Je partage ici les retours que j’avais faits sur Tchap :

aaah j’ai pu le faire marcher simplement avec : Clients.lookupOrAddDerived(Nom = $Client_txt_libre_)

De ce que je vois dans le code y a eu des changements sur cette fonction, sûrement pour ça.

C’est trop génial et j’en avais vraiment besoin, merci beaucoup

Celine Delval [Diplomatie] !!!

hello ! bon j’ai des soucis avec cette fonction, dès que je rajoute une colonne dans la table qui référence, ça fait complètement bugger le grist…

Celine Delval [Diplomatie] elle fonctionne de ton côté ? Sinon je peux poser la question à GristLabs, je me demande si elle est vraiment utilisable, c’est peut-être pour ça qu’elle n’est pas (plus?) documentée

réponse de Paul, CTO de GristLabs: « Oui, c’est volontairement omis de la documentation, car, bien que puissant, il est facile de se « couper avec ». Il est toutefois tout à fait possible de développer une fonctionnalité solide de cette manière. Dmitry avait un plan il y a quelque temps, et je crois qu’il a été partiellement implémenté, mais nous avons manqué de temps et avons dû prioriser d’autres choses. J’espère vraiment que nous, ou quelqu’un d’autre, pourrons y revenir un jour. »

si y a des gens motivés pour regarder ça avec moi, let me know!

1 « J'aime »
5

Bonjour @audezu je serais très intéressé pour avoir plus de détails sur les actions qui amènent à faire planter Grist ? C’est quand vous ajoutez une colonne dans la table Livraisons ou dans la table Clients ?

D’ailleurs au passage, j’ai réussi à faire tenir en une seule colonne l’ajout d’une nouvelle référence si elle n’existe pas (plus besoin de la colonne de texte libre).
Dans la colonne « Client (Ref) », j’utilise une formule d’initialisation avec le code suivant :

if type(PEEK($Client_ref_)) is grist.AltText:
  return Clients.lookupOrAddDerived(Nom=str(PEEK($Client_ref_)))
return PEEK($Client_ref_)

Quand le texte tapé n’existe pas dans la table Clients, le type d’objet utilisé par Grist pour afficher le texte sur fond rouge, c’est AltText, donc si je détecte que la valeur est de ce type, je déclenche un ajout dans la table Clients, sinon je retourne la référence telle qu’elle est.
On ne peut pas faire plus simple je pense, car juste Clients.lookupOrAddDerived(Nom=str(PEEK($Client_ref_))) ajouterait des Clients[1], Clients[2]…

De cette manière, plus besoin d’afficher deux colonnes avec la même information, et l’utilisateur peut profiter des suggestions de Grist pour éviter les doublons. :slight_smile:

Et ça a l’air de fonctionner si j’active l’option « Appliquer sur les modifications à » appliquée à elle-même.

Enfin je suis en train de me dire que ma solution évite peut-être le problème de plantage soulevé. Vu que ce n’est plus dans une formule, mais juste sur une initialisation, ce n’est exécuté qu’à la création de ligne ou à la modification de la valeur, et comme il y a un test conditionnel, ça ne se déclenche que si la valeur n’existe pas. On peut supposer que lors de l’ajout de colonne, les recalculs ne sont pas les mêmes entre formule et initialisation. En tous cas, sur mes tests j’ai pu ajouter des colonnes dans les deux tables.

6

chez moi ça fonctionne parfaitement et c’est meme fichtrement pratique ! :woman_shrugging:t2:

7

Bonjour,

Cette colonne de référence unique a l’air de faire très bien le boulot mais par contre n’est pas adaptée dans le cas d’un formulaire car dans ce cas le champ est de type « référence » et ne permet pas de remplir du texte librement.

Je me pose la question du coup si la solution à privilégier est de doubler toutes les colonnes du formulaire ? Ou alors d’avoir un bouton d’action qui sert à remplir les autres tables ?

Je suis preneuse de vos retours d’expériences :wink:

8

c’est le champ texte que tu dois utiliser pour ton formulaire dans ma solution

9

Autant pour moi, j’avais un souci lors de la soumission du formulaire qui bloquait et je pensais que c’était à cause de la formule mais en fait c’était lié à des règles d’accès :upside_down_face: