Champ calculé refusé depuis la version 23

Depuis la version 23, un champ calculé ne peut plus appeler n'importe quelle fonction, ni faire d'include, ni concaténer avec un point. Les règles exactes, les messages, et la façon propre d'appeler le code d'un module.

Versions concernées
Dolibarr 23 et 24 · pas de liste blanche en 22 · testé en 22.0.5, 23.0.4 et 24.0.1
Ce qui a été vérifié
Testé le 4 octobre 2026 sur des instances 22.0.5, 23.0.4 et 24.0.1 : une vingtaine de formules passées par la même fonction que les champs calculés, avec plusieurs listes blanches ; fiche d'un tiers avec de vrais champs calculés en 22.0.5 et 24.0.1 ; ligne ajoutée dans conf.php en 24.0.1. Liste par défaut lue dans le code officiel (23.0.0 à 24.0.2), fonction d'évaluation identique de 24.0.0 à 24.0.2. Journal officiel des modifications de la 23.0.

Vous avez un champ supplémentaire calculé. Sa formule marchait en version 22. Après le passage en 23 ou en 24, le champ affiche à la place un message qui commence par Bad string syntax to evaluate.

Ce n’est pas un bug. La version 23 a durci les règles des formules, pour des raisons de sécurité : une formule est du code PHP exécuté par le serveur.

Les règles depuis la version 23

1. Les fonctions et les méthodes doivent être sur une liste blanche. Elle se règle dans conf/conf.php, par le paramètre $dolibarr_main_restrict_eval_methods. Toute autre fonction est refusée avec ce message :

A function or method "fetch" was called and is not into the parameter
$dolibarr_main_restrict_eval_methods of white-listed functions and methods

Si ce paramètre n’est pas dans votre conf.php, la liste utilisée en 24 est : getDolGlobalString, getDolGlobalInt, getDolCurrency, getDolEntity, getDolDBType, fetchNoCompute, hasRight, isAdmin, isExternalUser, isModEnabled, isStringVarMatching, abs, min, max, round, dol_now, preg_match. En 23, c’est la même liste sans isExternalUser. S’il est dans votre conf.php, c’est sa liste qui compte. Une installation neuve en 24 par l’assistant l’y écrit déjà, avec dolSort en plus et sans isExternalUser.

Cela vaut aussi pour les méthodes : fetch() est refusé, mais fetchNoCompute() est accepté ; $langs->trans() est refusé, car trans n’est pas dans la liste.

2. Les variables sont limitées. L’objet courant s’écrit $objectoffield. Une variable de travail doit s’appeler $var suivi d’un nombre : $var1, $var2. Une variable comme $stock est refusée, et le message d’erreur donne la liste des variables acceptées ($langs, $mysoc, $user->hasRight, ($db)…).

3. include et require sont refusés, dol_include_once compris. Une formule ne peut donc plus charger le fichier d’une classe.

4. La concaténation avec le point est refusée. Pour assembler deux textes, utilisez dol_concat(texte1, texte2) après avoir ajouté dol_concat à la liste blanche, comme l’indique le journal des modifications de la 23.

5. new Classe($db) n’est accepté que pour une classe déjà chargée, et qui hérite de CommonObject, la classe de base des objets de Dolibarr.

Appeler le code d’un module : la voie propre

Si votre formule doit lire une donnée calculée par un module, passez par une fonction simple.

  1. Le module fournit une fonction, par exemple monmodule_valeur($id), qui lit l’objet et renvoie la valeur.
  2. Ajoutez cette fonction à la liste blanche dans conf/conf.php. Si la ligne $dolibarr_main_restrict_eval_methods existe déjà, ajoutez votre fonction à la fin de cette ligne, sans rien retirer. Sinon, recopiez d’abord la liste ci-dessus, puis ajoutez votre fonction à la fin : dès que vous écrivez le paramètre, votre liste remplace la liste par défaut en entier.
  3. La formule devient simplement : monmodule_valeur($objectoffield->id).

La fonction doit déjà être chargée au moment du calcul, puisque la formule ne peut pas faire d’include : sinon, le champ affiche « Exception during evaluation ». C’est au module de charger le fichier qui la contient.

Ne videz pas la liste pour « débloquer » une formule. Une liste vide désactive la liste blanche : Dolibarr se rabat sur une liste noire de fonctions interdites, et accepte de nouveau des appels qu’il refusait.

Comment cela a été vérifié

Sur des instances 22.0.5, 23.0.4 et 24.0.1 de test, avec la même fonction que les champs calculés :

  • en 22.0.5, ->fetch(), dol_include_once(), une variable libre et la concaténation passent ;
  • en 23.0.4 et 24.0.1, ils sont refusés ; $objectoffield->name, $var1 et ->fetchNoCompute() passent ;
  • dol_concat() et une fonction de test sont refusés, puis acceptés une fois ajoutés à la liste ;
  • avec une liste réduite à la fonction de test, getDolGlobalString devient refusé ;
  • avec une liste vide, ->fetch() redevient accepté.

Sur la fiche d’un tiers en 24.0.1, les champs calculés refusés affichent bien le message « Bad string syntax to evaluate… ». Les autres pièges de mise à jour sont dans Mettre à jour Dolibarr sans casse.

Si votre formule ne passe toujours pas

Si vous ne trouvez pas quelle règle bloque votre formule, ou si elle dépend d’un module que vous ne maîtrisez pas, le diagnostic à 90 € consiste à regarder votre instance avec vous pendant une heure, puis à vous remettre par écrit la cause et ce que coûterait la correction.

Dolibarrchamp calculéextrafielddol_evalrestrict_eval_methods2324