[SPIP Zone] Catalogue / Comptes & Contacts / Transactions

Archives Zone
1

(Désolé pour le post erroné sur spip-dev... dont je reprends le corps ci- après :slight_smile:

Je travaille sur un groupe de 4 plugins qui ont vocation à fonctionner ensemble et traiter la plupart des besoins d'un CRM, d'une boutique, d'un système d'inscription en ligne...

    1. plugin "catalogue" => ajoute aux articles SPIP des caractéristiques de produit : prix, TVA applicable, variantes, options... (fruit des besoins pour plusieurs dossiers, et d'échanges avec RealET).
    2. plugin "comptes & contacts" => ajoute aux auteurs SPIP des caractéristiques 1 à 1, soit de contact (date naissance, nom, prénom) soit de compte (SIRET, N°TVA), et des cartactériques 1 à n dans des tables spécifiques : adresses, numéros, emails... (fruit de partage d'infos besoin et de brainstorm avec xdjuj)
    3. plugin "transactions" => relie des articles à des auteurs dans le cadre de transactions; ça aurait pu s'appeler "panier" mais le terme transaction me semblait plus générique... sert de manière indiférenciée pour des inscriptions, des réservations, des achats...
    4. plugin "paiement" => pas commencé; mais gèrera le paiement d'une transaction...

Et réponses de Cédric (à propos de transactions) :

alors oui, un terme comme panier serait plus adapté.
Car la "transaction" implique un échange (monétaire contre un produit dans le cas qui nous intéresse).
Cela fait l'objet d'un plugin dont j'ai déjà préparé un gros morceau, qui prend justement en charge la gestion des transactions financières, opérateurs financiers inclus.

=> voir la suite du post

Et de RastaPopoulos :

Moi j'ai rien d'autre à dire que ça a l'air intéressant tout ça (car beaucoup plus générique qu'un gros plugin tout-en-un)... Je vois juste pas pourquoi ce message est sur la liste de développement du noyau de SPIP, et pas sur celle concernant les plugins. Je pense qu'il faudrait déplacer la suite de la conversation sur [spip-zone].

=> fait :slight_smile:

Cyril

2

Cyril MARION a écrit :

Et réponses de Cédric (à propos de transactions) :

alors oui, un terme comme panier serait plus adapté.
Car la "transaction" implique un échange (monétaire contre un produit dans le cas qui nous intéresse).

C'est vrai, "transaction" devrait être réservé lorsqu'il y a échange, négociation.
Mais "panier" aussi, est assez employé dans les boutiques.

Le bon terme devrait être utilisable dans les cas suivants :

- réservation d'une place de camping : une personne (id_auteur) intéressée par un "produit" (type d'hébergement, durée du séjour, période)
- réservation d'une séance de spectacle : un id_auteur intéressé par le spectacle du jeudi
- inscriptions à des conférences : un id_auteur intéressé par une entrée à 20€ pour la conf du 20 février
- à des réservations de voyage : sélection d'une ville de départ et d'une durée de séjour

et bien entendu :
- à des paniers d'achat : un id_user achète 3 tee-shirt bleus en taille XL

Le terme serait le "facteur commun" entre un panier, une inscription, une sélection, une réservation, une souscription, une transaction, un achat...
bref, bref un élément prenant en compte à la fois :
- une personne, qui choisit
- une chose, à
- une date

Alors, spip_paniers ? spip_transactions ? spip_sélections ?

Cela fait l'objet d'un plugin dont j'ai déjà préparé un gros morceau, qui prend justement en charge la gestion des transactions financières, opérateurs financiers inclus.

Ce plugin en préparation, gère t'il les "personnes" et les "produits" ? Si c'est le cas j'ai bien fait de poser la question avant d'aller trop loin dans le développement de Comptes et Contacts, et de Catalogue...
Si ce n'est pas le cas, y aurait il des parties à mettre en commun entre tous ces plugins ?

3

S'lt

C'est vrai, "transaction" devrait être réservé lorsqu'il y a échange,
négociation.
Mais "panier" aussi, est assez employé dans les boutiques.

Le bon terme devrait être utilisable dans les cas suivants :

- réservation d'une place de camping : une personne (id_auteur) intéressée
par un "produit" (type d'hébergement, durée du séjour, période)
- réservation d'une séance de spectacle : un id_auteur intéressé par le
spectacle du jeudi
- inscriptions à des conférences : un id_auteur intéressé par une entrée à
20€ pour la conf du 20 février
- à des réservations de voyage : sélection d'une ville de départ et d'une
durée de séjour

et bien entendu :
- à des paniers d'achat : un id_user achète 3 tee-shirt bleus en taille XL

Le terme serait le "facteur commun" entre un panier, une inscription, une
sélection, une réservation, une souscription, une transaction, un achat...
bref, bref un élément prenant en compte à la fois :
- une personne, qui choisit
- une chose, à
- une date

Alors, spip_paniers ? spip_transactions ? spip_sélections ?

spip_commande ? Le dénominateur commun c'est de commander un produit
matériel ou non.

Et bien sur je m'abstiens de troller sur I2 :slight_smile: mais pour autant il
faudrait trouver un moyen de faire converger toutes ses solutions
d'élargissement des auteurs.

Km

4

* Cyril MARION tapuscrivait, le 18/01/2010 15:43:

bref, bref un élément prenant en compte à la fois :
- une personne, qui choisit
- une chose, à
- une date

contrat

Et ce contrat sera ou non signé.

--
RealET

5

cam.lafit@azerttyu.net a écrit :

spip_commande ? Le dénominateur commun c'est de commander un produit
matériel ou non.

et bien... la "commande" me semble être plutôt un type de contrat commercial... je pense que ça vient "après" la transaction
l'utilisateur choisit un/des article/s : c'est le panier
il valide son panier : c'est la commande
il paye : c'est la transaction

Une réservation de place de camping, c'est peut-être pas encore un commande ? de même qu'une inscription à une conférence ? la commande est vraiment un acte commercial.

Plus j'y pense et plus le terme de "panier" pourrait convenir, non ?
spip_paniers... pas mal

Et spip_transactions on le réserve pour la phase d'après (validation de panier), à moins que le plugin démarré par Cédric ne vienne carrément remplacer panier + transaction ?

Et bien sur je m'abstiens de troller sur I2 :slight_smile: mais pour autant il
faudrait trouver un moyen de faire converger toutes ses solutions
d'élargissement des auteurs.

Oui, d'où mon message ici :wink:
Si I2 gérait mes fameuses tables 1-n (emails, adresses, numéros,etc.) en dehors de la table spip_auteurs_elargis, je ne serais pas parti dans la direction d'un nouveau plugin. Mais dans aucun des cas de gestion de personnes que j'ai eu à traiter, I2 ne pouvait convenir.

De plus, du fait de l'ancienneté de I2 et donc du nombre de plugins qui l'utilisent, je ne sais pas si c'est vraiment facile de le faire évoluer dans le sens d'avoir plusieurs tables 1-n.

I2 pourquoi pas mais :
- pas de tables 1-n en dehors de la table principale (si, il y en a une : la table spip_geo_pays)
- pas de possibilité de gérer des ensembles de personnes avec l'authentification SPIP (pas de relations auteur/auteur)

Dites moi si je me trompe à propos de I2 ?
Et en plus, le nom "inscription" ne reflète pas vraiment la fonction 1èer qui est de gérer des personnes (finalement, des comptes et des contacts)...

6

Le 18/01/2010 16:16, Cyril MARION a écrit :

Plus j'y pense et plus le terme de "panier" pourrait convenir, non ?
spip_paniers... pas mal

Oui. On met dans un panier des choses que l'on veut. Peu importe qu'il faille payer ou pas ensuite. On choisit juste une ou plusieurs choses qu'on regroupe ensemble.

Et spip_transactions on le réserve pour la phase d'après (validation de
panier), à moins que le plugin démarré par Cédric ne vienne carrément
remplacer panier + transaction ?

Non je ne pense pas. D'après ce que j'avais compris, le plugin de Cédric sert à payer. Pour faire rapide, un montant, un prestataire de payement, et hop.

- pas de possibilité de gérer des ensembles de personnes avec
l'authentification SPIP (pas de relations auteur/auteur)

Gérer des ensemble de personnes, ya un plugin Groupes pour ça non ?

--
RastaPopoulos

7

Le 18 janv. 2010 à 16:30, RastaPopoulos a écrit :

Le 18/01/2010 16:16, Cyril MARION a écrit :

Plus j'y pense et plus le terme de "panier" pourrait convenir, non ?
spip_paniers... pas mal

Oui. On met dans un panier des choses que l'on veut. Peu importe qu'il faille payer ou pas ensuite. On choisit juste une ou plusieurs choses qu'on regroupe ensemble.

Et spip_transactions on le réserve pour la phase d'après (validation de
panier), à moins que le plugin démarré par Cédric ne vienne carrément
remplacer panier + transaction ?

Non je ne pense pas. D'après ce que j'avais compris, le plugin de Cédric sert à payer. Pour faire rapide, un montant, un prestataire de payement, et hop.

voilà, mon plugin fournit une API pour demander le paiement d'une vente.
Il permet de créer une transaction (qui est l'objet de base) basée sur un montant et un client, à l'état commande, de générer le formulaire de paiement mono ou multi prestataire, de gérer la réponse du prestataire choisi, et selon le résultat du paiement, de changer l'état de la transaction vers OK ou refusée.
Lorsque le paiement est OK, il déclenche des appels de pipeline permettant d'éditer une facture (non pris en charge dans ce plugin) et de livrer les produits (non pris en charge).

Bref, le plugin ne fait que gérer la transaction financière.

Cédric

8

Moi je vote vraiment pour panier, ça me semble vraiment le plus générique ! :slight_smile:

=> Un panier est un récipient tressé rigide servant à contenir et à transporter des objets divers (exemple : panier à linge)

Le 18 janv. 10 à 16:30, RastaPopoulos a écrit :

Le 18/01/2010 16:16, Cyril MARION a écrit :

Plus j'y pense et plus le terme de "panier" pourrait convenir, non ?
spip_paniers... pas mal

Oui. On met dans un panier des choses que l'on veut. Peu importe qu'il faille payer ou pas ensuite. On choisit juste une ou plusieurs choses qu'on regroupe ensemble.

Et spip_transactions on le réserve pour la phase d'après (validation de
panier), à moins que le plugin démarré par Cédric ne vienne carrément
remplacer panier + transaction ?

Non je ne pense pas. D'après ce que j'avais compris, le plugin de Cédric sert à payer. Pour faire rapide, un montant, un prestataire de payement, et hop.

- pas de possibilité de gérer des ensembles de personnes avec
l'authentification SPIP (pas de relations auteur/auteur)

Gérer des ensemble de personnes, ya un plugin Groupes pour ça non ?
Connexion · GitLab

--
RastaPopoulos

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

9

RealET a écrit :

contrat

Et ce contrat sera ou non signé.

une personne -> choisit n choses
sans forcément qu'il y ait :
- ni négociation (donc transaction)
- ni contrat

ce qui me fait pencher fortement pour "paniers"...
et rejoint en celà l'avis de Rastapopoulos et celui de Xdjuj.

"transactions" est le nom des objets manipulés par le plugin de Cedric

10

cedric.morin@yterium.com a écrit :

voilà, mon plugin fournit une API pour demander le paiement d'une vente.
Il permet de créer une transaction (qui est l'objet de base) basée sur un montant et un client, à l'état commande, de générer le formulaire de paiement mono ou multi prestataire, de gérer la réponse du prestataire choisi, et selon le résultat du paiement, de changer l'état de la transaction vers OK ou refusée.
Lorsque le paiement est OK, il déclenche des appels de pipeline permettant d'éditer une facture (non pris en charge dans ce plugin) et de livrer les produits (non pris en charge).

Bref, le plugin ne fait que gérer la transaction financière.

Cédric

Bon, tout ça me semble s'imbriquer parfaitement ! Ah, la magie de SPIP !

en conclusion :

- plugins "Catalogue" et "Comptes & Contacts" : pour gérer des choses et des personnes

- plugin "Paniers" pour gérer des choix qu'effectuent des personnes (Contacts) parmi des choses (articles de Catalogue) à une certaine date

- le plugin de Cédric pour effectuer le paiement des Paniers...

Go go go !

Cyril

11

Yop,

Puisque je reconnais certaines questions, je me permet de poster... :stuck_out_tongue:

Le 18 janv. 10 à 15:05, Cyril MARION a écrit :

(Désolé pour le post erroné sur spip-dev... dont je reprends le corps ci- après :slight_smile:

Je travaille sur un groupe de 4 plugins qui ont vocation à fonctionner ensemble et traiter la plupart des besoins d'un CRM, d'une boutique, d'un système d'inscription en ligne...

  1. plugin "catalogue" => ajoute aux articles SPIP des caractéristiques de produit : prix, TVA applicable, variantes, options... (fruit des besoins pour plusieurs dossiers, et d'échanges avec RealET).

Pour moi catalogue est un ensemble de produits. Donc une question : ce plugin gère des articles-produits uniquement ou permet-il aussi de regrouper ces articles-produits en divers catalogues ? Si non, Produits serait plus approprié non ?

  2. plugin "comptes & contacts" => ajoute aux auteurs SPIP des caractéristiques 1 à 1, soit de contact (date naissance, nom, prénom) soit de compte (SIRET, N°TVA), et des cartactériques 1 à n dans des tables spécifiques : adresses, numéros, emails... (fruit de partage d'infos besoin et de brainstorm avec xdjuj)

Là j'ai deux remarques:
1) pourquoi il n'est pas possible de faire évoluer le plugin inscription ou tout autre plugin qui étend la notion d'auteur ?
2) si non, qu'est ce exactement qu'un compte et un contact par rapport à un auteur ? je vois pas bien la portée de ces notions.

  3. plugin "transactions" => relie des articles à des auteurs dans le cadre de transactions; ça aurait pu s'appeler "panier" mais le terme transaction me semblait plus générique... sert de manière indiférenciée pour des inscriptions, des réservations, des achats...

Ca m'a l'air hyper générique comme concept. C'est une association entre produits et comptes ?

  4. plugin "paiement" => pas commencé; mais gèrera le paiement d'une transaction...

Euh on paye pas une transaction non ? Mais bon puisque ça devient un panier :wink:

Eric

12

Eric Lupinacci a écrit :

Puisque je reconnais certaines questions, je me permet de poster... :stuck_out_tongue:

Pour moi catalogue est un ensemble de produits. Donc une question : ce plugin gère des articles-produits uniquement ou permet-il aussi de regrouper ces articles-produits en divers catalogues ? Si non, Produits serait plus approprié non ?

Oui, catalogue permet de regrouper des produits, puisque l'idée était d'utiliser les possibilités de regroupement natives des articles SPIP : mots-clé et/ou rubriques. Il s'agit d'une extension des articles.

Les nouveaux objets de Catalogue sont des "variantes", que l'on ajoute à un article SPIP exactement comme on rajoute un/des évènements à un article avec Agenda.

Là j'ai deux remarques:
1) pourquoi il n'est pas possible de faire évoluer le plugin inscription ou tout autre plugin qui étend la notion d'auteur ?

Oui, on pourrait; cependant vu le nombre de plugins qui utilisent déjà I2, ça me semblait délicat - mais je peux me tromper - d'assurer une compatibilité ascendante;

2) si non, qu'est ce exactement qu'un compte et un contact par rapport à un auteur ? je vois pas bien la portée de ces notions.

Contact = 1 personne
Compte = 1 groupe de personnes

Je me suis basé sur la définition des hcards; un même conteneur hcard peut être soit une personne soit un groupe (un contact ou un compte); j'ai repris le termes comptes et contacts par analogie avec les termes anglais account & contacts que l'on trouve dans la majorité des CRMs.

Je me suis inspiré aussi de la gestion des utilisateurs/groupes qu'un spip-dev(1) utilise dans un de ses derniers plugins : un auteur SPIP peut être soit une personne, soit un groupe (un groupe d'utilisateurs partageant le même login/pass SPIP).

En conséquence l'élément de base que l'on conserve est l'auteur SPIP; Comptes & Contacts permet d'étendre la table spip_auteurs avec 2 tables 1-1 supplémentaires : spip_comptes et spip_contacts; ces 2 tables d'extension comportent uniquement des données uniques : prénom, date naissance, etc. pour contacts, SIRET, capital, etc. pour comptes.

ici, la différence avec I2 est que j'ai sorti toutes les infos qui pouvaient être multiples : adresses, numéros, emails, etc. Ces informations 1-n pouvant être attribuées aussi bien à un compte (adresse de livraison, facturation) qu'à un auteur (adresse perso, boulot, etc.). Elles sont stockées dans les tables spip_adresses, spip_numeros, etc. Ces tables 1-n sont liées aux 2 tables spip_comptes et spip_contacts par des tables de liaison, sur le même principe que spip_documents_liens.

Dernière chose, les contacts sont liés aux comptes par une table spip_comptes_contacts, sachant qu'un contact peut être lié à plusieurs comptes : une personne peut être membre de 2 assoces et travailler pour un 3è.

La partie privée est encore dans les limbes, mais l'idée est de pouvoir transformer un spip_auteur en Contact (ajouter prénom...) ou en Compte (ajouter un N° SIRET), puis de lui ajouter autant d'adresses, numéros, adresses mail que l'on souhaite (à la manière du carnet d'adresse de mac OSX).

Ca m'a l'air hyper générique comme concept. C'est une association entre produits et comptes ?

oui, exactement : une liste d'articles, sélectionnés par une personne, à un moment donné.

Euh on paye pas une transaction non ? Mais bon puisque ça devient un panier :wink:

Oui, mais ça peut venir en dernier. Du moment que l'ensemble soit constitué de briques assemblables entr'elles.

Merci pour votre attention,
Cyril

(1) xdjuj :wink:

13

Mais comment comparer avec ce qui existe dans spip-thelia ?

En tout cas ç'a m'apparaît clair et j'ai hâte de voir.
(quand ça ?)

JLuc

Le 19/01/2010 08:36, Cyril MARION a écrit :

Oui, catalogue permet de regrouper des produits, puisque l'idée était
d'utiliser les possibilités de regroupement natives des articles SPIP :
mots-clé et/ou rubriques. Il s'agit d'une extension des articles.
Les nouveaux objets de Catalogue sont des "variantes", que l'on ajoute à
un article SPIP exactement comme on rajoute un/des évènements à un
article avec Agenda.

Là j'ai deux remarques:
1) pourquoi il n'est pas possible de faire évoluer le plugin
inscription ou tout autre plugin qui étend la notion d'auteur ?

Oui, on pourrait; cependant vu le nombre de plugins qui utilisent déjà
I2, ça me semblait délicat - mais je peux me tromper - d'assurer une
compatibilité ascendante;

2) si non, qu'est ce exactement qu'un compte et un contact par rapport
à un auteur ? je vois pas bien la portée de ces notions.

Contact = 1 personne
Compte = 1 groupe de personnes

Je me suis basé sur la définition des hcards; un même conteneur hcard
peut être soit une personne soit un groupe (un contact ou un compte);
j'ai repris le termes comptes et contacts par analogie avec les termes
anglais account & contacts que l'on trouve dans la majorité des CRMs.

Je me suis inspiré aussi de la gestion des utilisateurs/groupes qu'un
spip-dev(1) utilise dans un de ses derniers plugins : un auteur SPIP
peut être soit une personne, soit un groupe (un groupe d'utilisateurs
partageant le même login/pass SPIP).

En conséquence l'élément de base que l'on conserve est l'auteur SPIP;
Comptes & Contacts permet d'étendre la table spip_auteurs avec 2 tables
1-1 supplémentaires : spip_comptes et spip_contacts; ces 2 tables
d'extension comportent uniquement des données uniques : prénom, date
naissance, etc. pour contacts, SIRET, capital, etc. pour comptes.

ici, la différence avec I2 est que j'ai sorti toutes les infos qui
pouvaient être multiples : adresses, numéros, emails, etc. Ces
informations 1-n pouvant être attribuées aussi bien à un compte (adresse
de livraison, facturation) qu'à un auteur (adresse perso, boulot, etc.).
Elles sont stockées dans les tables spip_adresses, spip_numeros, etc.
Ces tables 1-n sont liées aux 2 tables spip_comptes et spip_contacts par
des tables de liaison, sur le même principe que spip_documents_liens.

Dernière chose, les contacts sont liés aux comptes par une table
spip_comptes_contacts, sachant qu'un contact peut être lié à plusieurs
comptes : une personne peut être membre de 2 assoces et travailler pour
un 3è.

La partie privée est encore dans les limbes, mais l'idée est de pouvoir
transformer un spip_auteur en Contact (ajouter prénom...) ou en Compte
(ajouter un N° SIRET), puis de lui ajouter autant d'adresses, numéros,
adresses mail que l'on souhaite (à la manière du carnet d'adresse de mac
OSX).

Ca m'a l'air hyper générique comme concept. C'est une association
entre produits et comptes ?

oui, exactement : une liste d'articles, sélectionnés par une personne, à
un moment donné.

Euh on paye pas une transaction non ? Mais bon puisque ça devient un
panier :wink:

Oui, mais ça peut venir en dernier. Du moment que l'ensemble soit
constitué de briques assemblables entr'elles.

Merci pour votre attention,
Cyril

(1) xdjuj :wink:

14

Je pense que ça n'est pas comparable dans le sens où l'on parle de plusieurs plugins qui liés, peuvent former une solution de "commerce" (comme Thélia) sauf qu'on n'est pas obligé (alors que Thélia n'a que cette vocacation non ?)

D'ailleurs pour utiliser SPIP Thélia il faut tout déployer les fichiers de thélia en plein dans la hiérarchie de SPIP non ? (créant un bronx sans nom)

Est-ce qu'on peut vraiment considérer que SPIP Thélia est un plugin alors qu'il n'est pas autonome ?

Le 19 janv. 10 à 10:29, JLuc a écrit :

Mais comment comparer avec ce qui existe dans spip-thelia ?

En tout cas ç'a m'apparaît clair et j'ai hâte de voir.
(quand ça ?)

JLuc

Le 19/01/2010 08:36, Cyril MARION a écrit :

Oui, catalogue permet de regrouper des produits, puisque l'idée était
d'utiliser les possibilités de regroupement natives des articles SPIP :
mots-clé et/ou rubriques. Il s'agit d'une extension des articles.
Les nouveaux objets de Catalogue sont des "variantes", que l'on ajoute à
un article SPIP exactement comme on rajoute un/des évènements à un
article avec Agenda.

Là j'ai deux remarques:
1) pourquoi il n'est pas possible de faire évoluer le plugin
inscription ou tout autre plugin qui étend la notion d'auteur ?

Oui, on pourrait; cependant vu le nombre de plugins qui utilisent déjà
I2, ça me semblait délicat - mais je peux me tromper - d'assurer une
compatibilité ascendante;

2) si non, qu'est ce exactement qu'un compte et un contact par rapport
à un auteur ? je vois pas bien la portée de ces notions.

Contact = 1 personne
Compte = 1 groupe de personnes

Je me suis basé sur la définition des hcards; un même conteneur hcard
peut être soit une personne soit un groupe (un contact ou un compte);
j'ai repris le termes comptes et contacts par analogie avec les termes
anglais account & contacts que l'on trouve dans la majorité des CRMs.

Je me suis inspiré aussi de la gestion des utilisateurs/groupes qu'un
spip-dev(1) utilise dans un de ses derniers plugins : un auteur SPIP
peut être soit une personne, soit un groupe (un groupe d'utilisateurs
partageant le même login/pass SPIP).

En conséquence l'élément de base que l'on conserve est l'auteur SPIP;
Comptes & Contacts permet d'étendre la table spip_auteurs avec 2 tables
1-1 supplémentaires : spip_comptes et spip_contacts; ces 2 tables
d'extension comportent uniquement des données uniques : prénom, date
naissance, etc. pour contacts, SIRET, capital, etc. pour comptes.

ici, la différence avec I2 est que j'ai sorti toutes les infos qui
pouvaient être multiples : adresses, numéros, emails, etc. Ces
informations 1-n pouvant être attribuées aussi bien à un compte (adresse
de livraison, facturation) qu'à un auteur (adresse perso, boulot, etc.).
Elles sont stockées dans les tables spip_adresses, spip_numeros, etc.
Ces tables 1-n sont liées aux 2 tables spip_comptes et spip_contacts par
des tables de liaison, sur le même principe que spip_documents_liens.

Dernière chose, les contacts sont liés aux comptes par une table
spip_comptes_contacts, sachant qu'un contact peut être lié à plusieurs
comptes : une personne peut être membre de 2 assoces et travailler pour
un 3è.

La partie privée est encore dans les limbes, mais l'idée est de pouvoir
transformer un spip_auteur en Contact (ajouter prénom...) ou en Compte
(ajouter un N° SIRET), puis de lui ajouter autant d'adresses, numéros,
adresses mail que l'on souhaite (à la manière du carnet d'adresse de mac
OSX).

Ca m'a l'air hyper générique comme concept. C'est une association
entre produits et comptes ?

oui, exactement : une liste d'articles, sélectionnés par une personne, à
un moment donné.

Euh on paye pas une transaction non ? Mais bon puisque ça devient un
panier :wink:

Oui, mais ça peut venir en dernier. Du moment que l'ensemble soit
constitué de briques assemblables entr'elles.

Merci pour votre attention,
Cyril

(1) xdjuj :wink:

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

15

Le 19/01/2010 17:00, XDjuj a écrit :

Je pense que ça n'est pas comparable dans le sens où l'on parle de
plusieurs plugins qui liés, peuvent former une solution de "commerce"
(comme Thélia) sauf qu'on n'est pas obligé (alors que Thélia n'a que
cette vocacation non ?)

Oui c'est préférable si c'est modulaire.
C'est l'aspect massif de I2 qui m'avait dissuadé de l'utiliser,
car avec le relatif manque de documentation, ça paraissait trop inmaitrisable.
ça fait beaucoup de ressources dispersées quand même !
donc je fais le voeux (2010) que les énergies se concentreront suffisamment,
ici ou là, pour que les plugins soient bien conçus adaptables et communicants,
et surtout documentés et stables ! :slight_smile:

A part ça, en étendant la table Auteurs avec une autre ayant le champ prénom,
comment gères tu le champ nom existant ?
Car dans SPIP, du fait de l'absence de champ prénom en standard,
le champ nom contient souvent les 2 !
Sur un site déjà existant, ça perturbe un peu...

Bonne continuation,
JLuc

16

JLuc a écrit :

A part ça, en étendant la table Auteurs avec une autre ayant le champ prénom,
comment gères tu le champ nom existant ?
Car dans SPIP, du fait de l'absence de champ prénom en standard,
le champ nom contient souvent les 2 !
Sur un site déjà existant, ça perturbe un peu...

je ne vois pas où le champ nom de spip_auteurs pourrait poser problème... il reste comme il est, il est juste "précisé" par un découpage nom de famille / prénom pour un "contact" (ou nom de l'entreprise ou de l'assoce, ou de l'institution pour un "compte")

Sur un site existant, si le plugin Comptes & Contacts est installé, c'est qu'il a des chances qu'une gestion fine nom/prénom soit souhaitée; dans ce cas il faudra à un moment ou un autre remplir les 2 champs.

A propos de concentration, la réflexion entamée avec C&C peut être un jour rebasculée vers I2, ça ne pose aucun problème.