Principe :
Comme un certain nombre d’autres plugins jusque là, "Comptes & Contacts" ajoute des champs indispensables à la table spip_auteurs, dès qu’il s’agit de gérer des personnes d’une manière un peu poussée. La table spip_auteurs est par nature, et historiquement sans doute, limitée aux champs nécessaires pour la rédaction d’articles. Dès que cette table doit être utilisée pour d’autres fonctions (inscription, transaction, etc.) certaines caractéristiques lui font défaut, et parmi elles :
- prénom, date de naissance, autres informations personnelles
- notion de "groupes d’auteurs"
- plus de une adresse mail, plusieurs numéros de téléphone ou ID communautaires (ICQ, MSN)
- autres informations spécifiques à l’utilisation
Objectif
Lors du développement du plugin nous avons veillé à ce que la notion d’auteur SPIP soit conservée intégralement. Nous avons par exemple choisi de ne pas modifier la structure de la table. Ainsi nous avons ajouté seulement les tables nécessaires à l’ajout de propriétés.
Ce plugin est déjà utilisé par le plugin Catalogue, et le plugin SPIPMine est en cours de modifications pour intégrer Comptes & Contacts en lieu et place du système de gestion clients existant.
Nouvelles tables
Table spip_contacts
Il aurait sans doute été possible de ne pas créer de table contacts mais d’utiliser une table "champs" avec une liaison entre un champ et un auteur. Par exemple, pour ajouter le prénom "Georges" à l’auteur N°117, on aurait pu créer une table "spip_champs" avec un enregistrement de type :
- id_objet : 117
- objet : auteur
- id_champ : X
- type_champ : prenom
- valeur_champ : Georges
C’est un peu ce que fait le plugin "champs_extra_2" non ? Non, on me dit que c’est plutôt ce que fait le plugin"forms&tables"... OU peut être encore "inscription 2" ?
Bref ça me semble un peu compliqué pour quelques tables à gérer finement soi-même. F&T ne fait pas tout et ses formats de champ texte ne permettraient pas de gérer facilement les tris par exemple pour "agenda".
Néanmoins, pour simplifier et arriver plus rapidement à un résultat exploitable, nous avons décidé de créer une table "spip_contacts" dont voici la structure :
Nota 1 : il est très important de garder une clé d’index sur le champ id_auteur, ce qui permet de faire la liaison avec la table spip_auteurs et d’utiliser des boucles (AUTEURS) avec un champ de la table spip_contact en critère.
Nota 2 : voir si la liaison peut s’étendre à des critères issus de la table spip_coordonnees dans une boucle (AUTEURS). Oui => c’est faisable en positionnant les 3 tables dans la boucle, de la manière suivante :
Table spip_adresses
Permet d’ajouter des adresses de différents types : perso, pro, vacance...
On peut ajouter une "adresse" aussi bien à un contact... qu’a un compte. ce fonctionnement est inspiré du très adulé système de gestion des documents dans SPIP (et qui gagnerait à être étendu à la gestion des mots-clé...). En effet, il existe une seule table documents, puis une seule table de liaisons permettant des liaisons à n’importe quel objet SPIP.
Table spip_comptes
Cette table permet(tra) de gérer des groupes de contacts. En voici sa structure pour l’instant :
La liaison comptes / contacts n’est pas encore opérationnelle pour l’instant. Doit elle être gérée avec un champ id_compte dans la table contacts ? doit elle être gérée avec une table de liaisons comptes_contacts ? A réfléchir. Pour l’instant les 2 plugins en cours de développement utilisant "Comptes & Contacts" n’ont pas encore besoin de la notion de comptes (seulement de contacts).
Réflexions sur les développements futurs
On distingue a priori 3 types de données relatives aux personnes :
- 1. les données "personnelles", uniques et intemporelles : prénom, date de naissance, genre (civilité), etc. Ces données sont d’une manière générale uniques (on n’est né qu’une seule fois, et à une seule date...) et ne se modifieront pas dans le temps ; elles seront donc placées dans une table possédant une liaison 1 à 1 avec la table spip_auteurs. Cette table est la table spip_contacts.
- 2. les données "de contact" multiples et plus ou moins "universelles" : adresse postale, numéro de téléphone, adresse mail, identifiant ICQ... D’une manière générale ces infos peuvent être multipliées : 1 adresse perso + 1 adresse pro, 1 tel portable, 1 tel domicile et un tel bureau, 1 contact MSN et un autre ICQ... Elles seront donc stockées dans une ou plusieurs tables qui pourront être livrées telles quelles avec le plugin : une table spip_adresses, une table spip_numeros, une table spip_chat (?) chacune avec leur table de liaison permettant d’attribuer par exemple plusieurs numéros différents à une personne. Les liaisons son 1 à n (1 auteur à n adresses).
- 3. des données "spécifiques" à une application, et par définition volatile [1] : inscription, achat (?), participation à un congrès, une conférence... Ce sont ces données qui devront pouvoir être étendues facilement en fonction des besoins.
De base, le plugin fournira les données "personnelles" (uniques) et "de contact" (multiples). Des extensions possibles avec d’autres tables "spécifiques" sont possibles. Il ne restera plus qu’à gérer les formulaires avec ce formidable outil qu’est la méthode CVT.
Autres évolutions
Pour continuer sur la gestion des personnes, envisager l’évolution vers d’autres types de liens, p. exemple liens familiaux (ou d’amitié). Les liens de type CV sont la plupart du temps gérés avec un enregistrement de la table articles lié à l’auteur.
Plugin Comptes & Contacts
RSS 2.0