Duplicate finder

The module compares your records on criteria that you choose, and shows you groups of records that are genuinely identical once the formatting is stripped out.

What it can scan: third parties, contacts and addresses, and — if the Members module is enabled — members.

The criteria:

Matching is strict equality after normalisation, not a similarity score. Two records are only grouped if one of their values is genuinely identical. So there is no “duplicate probability” to interpret, and empty fields never form a group.

The scan is read-only. Nothing is changed until you have chosen a record to keep, ticked a record to merge, clicked and confirmed.

The module merges the three objects it scans. The path is not the same for third parties as for the other two.

Third parties

For a third party, the module relies on Dolibarr’s native merge. The duplicate’s quotes, orders, invoices, contacts, categories and attached documents are moved to the record you keep, whose empty fields are filled in with those of the duplicate. The duplicate is then deleted.

Contacts and members

Dolibarr cannot merge contacts, and has only merged members since version 23: two duplicate contacts have to be copied over and deleted by hand, hoping nothing was missed. The module writes this merge itself.

Everything that pointed to the deleted record is moved to the kept record:

The empty fields of the kept record — address, phone numbers, job title, date of birth, social networks — are filled in with those of the duplicate, and the two notes are joined end to end. The kept record keeps its own link: merging two contacts held by two different third parties does not touch the third parties.

The operation runs in a transaction. If a single step fails, nothing is applied: both records stay in place and a message says so.

When the kept record already carries the same link as the duplicate — the same category, the same link to a third party, a contribution with the same date — the duplicate’s redundant row is set aside rather than making the operation fail.

In both cases

It is an irreversible operation. The module asks for an explicit confirmation that says so, requires the Dolibarr create and delete permissions on the object concerned in addition to its own permission, and re-checks both records on the server before writing anything.

The screen fits on one page, under Third partiesDuplicates.

At the top, the object to scan and the criteria checkboxes. The Scan button displays a banner such as “3 duplicate group(s) found, covering 6 record(s) out of 14 scanned.”, then one table per group.

Each group shows as its title the criteria that matched these records, and lists the records with their clickable name, email, phone, identifiers and town. A “Keep” column and a “Merge” column let you designate the master record.

In the screenshot, group 1 matches “Cabinet Vaillant” and “SARL Cabinet Vaillant” on all four criteria at once, even though their emails are not written with the same case and their phone numbers are not entered in the same format.

The choice of object changes the list scanned and the criteria offered. On Contacts / addresses, each group matches the same person entered several times — often on two different third parties — and carries the same merge button.

The setup page brings together the two safeguards, the history setting and the table of merges already carried out.

The second setting is the one that prevents the giant false group: without it, a switchboard number 03 88 00 00 00 shared by forty records of the same local authority would form a group of forty “duplicates”.

• Read-only scan. No write is possible from the scan screen without going through the merge button and its confirmation.
• A dedicated permission, “Use duplicate finder”.
• Dolibarr’s standard permissions on top: merging requires create/modify and delete on the object. Without the delete permission, the scan can still be viewed and the merge buttons are not displayed; a message explains why.
• Server-side re-check: the identifiers sent by the form are never taken at face value, both records are read again within the authorised scope.
• Multi-company: scan and merge limited to the authorised entities.
• External users: an account linked to a third party only sees its own record; members are never visible to it.
• Every merge is written to Dolibarr’s logs and to the module’s history.

• One table is added: llx_dolixdoublons_log. It only contains the merge history.
• The scan only reads a minimal set of columns — name, email, phone numbers, identifiers, town — and writes them nowhere.
• The only possible write is the merge that you trigger.
• No outgoing connection: nothing is sent anywhere.