Bonjour,
J'ai simplement essayé la démo en ligne, et je n'ai pas trouvé la façon de définir une nouvelle relation.
Où est-ce que c'est ?
Par exemple, si je souhaite créer une relation "a organisé un évènement avec".
Cette relation est symétrique (si X "a organisé un évènement avec" Y, l'inverse est également vrai).
Est-ce qu'il est possible de spécifier sur les relations sont symétriques ou non ?
Par exemple, "X a été intervenant dans un évènement organisé par Y" n'est pas symétrique.
Merci
Olivier FAURAX
Citation :J'ai simplement essayé la démo en ligne, et je n'ai pas trouvé la façon de définir une nouvelle relation.
Où est-ce que c'est ?
Ce n'est pas disponible dans la démo (l'utilisateur 'démo' n'a en fait pas les droits suffisants) ; ceci afin que les gens ne puissent pas mettre la configurations (des blocs notamment) totalement en vrac. Nous devons déjà nettoyer de temps en temps les tests des gens, qui mettent par exemple tous les éléments du menu dans le menu rapide (ce qui n'a aucun intérêt évidemment et rend très moche) ; s'ils pouvaient toucher la configuration des blocs ça serait un carnage !
Il y a dans la documentation présente dans les source ( https://bitbucket.org/hybird/creme_crm/ ... at=default ) un fichier "Administration - Relations et propriétés.pdf" où on voit la page de configuration des types de relations. En revanche on ne voit pas le formulaire de création d'une nouvelle relation ; j'en parlerait à mon acolyte.
Citation :Par exemple, si je souhaite créer une relation "a organisé un évènement avec".
Cette relation est symétrique (si X "a organisé un évènement avec" Y, l'inverse est également vrai).
Est-ce qu'il est possible de spécifier sur les relations sont symétriques ou non ?
Par exemple, "X a été intervenant dans un évènement organisé par Y" n'est pas symétrique.
Lorsqu'on créé un type de relation, il y a toujours la relation symétrique qui l'accompagne. Dans votre exemple, il y aurait un couple "a organisé"/"a été organisé par" et un couple "a été intervenant"/"a eu pour intervenant", que l'on pourrait établir entre un Contact/Société et un Événement, Lorsque une relation est créé entre X et Y, la relation symétrique est automatiquement créée avec le type symétrique.
On peut créer un type de relation et son symétrique avec la même étiquette/prédicat (ex: "a organisé avec"/"a organisé avec"), mais c'est une très mauvaise idée à l'heure actuelle, car pour être sûr de récupérer tous les co-organisateurs (dans votre exemple), il faudrait récupérer les entités liées par les relations des 2 types (avec le même prédicat donc, ce qui est 'confusant').
En gros, j'ai l'impression que vous voulez savoir si un type de relation peut être son propre symétrique (dans la nomenclature Creme) : la réponse est non. Mais l'idée est très intéressante ; je ne sais pas si en pratique nous avons déjà rencontré des cas où cela aurait été utile, mais l'exemple que vous donnez est plutôt sympathique. Il faudrait quand même réfléchir aux potentiels problèmes que cela soulèverait (je n'en vois pas là tout de suite, mais le diable se cache dans les détails), et voir aussi si des utilisateurs en ont réellement besoin (que c'est n'est pas que théorique).
Bonne soirée Olivier !
Hello Olivier !
Alors concernant ta question sur les relations et un type symétrique potentiel, une petite contribution à la question.
Pragmatiquement, et me basant sur les quelques fois ou une question est apparus chez des clients, j'ai envie de dire que c'est quasiment toujours un 'faux' besoin. Pour ton exemple par exemple, au final, savoir que quelqu'un a organisé un truc avec quelqu'un d'autre, ce n'est pas très utile au final pour une utilisation future. Ici il manquerait clairement une chose à savoir qu'est ce qui a été organisé. Du coup, on ne pourrait pas retrouver simplement tout les organisateurs d'un unique événement.
En plus si on a 3 contacts, A, B et C, que l'on part sur une relation symétrique, que A est relié à B , B relié à C , et A à C on ne sait pas si A, B et C ont organisés ensemble un même événement ou si A et B ont organisé un événement E1 et A et C un autre event E2.
Au lieu d'avoir une seule relation symétrique entre 2 personnes, on se retrouve alors avec une relation entre une activité par exemple (ou une action co ou un événement) et des contacts. Ici on sait donc qui sont les organisateurs des choses, de quelles choses précisément, etc ... En terme de modélisation c'est bien bien mieux.
Tu vas me rétorquer, si tu as regardé la liste de relation de Crème, qu'il existe pourtant dans Crème une relation qui pourrait être symétrique. La relation de partenariat. Et c'est vrai. A priori être partenaire c'est une relation totalement symétrique. Dans Crème, au moment de l'inclusion de cette relation, il a été décidé de la modéliser comme une relation classique avec deux prédicats artificiellement différent (est un partenaire de / a pour partenaire ). [on pourrait toujours argumenter qu'on peut donner un sens légèrement différent au deux prédicats , du type ' le sens est un partenaire ' est celui de l'initiateur du partenariat, mais ce ne serait que de l'ergotage ].
La décision a été prise de ne pas rajouter une notion (relation symétrique ou pas) qui n'est utile que dans très peu de cas [aujourd'hui j'ai 2 exemples de l'utilité potentielle de la chose, la relation partenaire et la relation non sémantique (et que l'on déconseille totalement d'utiliser 'est relié à / est relié à ) ] afin de ne augmenter encore un peu plus la barrière à l'entrée de l'utilisation (et de la compréhension) par les utilisateurs du mécanisme des relations.
[En plus, ne pas avoir la possibilité d'avoir des relations symétriques force les utilisateurs à réfléchir sur leur modèle de relation, et à transformer les relations symétrique en des relations non symétriques, souvent bien plus porteuses de sens. D'ailleurs tu pourrais totalement (et tu aurais raison) m'indiquer que la relation de partenariat symétrique est une relation peu utile, parce qu'un partenariat, c'est la plupart du temps limité à une gamme produit, un projet de consorsium, un marché bien précis, etc .. et que là on perds cette info ... ]
OK, merci beaucoup 
Je pense que s'il y a une doc/tutorial, ça devrait être précisé qu'il faut modéliser son écosystème seulement avec des relations asymétriques.
Quel est la doc que vous conseillez pour commencer à prendre en main l'outil ?
Merci
Olivier
Je pense que je vais détailler les choses dans un prochain billet du mardi.
Concernant la prise en main, il y a déjà un certain nombre (pour ne pas dire un nombre certain) de procédures dans le répertoire doc du repository de Crème.
Ensuite, il y a les billets du mardi (le deuxième arrive d'ici peu, le temps de répondre ici et à quelques emails) qui vont j'espère éclairer différentes problématiques d'une manière plus précises (et qui permettra un échance). Pour rappel les billets du mardi se trouvent dans la sous partie CRM, théorie et utilisation
Bonjour,
Je suis débutante en Crème, je ne suis vraiment pas fan qu'il y ait des relations "faussement symétriques" (partenaire).
C'est celle que j'utilise le plus et cela m'a donné l'impression que les relations étaient mal ficelées.
En lisant votre réponse, je comprends que ce n'est pas le cas, que c'est un choix réfléchi, que seul "partenaire" est concerné, mais je voulais témoigner de ma première impression
Je n'ai pas encore exploité le potentiel des relations et je ne suis pas consciente de toutes les contraintes technique qui y sont associées.
Mais il y a peut-être une possibilité de rendre certaines relations "réciproques" plutôt que "symétriques" d'un point de vue utilisateur, sans changer toute la tringlerie derrière?
Bonjour,
Citation :Mais il y a peut-être une possibilité de rendre certaines relations "réciproques" plutôt que "symétriques" d'un point de vue utilisateur, sans changer toute la tringlerie derrière?
Je ne suis pas certain de que vous entendez par là.
Actuellement lorsqu'on crée un relation "est client de" entre A & B, une relation "est fournisseur de" est automatiquement créée entre B & A. Dans la nomenclature Creme on appelle ça des relations symétriques, mais le terme "réciproques" serait sûrement plus pertinent. Et le terme "symétrique" pourrait être réservé pour indiquer si un type de relation l'est, ou pas.
Je pense que techniquement il est possible d'ajouter cette notion de symétrie de manière relativement simple, sans devoir tout casser : lorsqu'un type de relation est marqué comme symétrique, il faudrait créer en plus de la relation réciproque (comme vu au dessus) 2 autres relations réciproque entre elles, et symétriques des 2 premières. Ces 3 relations créée automatiquement seraient marquées comme "fantôme" et ne serviraient qu'à faire des requêtes qui fonctionnent (ex: lorsqu'on cherche les fiches partenaires dans la vue de liste), mais ne seraient pas visibles (seule la 1ère l'est).
Reste que :
- Il faut quand même tester mon idée ci-dessus ; le diable se cache dans les détails, et aussi il est difficile d'être sûr que tout fonctionne bien sans l'implémenter. Dans tous les cas même s'il ne s'agit pas de tout casser, ça n'est pas totalement trivial non plus, et demanderait plusieurs jours/semaines de travail. Et donc ça rentre dans l'immense liste des fonctionnalités possibles -- sachant qu'on ne peut se permettre de ne faire que les plus utiles.
- Mon collègue au dessus avait même l'air de penser que c'était potentiellement une mauvaise idée de toutes les façons que d'avoir une telle fonctionnalité. je dirais qu'on n'a peut-être pas assez de cas concrets pour en décider.
|
