Computed field rejected since version 23

Since version 23, a computed field can no longer call any function, include a file or concatenate with a dot. The exact rules, the messages, and the clean way to call a module's code.

Versions concerned
Dolibarr 23 and 24 · no whitelist in 22 · tested in 22.0.5, 23.0.4 and 24.0.1
What was checked
Tested on 4 October 2026 on 22.0.5, 23.0.4 and 24.0.1 instances: about twenty formulas run through the same function as computed fields, with several whitelists; third-party card with real computed fields in 22.0.5 and 24.0.1; line added to conf.php in 24.0.1. Default list read in the official code (23.0.0 to 24.0.2), evaluation function identical from 24.0.0 to 24.0.2. Official 23.0 changelog.

You have a computed extra field. Its formula worked in version 22. After moving to 23 or 24, the field shows instead a message starting with Bad string syntax to evaluate.

It is not a bug. Version 23 tightened the rules for formulas, for security reasons: a formula is PHP code run by the server.

The rules since version 23

1. Functions and methods must be on a whitelist. It is set in conf/conf.php, with the $dolibarr_main_restrict_eval_methods parameter. Any other function is rejected with this 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

If this parameter is not in your conf.php, the list used in 24 is: getDolGlobalString, getDolGlobalInt, getDolCurrency, getDolEntity, getDolDBType, fetchNoCompute, hasRight, isAdmin, isExternalUser, isModEnabled, isStringVarMatching, abs, min, max, round, dol_now, preg_match. In 23, it is the same list without isExternalUser. If it is in your conf.php, its list is the one that counts. A new installation of 24 with the wizard already writes it there, with dolSort added and without isExternalUser.

This also applies to methods: fetch() is rejected, but fetchNoCompute() is accepted; $langs->trans() is rejected, because trans is not on the list.

2. Variables are limited. The current object is written $objectoffield. A working variable must be called $var followed by a number: $var1, $var2. A variable such as $stock is rejected, and the error message gives the list of accepted variables ($langs, $mysoc, $user->hasRight, ($db)…).

3. include and require are rejected, dol_include_once included. A formula can therefore no longer load a class file.

4. Concatenation with a dot is rejected. To join two texts, use dol_concat(text1, text2) after adding dol_concat to the whitelist, as the 23 changelog says.

5. new Class($db) is only accepted for a class that is already loaded, and that inherits from CommonObject, the base class of Dolibarr objects.

Calling a module’s code: the clean way

If your formula must read a value computed by a module, go through a simple function.

  1. The module provides a function, for example mymodule_value($id), which reads the object and returns the value.
  2. Add this function to the whitelist in conf/conf.php. If the $dolibarr_main_restrict_eval_methods line already exists, add your function at the end of that line, without removing anything. Otherwise, first copy the list above, then add your function at the end: as soon as you write the parameter, your list replaces the default list entirely.
  3. The formula simply becomes: mymodule_value($objectoffield->id).

The function must already be loaded when the field is computed, since the formula cannot include anything: otherwise, the field shows “Exception during evaluation”. It is up to the module to load the file that contains it.

Do not empty the list to “unblock” a formula. An empty list disables the whitelist: Dolibarr falls back to a blacklist of forbidden functions, and accepts again calls it used to reject.

How this was verified

On 22.0.5, 23.0.4 and 24.0.1 test instances, with the same function as computed fields:

  • in 22.0.5, ->fetch(), dol_include_once(), a free variable and concatenation pass;
  • in 23.0.4 and 24.0.1, they are rejected; $objectoffield->name, $var1 and ->fetchNoCompute() pass;
  • dol_concat() and a test function are rejected, then accepted once added to the list;
  • with a list reduced to the test function, getDolGlobalString becomes rejected;
  • with an empty list, ->fetch() is accepted again.

On a third-party card in 24.0.1, the rejected computed fields do show the message “Bad string syntax to evaluate…”. The other upgrade pitfalls are in Dolibarr upgrade: checklist and upgrade path.

If your formula still does not pass

If you cannot find which rule blocks your formula, or if it depends on a module you do not control, the €90 diagnosis is about looking at your instance with you for one hour, then giving you in writing the cause and what the fix would cost.

Dolibarrcomputed fieldextrafielddol_evalrestrict_eval_methods2324