Computed fields in Dolibarr

A computed field is an additional field whose value is not typed in: a formula calculates it. A price including tax, a number of cartons on an order line, the third party’s trade name on a contact card.

Everything below was tested on 15 October 2026 on a fresh Dolibarr 24.0.2 install. The security rules for formulas (whitelist, allowed variables) are detailed in the note Computed field refused since Dolibarr 23: this guide sums them up and goes further.

Creating a computed field

The field is created in the setup of the module concerned: Home › Setup › Modules/Applications, gear icon of the module (Products, Orders, Third parties…), Additionnal fields tab (that is how Dolibarr spells it). For a document line, use the Additionnal fields (lines) tab.

Fill in the label, the code and the type. The type sets the display format: with the “Float” type, our price including tax showed 10.55. The formula goes into the Computed field box. Visibility decides where the field appears, and On PDF whether it is printed.

A confusion seen on the forum: “computed field” is not a type. You pick a normal type, then fill in the formula.

The rules to know

• The record of the card is $objectoffield. Its properties are read with ->: $objectoffield->price, $objectoffield->qty.
• A working variable must be named $var1, $var2… Any other variable is refused.
• To read another object: ($var1 = new Product($db)), then $var1->fetchNoCompute(id). fetch() is refused.
• Only whitelisted functions are accepted (round, min, max, abs, dol_now…).
• No dot outside a number. A text such as 'n.a.' makes the whole formula fail: “dot char is forbidden if not strictly between 2 numbers”. Write 'na'.
• No SQL query.

A refused formula shows, instead of the value, a message starting with Bad string syntax to evaluate.

Note: the example in Dolibarr’s own help does not work as is. It uses a $reloadedobj variable, which Dolibarr 24 itself refuses (“found use of $ not matching pattern”). Replace it with $var1.

Tested formulas

All were created in the interface and checked on the card.

Price including tax of a product (product field, Float type):

$objectoffield->price * (1 + $objectoffield->tva_tx / 100)

Product at 10 excl. tax, 5.5 % VAT: the card shows 10.55.

Number of cartons on an order line (order line field). The product has an integer field cond (6 per carton):

(($var1 = new Product($db)) && $var1->fetchNoCompute($objectoffield->fk_product) && ($var2 = ($var1->array_options['options_cond'] * 1)) > 0) ? round($objectoffield->qty / $var2, 1) : 'na'

Line of 12 units: 2. The result is also printed in a column of the order PDF with “On PDF” = 1 and the eratosthene template. The PDF writes it with a dot (“1.5”).

Third party trade name on a contact card (contact field):

($var1 = new Societe($db)) && ($var1->fetchNoCompute($objectoffield->socid) > 0) ? $var1->name_alias : ''

The contact card shows the third party’s trade name.

Nested conditions:

$objectoffield->id == 1 ? 'premier' : ($objectoffield->id == 2 ? 'second' : 'autre')

It works in 24.0.2. It was refused in 21.0.4 (same formula, same evaluation function: refused in 21.0.4, accepted in 20.0.4 and 24.0.2). If a formula like this fails for you, check your version.

Adding a function to the whitelist

The list is set in conf/conf.php, line $dolibarr_main_restrict_eval_methods. A fresh 24 install already writes it there: add your function at the end, without removing anything. The full procedure is in the note on the whitelist.

Tested: strtoupper($objectoffield->label) is refused, then accepted once strtoupper is added. But it leaves accented letters in lower case (“CAFé MOULU”). With mb_strtoupper added to the list, you get “CAFÉ MOULU”.

Each function you add widens what a formula can do on your server: only add what you need.

Card, list, PDF, database: where is the value?

By default, a computed field is not stored in the database: the column stays empty, even after saving the card. The formula is recalculated on each display.

• On the card and on the PDF: the value is right.
• In lists, it can be wrong. In the product list, our price including tax showed 10 instead of 10.55. In a list, the formula only gets part of the object’s properties: here, not the VAT rate. Dolibarr’s code says so itself. A formula that only reads properties loaded by the list displays correctly.

Storing the value in the database: the hidden option and its trap

Dolibarr has an option, not shown in the menus, that stores the result of formulas: MAIN_STORE_COMPUTED_EXTRAFIELDS. To enable it: Home › Setup › Other Setup, name MAIN_STORE_COMPUTED_EXTRAFIELDS, value 1, Add. In the field form, the words “Store computed field” then appear next to the formula, with a warning.

What we saw:

• the formula is calculated when the card is saved, and the result is written to the database;
• the list then shows the stored value, which is right (10.55);
• existing records stay empty until they are saved again;
• Dolibarr warns about it itself: the value is only recalculated when the object is modified. If the formula depends on another object (the product’s pack size, for example), the stored value becomes wrong when that other object changes.

The trap: a single formula in error blocks saving all the additional fields of the card. With the option on and one refused computed field on products, we changed a normal field (the pack size, from 6 to 8). Saving failed with “Data too long for column ‘ancien’ at row 1”, and the change was lost. The formula’s error message is too long to fit in the column. Once the refused formulas were fixed or deleted, everything saved normally.

Before enabling this option, open a record of each type concerned and check that no computed field shows “Bad string syntax to evaluate”.

What a computed field can no longer do

A sum or a query over other records, such as a member’s total subscriptions or an average payment delay, is no longer possible. SQL queries are refused. The solutions live in a module:

• a trigger that calculates the value and writes it to a normal field when the object changes;
• a scheduled job that recalculates it;
• a function provided by the module, added to the whitelist (see the note on the whitelist).

What we did not test

• Other versions in the interface: the 20.0.4 and 21.0.4 comparisons cover the evaluation function only, with the same formulas.
• PDF templates other than eratosthene.
• The MAIN_STORE_COMPUTED_EXTRAFIELDS option with several entities (multicompany), and adding a document line through the interface with this option.

Summary

• A computed field = a normal type + a formula in “Computed field”.
• $objectoffield for the record, $var1 for another object, fetchNoCompute(), no dot in texts, no SQL.
• The example in Dolibarr’s help uses $reloadedobj: replace it with $var1.
• The value is right on the card and the PDF, sometimes wrong in lists, absent from the database.
• MAIN_STORE_COMPUTED_EXTRAFIELDS stores it, but a formula in error then blocks saving the whole card.

If a formula keeps failing, the €90 diagnosis means looking at your instance with you for one hour, then giving you in writing the cause and what the fix would cost.