Probleme de jointure sur des tables externes

Dev
1

Bonjour,
Je suis en train de me faire un plugin de liaison entre spip et dolibarr (logiciel de facturation) afin de me faire une boutique en ligne qui interface les 2 : les produits sont des objets dolibarr existant et les commandes/facturations sont géré dans dolibarr mais la partie site internet est dans spip.
Ça marche déjà pour la partie commande / facturation / récupération des prix, mais uniquement avec des objets spip qui récupère les infos dans dolibarr.

J’aimerai maintenant pouvoir utiliser la base de dolibarr en lecture pour afficher les produits présent dans dolibarr pour ne pas avoir à tous les recréé (acces par spip en lecture seul de la base. les écritures se demandant via l’api rest de dolibarr, donc restent géré par dolibarr).

la logique d’union de table de dolibarr n’est pas la même que celle de spip il me faut donc déclarer des exceptions et c’est là que je bloque…:
Dans dolibarr les tables d’infos produits sont les suivantes:

  • product (table principale) avec la clé en rowid
  • product_extrafields (pour des info de type champs extra) avec la clé qui fait pivot avec la table product en fk_object
  • product_stock, clé pivot fk_product
  • product_attribute_combination, clé pivot: fk_product_parent

j’aimerai donc pouvoir faire des liaison avec toutes ces tables et pour l’instant je n’y arrive que pour la table product_attribute_combination.

function dolibarr_declarer_tables_interfaces($interfaces)
{
//[...]
        $interfaces['table_des_tables']['product'] = 'product';   // déclare des alias de tables SQL
        $interfaces['exceptions_des_tables']['product']["id_product"] = ['product','rowid'];  //attribue des alias de colonne SQL sur une table donnée

        $interfaces['table_des_tables']['product_extrafields'] = 'product_extrafields';
        $interfaces['tables_jointures']['product'][] = 'product_extrafields';

        $interfaces['exceptions_des_jointures']['product_extrafields']['fk_object'] = [$table, 'rowid'];
        $interfaces['exceptions_des_tables']['product_extrafields']["id_$table"] = 'fk_object';

// liaison à la table product_attribute_combination
        $interfaces['table_des_tables']['product_attribute_combination'] = 'product_attribute_combination';
        $interfaces['exceptions_des_tables']['product']['id_product_parent'] = array('product_attribute_combination', 'fk_product_parent');
        $interfaces['exceptions_des_tables']['product']['fk_product_parent'] = array('product_attribute_combination', 'fk_product_parent');
        // jointures supplémentaires sur product
        $interfaces['tables_jointures']['product'][] = 'product_attribute_combination';
        $interfaces['exceptions_des_jointures']['product_attribute_combination']['fk_product_child'] = array('product', 'rowid');


// afin de pouvoir utiliser dans spip des champs id_rubrique, id_secteur et statut
        $interfaces['exceptions_des_tables']['product']['id_rubrique'] = ['product_extrafields', 'id_rubrique_'.$nomSiteSpip];
        $interfaces['exceptions_des_tables']['product']['statut'] = ['product_extrafields', 'statut_'.$nomSiteSpip];
        $interfaces['exceptions_des_tables']['product']['id_secteur'] = ['product_extrafields', 'id_secteur_'.$nomSiteSpip];
// categorie (ie 'mot' dans dolibarr)
        $interfaces['table_des_tables']['categorie_product'] = 'categorie_product';
        $interfaces['exception_des_tables']['product']['fk_categorie'] = ['categorie_product', 'fk_categorie'];
        $interfaces['tables_jointures']['spip_product'][] = 'categorie_product';
        $interfaces['exceptions_des_jointures']['categorie_product']['fk_product'] = array('product', 'rowid');

Avez vous une idée de ce qui peut manquer ?

Merci beaucoup !

2

Tu peux peut-être créer des vues dans Dolibarr qui adoptent le formalisme SPIP pour le nom des champs ?

3

Hello, sans avoir encore regardé ton problème précis, est-ce que tu sais qu’il a déjà existé une liaison entre SPIP et Dolibarr qui s’appelait « Dolispip ». Il y avait même un nom de domaine dédié.

Il faudrait demander à @azerttyu où ça en est, si ça a totalement disparu ou quoi. Mais à minima c’était du logiciel libre : il doit quand même être possible de repartir de cette base plutôt que de tout recoder 100% depuis zéro. (Sauf si tout est vraiment trop vieux et obsolète ?)

1 « J'aime »
4

non je ne savais pas… Mais ça doit être obsolete, y a pas eu de commit depuis 10 ans… Je vais rester sur mon projet qui a déjà un bon bout qui marche :slight_smile:

5

Non justement, je voudrais pouvoir afficher ce qui est directement présent dans dolibarr. Sans en changer la forme, pour que ça soit afficher pareil dans dolibarr et spip. Il faut juste que je trouve comment faire ces jointures :slight_smile:
Y aurais bien la solution de passer par l’api REST de dolibarr, mais ça serait perdre les capacités des squelettes de spip d’afficher directement les objets de la bdd.

6

M’est-avis que ce serait quand même plus propre d’utiliser l’API REST de Dolibarr en lecture aussi :

  • l’API est censée être plus stable que le détail du stockage interne qui peut changer au cours du temps, donc ça parait plus pérenne d’utiliser ce qui est documenté comme interface publique, alors que les tables, champs, etc peuvent bouger (et il est possible de coder des boucles dont la source est l’API, et même en codant peu avec les boucles DATA)
  • ça aboutit à un truc plus générique qui pourra être réutilisé par d’autres, car tout le monde n’a pas forcément SPIP et Dolibarr installé sur le même serveur et déclarable en base externe de manière sécurisée, alors que l’API elle est bien la manière officielle d’aller lire les infos peu importe où le Dolibarr est installé
1 « J'aime »
7

J’insiste : une vue, c’est une requête MySQL qui se comporte comme une table en lecture seule.

Autrement dit, ça permet de transformer des données d’une ou plusieurs tables en une autre table qui pourra être lue depuis SPIP par exemple.

NB : une vue est dynamique elle affiche ce qui est dans les tables d’origine en temps réel.

1 « J'aime »
8

@RealET
OK, pardon je ne connaissait pas les vues et je n’avais donc pas compris ta réponse, oui ça répondrais parfaitement à ma problématique.

@rastapopoulos,
Effectivement la contrainte c’est que spip ait accès à la base de dolibarr… et donc l’API va mieux correspondre si la base sql de dolibarr n’est pas accessible.
Un argument qui va dans le sens de l’utilisation de l’API c’est la loi des finances qui rend globalement les installations de dolibarr moins accessibles
Par contre pour ce qui est de la docu dolibarr elle n’est pas plus présente pour l’api que pour la base

Merci beaucoup, je vais cogiter avec tout ça

2 « J'aime »
9

Bonjour

J’ai bien récupéré des bouts d’archive concernant le projet dolisip. Mais il me manque des bouts malheureusement.
Les 2 projets initiaux n’existent plus. Le premier en raison du décès prématuré du développeur et l’impossibilité d’accéder à une de ses archives. Le second en raison de la fin des RMLL qui était l’exemple complet d’une telle liaison. Les forges associées ont aussi disparu dans les limbes.

Certains bouts fonctionneraient encore et la base de travail était intéressante pour suivre et s’adapter à l’existant.
Le code n’ayant pas spécifiquement évolué coté « api », une bonne partie de l’existant est encore à mon sens valide à date.

Toutefois les boucles devraient s’appuyer sur l’api et non les bases de données. Les outils ne sont pas forcément hébergés de la même façon. On ne va pas essayer de mettre en frontal un ERP sur internet alors que les données son sensibles.

Dans la même veine il y avait le projet spip2ps (prestashop) qui était en mode api.
Enfin de mon coté je n’ai plus prévu de bosser sur cette question. Mais ce que j’ai récupéré est à disposition bien entendu.

10

Mon plugin (non terminé) est fonctionnel.

Je vais monter un dépot prochainement pour le partager.

1 « J'aime »