Créer des relations entre les listes de données

Dans Kis, les données sont organisées dans des listes : adhérents, structures, projets, tâches, inscriptions, factures, etc.

Les relations permettent de relier les informations entre plusieurs listes, sans avoir à recopier les mêmes données partout.

Comprendre les relations entre les listes
de données

Pour comprendre le concept de relation entre des listes de données, prenons un exemple simple avec deux listes :

• adherents ;
• inscriptions

Un adhérent peut avoir plusieurs inscriptions.

• Dans la liste adherents :

• Dans la liste inscriptions :

Ici, le champ "adherent_id = 12345" de la liste "inscriptions", similaire au champ "_id" de la liste "adherents" permet donc de relier l’inscription à Julie Martin.

Où trouver la clé primaire dans Kis ?

Chaque ligne d’une liste Kis possède une clé primaire unique, stockée dans la colonne _id.

Les trois dernières colonnes techniques d’une liste, qui apparaissent obligatoirement, sont toujours :

• _id : identifiant unique de la ligne ;
• c_at : date de création (created at) ;
• u_at : date de dernière mise à jour (updated at).

La colonne _id est donc la première affichée après les champs que vous avez créé dans votre liste.

Utiliser _id est souvent recommandé,
mais pas obligatoire

La clé _id est souvent la solution la plus fiable pour relier deux listes car elle identifie une ligne de façon unique.

Mais ce n’est pas une obligation.

Une relation peut aussi s’appuyer sur une autre valeur commune, par exemple :

• un numéro d’adhérent ;
• un SIREN ;
• une référence de dossier ;
• un numéro de commande ;
• une adresse e-mail ;
• une référence provenant d’un autre logiciel.

Exemple fréquent : la relation « un vers plusieurs »

Prenons un cas d'usage fréquent avec une structure qui est amenée à gérer plusieurs contacts.

Dans ce cas, on peut imaginer une liste de données "contacts" qui contient une colonne "structure_id".

On peut suivre la même logique pour :

• 1 projet → plusieurs tâches ;
• 1 convention → plusieurs appels de fonds ;
• 1 adhérent → plusieurs inscriptions ;
• 1 donateur → plusieurs dons.

En général, la référence vers l’élément principal est stockée dans la liste située du côté « plusieurs ».

Remplir automatiquement la relation
avec un formulaire

Il n’est pas nécessaire de demander à l’utilisateur de renseigner lui-même l’identifiant.

Reprenons l'exemple les deux listes "adherents" et "inscriptions" (qui comporte une colonne "adherent_id").

Depuis la fiche d’un adhérent, l’utilisateur clique sur « Ajouter une inscription » pour inscrire l'adhérent en question à un événement.

Dans le formulaire de création de l’inscription, on peut ajouter un champ invisible visant à récupérer le _id de l’adhérent depuis lequel le formulaire a été ouvert.

Pour ce faire, dans la "Valeur par défaut" du champ invisible, on renseigne la balise [data_in: _id].

De cette manière, l'inscription va être automatiquement reliée à l’adhérent.

Cette astuce permet de créer des parcours très simples pour l’utilisateur, par exemple :

• « Ajouter une tâche à ce projet »
• « Ajouter un contact à cette structure »
• « Ajouter un appel de fonds à cette convention »

Et l’utilisateur n’a pas besoin de comprendre ou de manipuler les identifiants.

Les listes intermédiaires

Parfois, la relation entre les listes peut se montrer plus complexe. Par exemple :

• un don peut financer plusieurs projets ;
• un projet peut recevoir plusieurs dons.

Dans ce cas de figure, on peut alors créer une liste intermédiaire, par exemple "affectations", contenant les colonnes :

• don_id ;
• projet_id ;
• montant

La liste intermédiaire permet à la fois de relier les deux listes et de stocker des informations propres à cette relation.

À retenir

• Une liste = un type de donnée métier.
• Une ligne = un enregistrement unique.
• _id = la clé primaire de la ligne.
• Une relation = une valeur commune permettant de relier deux données.
• Le _id est souvent utilisé, mais ce n’est pas obligatoire.
• Le formulaire peut transmettre automatiquement le _id dans un champ invisible, afin de créer la relation, sans aucune action supplémentaire pour l’utilisateur.