[RELEASE] CustomFields module Champs Personnalisés

Utiliser mon Dolibarr Autres modules natifs
1

Module CustomFields (Champs Personnalisés) pour Dolibarr

Téléchargement

=> CUSTOMFIELDS V3

CustomFields v3 est disponible pour toutes les versions de Dolibarr à partir de 3.1 et jusqu’à la toute dernière (actuellement 3.7) et probablement compatible avec les futures versions de Dolibarr (tant que les systèmes de Hooks et Triggers ne changent pas) en téléchargement gratuit ici:

Plus d’infos:
http://www.customfields.org

Démo en ligne:
http://customfields.org/demo/htdocs/index.php

CustomFields Pro contient toutes les fonctionnalités de CustomFields Free v2, mais avec bien d’autres fonctionnalités avancées en plus comme les fonctions de surcharge et les cascades.

Note: Les champs créés avec d’anciennes versions de CustomFields et avec la version Free v2 sont totalement compatibles avec la version Pro, il suffit juste de supprimer tous les fichiers CustomFields avant de copier les fichiers de la version Pro (tout est expliqué dans le fichier INSTALL.txt fournis dans l’archive, et sur le wiki également).

=> CUSTOMFIELDS Free V2

CustomFields Free v2 est l’ancienne version de CustomFields.

Pour télécharger CustomFields Free edition pour Dolibarr >= 3.4 (compatible avec tous les Dolibarr supérieurs, y compris 3.6.x et 3.7-alpha):

https://github.com/lrq3000/dolibarr_customfields/archive/3.4.zip

Pour télécharger CustomFields Free edition pour Dolibarr 3.3.x:

https://github.com/lrq3000/dolibarr_customfields/zipball/3.3
ou
http://www.dolistore.com/lang-fr/autres/221-Champs-Personnalis--s.html

Pour télécharger CustomFields Free edition pour Dolibarr 3.2.x:

https://github.com/lrq3000/dolibarr_customfields/zipball/3.2
ou
http://www.dolistore.com/lang-fr/autres/98-Champs-Personnalis--s-pour-Dolibarr-3-2.html

Pour télécharger CustomFields Free edition pour Dolibarr 3.1 (3.1.1 inclus):

https://github.com/lrq3000/dolibarr_customfields/zipball/3.1

Note: il est très fortement conseillé de mettre à jour votre version de CustomFields si elle est en-dessous de 2.11 car les dernières versions ont de nouvelles fonctionnalités critiques.

Documentation

La documentation pour la version Free réside directement dans les archives, dans le fichier README-CF.txt

La documentation pour la version Pro est disponible sur le wiki ainsi que dans le github:

Documentation utilisateur:
http://wiki.dolibarr.org/index.php/Module_CustomFields_FR

Examples d’implémentations:
http://wiki.dolibarr.org/index.php/Module_CustomFields_Cases_FR

Néanmoins les documentations en français ne contiennent que les bases, car la documentation n’a pas encore été totalement traduite.

La documentation complète se trouve sur le wiki en anglais, et contient toutes les infos sur les fonctionnalités avancées de CustomFields:

Documentation utilisateur en anglais:
http://wiki.dolibarr.org/index.php/Module_CustomFields

Documentation développeur en anglais:
http://wiki.dolibarr.org/index.php/Module_CustomFields_Dev

Exemples d’implémentations en anglais:
http://wiki.dolibarr.org/index.php/Module_CustomFields_Cases

Support

Vous pouvez utiliser ce fil de discussion pour poser toutes vos questions à propos de CustomFields.

Le reste de ce post n’est gardé ici qu’en historique des débuts du module, vous pouvez ignorer le reste du post et aller lire la documentation sur le wiki pour commencer à utiliser directement le module, ou aller en dernière page de ce fil de discussion et poster vos questions.

Description
Le module CustomFields (Champs Personnalisés) a été créé dans le but premier de permettre aux intégrateurs de répondre plus facilement, rapidement et robustement aux demandes de customization des utilisateurs.

Mon but était de créer un module qui automatiserait la création et la gestion de champs personnalisés avec un code générique, flexible et facilement adaptable à tous les modules de Dolibarr tels qu’ils sont avec le minimum de modification des fichiers Core, et peut également s’intégrer en théorie à n’importe quel module tiers.

Ce module ne rentre pas en conflit avec ExtraFields et ne remplace pas ses fonctionnalités, mais en lisant le code de EF j’ai pu remarquer qu’il était très spécifique au module société, et très peu générique donc difficilement adaptable à d’autres modules, car il aurait requis de créer des fonctions spécifiques pour chaque module supporté, ce que je voulais absolument éviter. Je voulais qu’un dev extérieur au projet puisse faire (presque) uniquement du copier/coller d’un code que je fournirais pour adapter les champs personnalisés à un nouveau module.

Ceci étant, je voulais également donner un maximum de fonctionnalités et de flexibilité aux usagers et intégrateurs, avec un minimum de compétence et de temps investi. En gros, que tout soit automatisé, même ce qui n’a pas été prévu dans le module CustomFields au départ.

Je vous présente donc aujourd’hui le fruit de mon labeur, sous licence GPL v2 open source, ma contribution au projet et à l’esprit Dolibarr.

Vous pourrez trouver joint à ce post la dernière version standalone du module, la dernière version étant directement mergé à Dolibarr dans mon repository:

Quelques captures d’écran (en anglais mais le module est traduit en francais):
http://imageshack.us/photo/my-images/811/cf8a.jpg/
http://imageshack.us/f/135/cf2io.jpg/
http://imageshack.us/f/197/cf3i.jpg/
http://imageshack.us/f/24/cf4hr.jpg/
http://imageshack.us/f/15/cf5t.jpg/
http://imageshack.us/f/834/cf6c.jpg/
http://imageshack.us/f/829/cf7yu.jpg/

Avantages:
- Supporte nativement les modules suivants: Factures, propositions commerciales, produits/services.

- Support complet du multilangage (francais et anglais pour le moment, mais il est très facile de traduire vers d’autres langues en utilisant la même méthodologie que Dolibarr, à savoir les fichiers de langue):
* Console d’administration multilangue
* Libellés des champs personnalisés multilangues (vous pouvez traduire vos propres champs dans plusieurs langues!)
* ET valeurs des champs personnalisés multilangues également (eg: Choix Oui/Non peut être traduit dans n’importe quelle langue, idem pour les enum/Liste déroulante).

- 6 types de champs gérés nativement :
* Zone de texte simpleTextbox
* Zone de texte étendue HTML
* Choix Oui/Non
* Choix Vrai/Faux
* Liste déroulante (vos propres choix)
* Contrainte (liste déroulante liée à une autre table)
* Autre (type personnalisé)

Le dernier type n’est pas vraiment un type natif mais permet à l’intégrateur de très facilement choisir un type SQL qui n’est pas encore implémenté nativement dans CustomFields, et celui-ci sera quand même géré par le module comme n’importe quel autre champ (par défaut, pour les types inconnus ils sont affichés comme une zone de texte simple).

Il est par ailleurs aisé de rajouter le support natif pour un nouveau type de champ et de programmer sa gestion et son affichage à l’écran (voir le Readme).

- Requête SQL personnalisée pour créer des champs complexes : ces requêtes sql seront executées après la création/modification de la définition d’un champ personnalisé, ce qui permet de virtuellement créer n’importe quoi en SQL.

- Portable vers toutes les versions de Dolibarr (en théorie, tant que les triggers sont implémentés)

- S’intègre harmonieusement à Dolibarr : la nomenclature du projet et les habitudes de développement ont été respectées au maximum.

- Propre : vous pouvez désactiver voire supprimer le module et ses tables sans n’avoir aucun inconvénient (à part la perte des données des champs personnalisés bien entendu), car le module CustomFields est (presque) totalement découplé de Dolibarr.

- Gestion totalement automatique et transparente des champs personnalisés en base de données, grâce à des commandes SQL d’intégrité et aux triggers Dolibarr.

- Extensible à n’importe quel module, que ce soit un module noyau de Dolibarr ou un module tiers créé par la communauté(instructions détaillées dans le README-CF.txt).

- Champs liés/champs contraints : Auto-detection (trouve automatiquement les meilleurs paramètres lors de la création du champ personnalisé) et auto gestion des contraintes (met à jour le champ automatiquement en fonction de l’autre table liée) et auto gestion de leur affichage et de leur interface utilisateur (les affiche en tant que liste déroulante et il est possible de choisir la donnée qui sera affichée, comme le nom ou login ou autre!).

Ex: si vous souhaitez lier votre champ personnalisé à la table des utilisateurs de Dolibarr, sélectionnez à la création de champs le type Autre/Contrainte et comme contrainte: « llx_users ». Créez le champs, celui-ci devrait maintenant vous afficher la liste des ID (rowid) de chaque utilisateur de Dolibarr!
Maintenant si vous voulez afficher le nom de chaque utilisateur au lieu de leur ID, simplement ajoutez le préfixe « name_ » au nom de votre champ personnalisé (vous pourrez toujours changer le libellé plus tard dans les fichiers langs). Par exemple choisissez « name_ref ». Vous pouvez maintenant voir que CustomFields va automatiquement comprendre votre intention et afficher la liste des noms d’utilisateurs au lieu de leur ID (car avec « name_ » vous lui avez dit de prendre le champ name de la table llx_users au lieu des ID).
Ne vous inquiétez pas, le champ est toujours lié aux ID des utilisateurs, donc il ne peut y avoir de doublon ni d’erreur de noms homonymes, c’est simplement l’affichage qui change.

- Possibilité de définir des champs personnalisés différents pour CHAQUE module supporté

- Totalement intégré dans la génération de documents PDF (accessible avec $object->cf_votrechamp) et ODT (accessible avec de simples tags - vous pouvez même accéder à TOUS les champs d’une table liée, par ex: avec name_ref contraint sur llx_users, vous pouvez accéder au nom d’un utilisateur avec {cf_name_ref} mais aussi par {cf_name_ref_name} et accéder au prénom par {cf_name_ref_firstname} et numéro de téléphone par {cf_name_ref_user_mobile}, etc. Plus d’infos dans le Readme).

- Présentation élégante et transparente dans la fiche de données produit/facture/devis/etc.

- Supporte toutes les fonctions classiques d’un champ Dolibarr standart: creation, modification, clonage, suppression, suppression en cascade (facture supprimée -> données champs supprimés), etc.

- Propre: n’interfère pas avec le fonctionnement normal de Dolibarr, tout est séparé. You can just delete the customfields and it will never do anything wrong with your Dolibarr install or your other datas.

- Kit pour développer ses propres modules : CF fournit de nombreuses méthodes pour automatiquement gérer les entrées utilisateurs ainsi que pour accéder et gérer les valeurs des champs depuis n’importe où dans votre code (que ce soit dans le noyau de Dolibarr ou dans votre propre module!), et même quelques fonctions génériques pour envoyer des requêtes SQL libre/personnalisée, échapper les entrées utilisateurs, et gérer les données récupérées.

- Le code est très facile à modifier/personnaliser/réutiliser/porter (très commenté et architecture modulaire, pas de fonctionnalités en double).

- Gratuit et Open Source: gratuit à utiliser, redistribuer et modifier selon vos besoins!

Désavantages:
- Problème possible: a été créé et testé (assidument!) avec le SGBD MySQL, peut-être que cela nécéssitera un peu de portage pour les autres SGBD comme PostgreSQL (usage étendu des tables contenant les schémas de structure : informations.columns et references). Mis à part cela, toutes les commandes SQL ont été pensée et implémentée de la manière la plus générique possible pour être au maximum compatible avec les autres SGBD (même Oracle SQL en théorie!).

NEWS: il semble que informations.columns et references soient des normes de SQL, et PostgreSQL semble les supporter, donc CustomFields devrait aussi fonctionner avec PostgreSQL. Si vous êtes courageux et que vous testez CustomFields avec PostgreSQL, n’oubliez pas de nous faire un retour de votre expérience!

NEWS2: je n’ai pas eu de retour, mais j’ai vérifié et effectivement cela devrait fonctionner sans soucis. D’autre part, CustomFields a été mis à jour pour être encore davantage compatible avec les autres SGBD, donc il ne devrait y avoir aucun soucis.

5 « J'aime »
2

Ce module a l’air sympa, merci de le distribuer.

Par contre il surcharge et écrase de nombreux fichiers du core Dolibarr à l’installation.
Il me semble qu’il est possible d’utiliser le répertoire « custom » pour utiliser ces fichiers dans le module sans écraser les autres… Il faudrait confirmer ça.

3

Non, ce n’est pas possible. J’ai depuis le début modelisé ce module pour qu’il soit le plus indépendant possible du code de Dolibarr, mais malheureusement dans la v3.1.0 ce n’est pas possible : il faut au moins toucher à un fichier par module supporté (il faut rajouter le code là ou on veut afficher les champs personnalisés).

Je vais essayer de porter ça pour la v3.2.0 avec le système de hooks, ce qui permettrait théoriquement de totalement découpler le module CustomFields des fichiers de Dolibarr.

Néanmoins n’ayez par peur, le module en v1.1.1 est adapté à Dolibarr v3.1.0 RC donc il n’y a absolument aucun risque de perte de fonctionnalités pour cette version (cela devrait être le même cas pour la v3.1.0 finale, il ne devrait pas y avoir de modifications sur les fichiers core surchargés).

4

Ça y est, j’ai porté le code vers Dolibarr v3.2.0 en usant du système de hooks, donc plus de conflit avec le code core de Dolibarr.

Dispo sur mon github:
https://github.com/lrq3000/dolibarr

5

Rien à dire d’autre que Bravo et Merci, même le fichier d’installation est digne du plus grand respect ! …En attendant impatiemment de passer sur la 3.1…

6

je n’arrive pas a l’activité.
comment faire il n’apparait pas dans le menu,
Cordialement

7

Merci pour vos encouragements :happy:

Désolé le screenshot que j’ai posté n’est plus valide, dans la dernière version le module a été déplacé dans les « Modules principaux », dans la section « Outils multi-modules »:

8

J’ai installer aujourd’hui la,version git.
Le modulevest bien présent dans le répertoire mais pas dans l’activation des modules…
Je ne comprends pas bien…je regarde si j’ai pas fait une erreur…mais bon
Cordialement

9

Bonjour ,

j’ai ce message à la création de table à partir du module : « (errno: 150) can’t create table »
une idée peut être?
Merci

10

Attention, la version github est réservée à Dolibarr v3.2.0, êtes-vous sûr de tourner sous cette version? Si oui, vérifiez que le fichier /htdocs/includes/modules/modCustomFields.class.php existe bien.

Um… Cela signifie qu’il n’a pas su créer la table SQL. J’aurais besoin de plus d’infos:
- Est-ce MySQL ou PostgreSQL ?
- Quelle version ?
- Quel hébergeur ? Mutualisé ou dédié ?
- L’erreur apparait pour la création de toutes les tables pour tous les modules, ou c’est seulement un module en particulier ?
- Quelle version de CustomFields (voir /htdocs/customfields/Readme-CF.txt) ?

11

Je suis sous debian stable sous mysql… A jour
Hébergement chez moi
Pour le reste je regarde ce soir
Cordialement

12

J’utilise la 3.2 alpha en test localavec Mysql 5.1.37
erreur sur tous les modules
customfields de github

merci

13

Je viens de peut-être trouver la cause, j’ai uploadé la mise à jour sur github, essayez avec cette version et dites moi si cela fonctionne mieux:

https://github.com/lrq3000/dolibarr/tarball/develop

1 « J'aime »
14

Non non vous n’avez pas besoin de me donner ces infos, c’était pour le problème de galtitou, votre problème n’a rien à voir avec mysql normalement.

Vérifiez juste que /htdocs/includes/modules/modCustomFields.class.php existe bel et bien et à ce chemin précis, c’est ce fichiers qui gère l’affichage dans le panneau d’administration.

Quelle est votre version de Dolibarr et de CustomFields?

15

OK je pense savoir. Vérifiez que vous utilisez bien le moteur INNODB et pas MYISAM (qui est le moteur par défaut dans MySQL < 5.5) car MYISAM ne supporte pas les fonctionnalités dont CustomFields a besoin.

16

Bonne nouvelle pour les utilisateurs de PostgreSQL, il semblerait que la table information_schema soit un standard SQL, donc CustomFields doit très probablement aussi fonctionner pour Postgres. Voir:
http://www.postgresql.org/docs/7.4/static/information-schema.html#INFOSCHEMA-SCHEMA

17

Merci, ça fonctionne effectivement tout de suite,création des tables et mise en place des champs,
je vais travailler un peu là-dessus.Ce module est indispensable !

Il faut que je puisse imprimer ce champ dans mon pdf ,j’ai vu qu’il y avait une fonction pour ça mais je suis plus timoré quand il s’agit d’entrer dans le code.:huh:

Encore merci pour la raipdité de la réponse et le travail fourni.

18

Juste pour mon information, qu’avez-vous fait exactement ? Juste mis à jour CustomFields ou vous êtes aussi passé sous InnoDB ?

C’est très facile, tout est documenté et le paragraphe est relativement petit (il aurait pu être encore plus petit mais j’ai préféré montrer toutes les possibilités ;)).

Exemple simple: Soit un champ nommé « monchamp ». Son nom de variable sera automatiquement donné: « cf_monchamp ». Dans le template PDF, il suffira d’utiliser

$object->cf_monchamp

pour avoir la valeur dans ce champ. Pour l’afficher dans le PDF, il suffira d’utiliser la commande FPDF suivante:

$pdf->MultiCell(0,3, $object->cf_monchamp, 0, 'L'); // printing the customfield

Attention, ceci affichera la valeur ‹ brute › du champ, c’est-à-dire que si c’est un champ contraint, vous obtiendrez l’id de la ligne SQL, ce qui peut être inutilisable.

Pour être sur de bien afficher la valeur du champ (bien converti et avec support du multilangage), il faut utiliser la fonction fournie printFieldPDF():

// Init and main vars
include_once(DOL_DOCUMENT_ROOT.'/customfields/class/customfields.class.php');
$customfields = new CustomFields($this->db, '');

// Getting the formatted value of the field
$monchampval = $customfields->simpleprintFieldPDF('monchamp', $object->cf_monchamp);

// Printing the field
$pdf->MultiCell(0,3, $monchampval, 0, 'L');

Ou sinon, si vous faites un modele ODT vous pouvez simplement utiliser le tag suivant:

{cf_monchamp}

Et cela imprimera la valeur du champ (avec formattage et support multilingue).

Et si c’est un champ contraint, vous pouvez même accéder aux champs liés dans une autre table:

{cf_monchamp_champdanslatableliee}

Exemple: si monchamp est un champ contraint sur la table llx_users, pour afficher le nom, prénom et téléphone de l’utilisateur, il suffit d’utiliser 3 tags:

[code]
{cf_monchamp_name} {cf_monchamp_firstname} {cf_monchamp_user_mobile}[/code

19

En fait j’ai récupéré votre version à jour et remis à jour conf.php avec ma base en local et c’est tout(j’étais en 3.2 Alpha)
Merci pour les explications détaillées sur l’impression.:happy:

20

Dans ce cas je vous conseille tout de même que vous utilisez bien InnoDB car le moteur MyISAM (qui est par défaut avec MySQL < 5.5) manque de fonctionnalités critiques, surtout les contraintes d’intégrité.

En gros, ça peut marcher avec MyISAM, et les bugs vont passer inaperçus, jusqu’au jour où les bugs vont s’accumuler et faire un effet boule de neige et provoquer de gros bugs incompréhensibles.

Voilà pourquoi je vous conseille de vérifier, au moins vous prendrez les devants et éviterez ce genre de complications.