[WIP] Fix #3 : une fonction d'API commandes_client() avec un pipeline extensible éponyme #15

Open
rastapopoulos wants to merge 3 commits from dev/issue_3_api_infos into master
Owner

L'API doit retourner quelques informations importantes sur la clientèle d'une commande précise, dans des clés définies à l'avance.

Pour l'instant au moins nom, adresse_facturation, adresse_livraison. Dans les adresses les clés sont imposées aussi (calqués sur celles de Coordonnées qui gère bien tous les pays du monde).

Par défaut la fonction remplit déjà un peu suivant une logique similaire à ce qui était disséminé un peu partout dans les squelettes pour le nom (orga ou contact ou auteur). Pour les adresses par contre pour le moment ça ne prend en compte que si c'était lié directement à la commande (pas les adresses de l'auteur ou du contact etc). Le pipeline permet d'étendre et remplir si on veut que ça vienne d'autre part (par ex les champs en dur du plugin Livraisons).

Tous les sous-plugins (comme Livraisons) qui se basent sur ces infos DEVRONT faire confiance à cette API uniquement, sans aller eux-mêmes chercher les infos ailleurs. Par ex pour définir les frais d'envoi, ou si un plugin de taxe ajoute ou enlève des taxes suivant le pays, etc.

Je ne sais pas si je l'inclus dans cette branche ou si on modifie après : il faudra changer tous les squelettes pour utiliser les infos de l'API plutôt que de rechercher plus-ou-moins-pareil-mais-pas-toujours dans chaque squelette

L'API doit retourner quelques informations importantes sur la clientèle d'une commande précise, dans des clés définies à l'avance. Pour l'instant au moins nom, adresse_facturation, adresse_livraison. Dans les adresses les clés sont imposées aussi (calqués sur celles de Coordonnées qui gère bien tous les pays du monde). Par défaut la fonction remplit déjà un peu suivant une logique similaire à ce qui était disséminé un peu partout dans les squelettes pour le nom (orga ou contact ou auteur). Pour les adresses par contre pour le moment ça ne prend en compte que si c'était lié directement à la commande (pas les adresses de l'auteur ou du contact etc). Le pipeline permet d'étendre et remplir si on veut que ça vienne d'autre part (par ex les champs en dur du plugin Livraisons). Tous les sous-plugins (comme Livraisons) qui se basent sur ces infos DEVRONT faire confiance à cette API uniquement, sans aller eux-mêmes chercher les infos ailleurs. Par ex pour définir les frais d'envoi, ou si un plugin de taxe ajoute ou enlève des taxes suivant le pays, etc. Je ne sais pas si je l'inclus dans cette branche ou si on modifie après : il faudra changer tous les squelettes pour utiliser les infos de l'API plutôt que de rechercher plus-ou-moins-pareil-mais-pas-toujours dans chaque squelette
rastapopoulos added 1 commit 7 months ago
rastapopoulos added 1 commit 6 months ago
rastapopoulos force-pushed dev/issue_3_api_infos from 4fc8f9b65e to e94895a86f 2 months ago
Owner

Ça semble tout bien 👍

Quelques remarques dans le tableau retourné, des compléments rapport à C&O (dont la présence est déjà testée pour les adresses) :

  • Peut-être que si on a le détail prénom + nom, alors on peut l'ajouter en plus du nom complet.
  • Il pourrait s'avérer utile de savoir si le client est une personne physique ou morale (une orga).
    • soit une clé id_contact ou id_organisation, comme ça on peut le déduire d'après ça
    • soit un booléen "est-ce que c'est une orga oui/non" ?
    • ou alors un truc du genre "type = personne / orga" ?

Voilà ce que retourne la fonction actuellement, pour les relecteur⋅ices :

  • int id_auteur : compte utilisateur de la personne qui a fait la commande
  • string nom : nom complet de la personne ou orga qui a fait la commande
  • array adresse_livraison
    • string voie
    • string complement
    • string code_postal
    • string ville
    • string localite_dependante
    • string zone_administrative
    • string pays : code international
  • array adresse_facturation
    • string voie
    • string complement
    • string code_postal
    • string ville
    • string localite_dependante
    • string zone_administrative
    • string pays : code international
Ça semble tout bien 👍 Quelques remarques dans le tableau retourné, des compléments rapport à C&O (dont la présence est déjà testée pour les adresses) : * Peut-être que si on a le détail prénom + nom, alors on peut l'ajouter *en plus* du nom complet. * Il pourrait s'avérer utile de savoir si le client est une personne physique ou morale (une orga). * soit une clé `id_contact` ou `id_organisation`, comme ça on peut le déduire d'après ça * soit un booléen "est-ce que c'est une orga oui/non" ? * ou alors un truc du genre "type = personne / orga" ? Voilà ce que retourne la fonction actuellement, pour les relecteur⋅ices : * int id_auteur : compte utilisateur de la personne qui a fait la commande * string nom : nom complet de la personne ou orga qui a fait la commande * array adresse_livraison * string voie * string complement * string code_postal * string ville * string localite_dependante * string zone_administrative * string pays : code international * array adresse_facturation * string voie * string complement * string code_postal * string ville * string localite_dependante * string zone_administrative * string pays : code international
Poster
Owner

Sûrement un truc indépendant de C&O si par d'autres moyens on veut dire que c'est une orga.

Dans Livraisons ya aussi "numéro TVA" (ce qui permet de dire que c'est une entreprise forcément), mais ça c'est pas un champ qui existe dans les plugins actuels donc chacun le rajoute où il veut, mais on pourrait le prévoir dans le phpdoc pour dire où le mettre SI on le connait.

Sûrement un truc indépendant de C&O si par d'autres moyens on veut dire que c'est une orga. Dans Livraisons ya aussi "numéro TVA" (ce qui permet de dire que c'est une entreprise forcément), mais ça c'est pas un champ qui existe dans les plugins actuels donc chacun le rajoute où il veut, mais on pourrait le prévoir dans le phpdoc pour dire où le mettre SI on le connait.
Owner

Ah et t'avais prévu de modifier le squelette du privé qui donne les infos clients dans cette PR ou tu voulais faire ça à part ?

Celui-là : https://git.spip.net/spip-contrib-extensions/commandes/src/branch/master/prive/squelettes/inclure/commande_client.html

Edit : et aussi celui pour les adresses → https://git.spip.net/spip-contrib-extensions/commandes/src/branch/master/prive/squelettes/inclure/commande_adresses.html

Ah et t'avais prévu de modifier le squelette du privé qui donne les infos clients dans cette PR ou tu voulais faire ça à part ? Celui-là : https://git.spip.net/spip-contrib-extensions/commandes/src/branch/master/prive/squelettes/inclure/commande_client.html Edit : et aussi celui pour les adresses → https://git.spip.net/spip-contrib-extensions/commandes/src/branch/master/prive/squelettes/inclure/commande_adresses.html
Poster
Owner

Ça c'est ce que je disais hier : éventuellement ça peut être après, car comme c'est un ajout d'une nouvelle fonction ça ne change rien à l'existant, donc valider cette PR permettrait déjà de pouvoir utiliser l'API ailleurs. Dans le texte plus haut je me demandais dès le départ si j'incluais ça directement ou pas.

Ça c'est ce que je disais hier : éventuellement ça peut être après, car comme c'est un ajout d'une nouvelle fonction ça ne change rien à l'existant, donc valider cette PR permettrait déjà de pouvoir utiliser l'API ailleurs. Dans le texte plus haut je me demandais dès le départ si j'incluais ça directement ou pas.
Owner

À mon avis vaut mieux inclure tout de suite dans la PR pour pas oublier plus tard et montrer un exemple d'utilisation.

À mon avis vaut mieux inclure tout de suite dans la PR pour pas oublier plus tard et montrer un exemple d'utilisation.
rastapopoulos added 1 commit 2 months ago
Collaborator

hello,
quelques idées que je vous propose de discuter

cette API fait le pont entre plusieurs plugins

  • commande
  • coordonnées
  • contacts & orga
  • livraison
    est-ce que ce ne serait pas mieux d'en faire un plugin à part ?

l'usage que je vois est de pouvoir lister des coordonnées depuis un tableau de correspondance personnifié pour s'en servir lors du calcul du cout de livraison. Et considérant qu'une livraison de commande n'est qu'un champ à entrer dans une commande en details_commandes
( dont le 'prix' est calculé en amont grace à :
mode_livraison + coordonnees (réelles ou fictives) + (objet-s ou panier ou commande).

Actuellement le plugin livraisons allonge de façon excessive la table commandes et dispose de fonctions qu'on pourrait imaginer scinder en deux plugins. Le but est d'afficher pour information en amont le prix plausible de livraison d'un objet, du panier, d'une commande.

  • livraison_modes -> uniquement les tables de type de livraisons
  • livraison_calcul -> calculer à partir d'un tableau de coordonnées par defaut (en france métropolitaine + colissimo)
    _ livraison_commande -> créée les champs supp si on veut continuer à entrer les coordonnées dans la table commandes.

A vous lire
++

hello, quelques idées que je vous propose de discuter cette API fait le pont entre plusieurs plugins - commande - coordonnées - contacts & orga - livraison est-ce que ce ne serait pas mieux d'en faire un plugin à part ? l'usage que je vois est de pouvoir lister des coordonnées depuis un tableau de correspondance personnifié pour s'en servir lors du calcul du cout de livraison. Et considérant qu'une livraison de commande n'est qu'un champ à entrer dans une commande en details_commandes ( dont le 'prix' est calculé en amont grace à : mode_livraison + coordonnees (réelles ou fictives) + (objet-s ou panier ou commande). Actuellement le plugin livraisons allonge de façon excessive la table commandes et dispose de fonctions qu'on pourrait imaginer scinder en deux plugins. Le but est d'afficher pour information en amont le prix plausible de livraison d'un objet, du panier, d'une commande. - livraison_modes -> uniquement les tables de type de livraisons + livraison_calcul -> calculer à partir d'un tableau de coordonnées par defaut (en france métropolitaine + colissimo) _ livraison_commande -> créée les champs supp si on veut continuer à entrer les coordonnées dans la table commandes. A vous lire ++
Poster
Owner

@touti c'est précisément à ça que sert cette API et c'est déjà codé et en place dans cette branche : spip-contrib-extensions/livraison#5
(mais faut justement valider cette PR ici pour valider ensuite la PR là bas, tout fonctionne utilisable en prod à priori)

Tout ceci étant… toujours lié au plugin Commandes, qui est le pivot central de tout ce qui concerne le commerce dans SPIP depuis un moment (c'est toujours "la personne cliente d'une commande", "la facturation d'une commande", etc et quelque soit la manière d'acheter on devrait toujours passer par un objet commande pour avoir un suivi unifié). D'autant plus pour le cas d'utilisation "livraison" qui est un plugin dépendant du plugin Commandes.

Du coup ça me parait toujours le plus logique (et même obligatoire) pour le moment d'avoir cette API dans le plugin Commandes plutôt qu'un plugin séparé puisque pour trouver "les infos d'un⋅e client⋅e" c'est toujours en partant des infos de la commande (= à quel id_auteur OU à quel email ou autre, était cette commande). Sans être relié à rien un plugin autonome n'a que peu de sens puisque c'est pas toujours forcément un id_auteur (en théorie on peut aussi faire des commandes d'anonyme enfin de gens qui ne veulent pas créer un compte permanent).

@touti c'est précisément à ça que sert cette API et c'est déjà codé et en place dans cette branche : https://git.spip.net/spip-contrib-extensions/livraison/pulls/5 (mais faut justement valider cette PR ici pour valider ensuite la PR là bas, tout fonctionne utilisable en prod à priori) Tout ceci étant… toujours lié au plugin Commandes, qui est le pivot central de tout ce qui concerne le commerce dans SPIP depuis un moment (c'est toujours "la personne cliente *d'une commande*", "la facturation *d'une commande*", etc et quelque soit la manière d'acheter on devrait toujours passer par un objet commande pour avoir un suivi unifié). D'autant plus pour le cas d'utilisation "livraison" qui est un plugin dépendant du plugin Commandes. Du coup ça me parait toujours le plus logique (et même obligatoire) pour le moment d'avoir cette API dans le plugin Commandes plutôt qu'un plugin séparé puisque pour trouver "les infos d'un⋅e client⋅e" c'est toujours en partant des infos de la commande (= à quel id_auteur OU à quel email ou autre, était cette commande). Sans être relié à rien un plugin autonome n'a que peu de sens puisque c'est *pas toujours forcément* un id_auteur (en théorie on peut aussi faire des commandes d'anonyme enfin de gens qui ne veulent pas créer un compte permanent).
Collaborator

Ben non, commandes n'est pas forcément le pivot central, même si ça te parait recommandé, ça dépend du processus voulu.

On peut avoir une boutique simple qui n'utilise que paniers et bank et laisser paypal (…) gérer les coordonnées, si on ne souhaite pas stocker de données clients. Ou avec paiement formidable qui ne nécessite pas non plus commandes.

Du coup, en pensant le processus avec une obligation d'utiliser commandes comme tu le fais, l'utilisation de cette PR n'est pas possible.

Sans trop avoir fouillé, ça voudrait dire aussi que le panier ne peut pas calculer le coût de la livraison (si on dépend de commandes).
Il est pourtant respectueux de prévenir les client·es avant qu'iels ne donnent leurs coordonnées, à combien la livraison est évaluée au risque qu'iels quittent les sites qui omettent cela !

voila voila

Ben non, commandes n'est pas forcément le pivot central, même si ça te parait recommandé, ça dépend du processus voulu. On peut avoir une boutique simple qui n'utilise que paniers et bank et laisser paypal (…) gérer les coordonnées, si on ne souhaite pas stocker de données clients. Ou avec paiement formidable qui ne nécessite pas non plus commandes. Du coup, en pensant le processus avec une obligation d'utiliser commandes comme tu le fais, l'utilisation de cette PR n'est pas possible. Sans trop avoir fouillé, ça voudrait dire aussi que le panier ne peut pas calculer le coût de la livraison (si on dépend de commandes). Il est pourtant respectueux de prévenir les client·es avant qu'iels ne donnent leurs coordonnées, à combien la livraison est évaluée au risque qu'iels quittent les sites qui omettent cela ! voila voila
Collaborator

Ok, après avoir un peu mieux étudier le code et lu les différents tickets (pff ça se croise) ,

j'ai créé une fonction livraison_cout_panier spip-contrib-extensions/livraison#14
qui résoud la question du calcul du prix de livraison du panier pour informer l'internaute en amont.

Je pense que @rastapopoulos et @tcharlls vous êtes sur la bonne piste en récupérant via une API les coordonnees client,
éventuellement pour remplir ensuite les champs adresses de la commande.

Ma question est donc qu'est-ce qu'on attend pour merger ? :)

Ok, après avoir un peu mieux étudier le code et lu les différents tickets (pff ça se croise) , j'ai créé une fonction livraison_cout_panier https://git.spip.net/spip-contrib-extensions/livraison/pulls/14 qui résoud la question du calcul du prix de livraison du panier pour informer l'internaute en amont. Je pense que @rastapopoulos et @tcharlls vous êtes sur la bonne piste en récupérant via une API les coordonnees client, éventuellement pour remplir ensuite les champs adresses de la commande. Ma question est donc qu'est-ce qu'on attend pour merger ? :)
Poster
Owner

@touti pour merger, pas grand chose mais un peu, il ne manque que la dernière remarque de @tcharlss qui répondait à ma question, où il disait que c'était mieux d'inclure dans la PR le fait de modifier tous les squelettes par défaut généré pour utiliser cette nouvelle API, plutôt que faire du micmac perso. Càd "commande_client.html", "commande_adresses.html", etc. Et… je n'ai toujours pas eu le temps de faire ce "mini" dernier point :(

Dès que ces squelettes utilisent les infos venant de l'API, on peut merger à priori.

@touti pour merger, pas grand chose mais un peu, il ne manque que la dernière remarque de @tcharlss qui répondait à ma question, où il disait que c'était mieux d'inclure dans la PR le fait de modifier tous les squelettes par défaut généré pour utiliser cette nouvelle API, plutôt que faire du micmac perso. Càd "commande_client.html", "commande_adresses.html", etc. Et… je n'ai toujours pas eu le temps de faire ce "mini" dernier point :( Dès que ces squelettes utilisent les infos venant de l'API, on peut merger à priori.
This pull request has changes conflicting with the target branch.
commandes_fonctions.php
inc/commandes.php
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.