La typologie produit pour normaliser ses caractéristiques physiques
Lorsqu’on crée un produit, il est essentiel de le classer dans une typologie qui permet de définir ses standards physiques, un peu comme un architecte qui choisit d’abord le type de bâtiment avant d’en préciser la hauteur ou les matériaux.
Nous travaillons sur le projet sur Github afin de faire un POC intégrable dans le core Dolibarr, les participants : Eoxia, NSInfo, Progiseize, Evarisk (@Lmag , @AnthonyD@nicolas90@Nicolas-Eoxia
Pour bien comprendre, c’est un ensemble d’extra-fields rassembler sous un “type” qui permet de renseigner les caractéristiques d’un élément ? Ce qui permettra d’avoir des extra-fields selon le type d’un élément ? C’est bien ça ?
Attention au terme “topologie” qui n’a pour moi aucun rapport mais qui apparaît de temps en temps. Ça ne falicite pas la compréhension.
Est-ce que on peut faire un parallèle avec les factures modèles pour les factures ? Ce serait des produits modèles permettant de créer certains types de produits ?
J’en doute pas des capacités de chacun mais pensez à ne pas (trop) chevaucher fonctionnellement avec les variantes de produit ? ou ca n’a rien à voir ?
Voila les deux POC réalisés chez nous après le devcamp :
Import d’un fichier json qui décrit l’objet et implémentation sous forme d’extrafields mais ça va casser rapidement pour cause de nombre d’extrafields possibles
import du fichier json qui cette fois créé une table dans la bdd et permet donc ensuite d’être lié à n’importe quoi d’autre
L’objectif serait de faire un dépôt commun de fichiers json de ce type qui seraient ensuite utilisables par n’importe quel module (ou autre) de dolibarr pour qu’on puisse uniformiser les objets que nous manipulons
Hello à toutes et tous,
un petit point d’étape / de suivi / transparence sur ce sujet suite au devcamp.
Donc suite au devcamp de fin 2025 j’ai avancé comme annoncé dans le message précédent sur les deux POC.
Et à ce devcamp de juin 2026 nous avons fait un point d’étape.
Du côté de cap-rel le chantier a beaucoup avancé et je voulais voir avec les autres où ça en était.
Pour cap-rel le focus est fait pour notre projet de gestion des interventions, j’ai donc mis en place un site web de partage des schemas : https://schemas.cap-rel.fr/ (le dépôt git est public comme dhabitude, vous avez le lien en pied du site web) et j’ai présenté ça en petit commité lors du devcamp.
Il en est ressorti une proposition d’ajout dans le coeur de dolibarr, la première étape étant le datamodel via la PR suivante:
Pour rappel de l’objectif si on devait donner un exemple vraiment simple, l’objectif est de pouvoir enrichir ou définir de manière générique et systématique des données complémentaires sur n’importe quel objet dolibarr.
Exemple vous vendez ou louez des voitures, certains utilisateurs de dolibarr voudraient pouvoir stocker des données spécifiques « voiture » dans les produits, d’autres dans les devis, et les loueurs dans les contrats…
Le schéma « voiture » apporterait donc un ensemble de champs normalisés que vous pourriez importer et appliquer aux objets que vous voulez.
en attendant c’est beaucoup moins…
Je le répète : customTabs sait déjà faire de genre de chose, j’ai proposé de me filer l’argent de leur hypothétique giff pour l’intégrer dans le core mais il préfère se payer à réinventer la roue…
