# Dolibarr Dummy Data & Database Synchronization Investigation Report

**Date:** June 24, 2026
**Subject:** Investigation into the perceived synchronization of "serialized dummy company records" across `aircrm`, `crmcbeezai`, and `nfinitycrm`.

---

## 1. Issue Description
It was observed that multiple Dolibarr instances (`aircrm`, `crmcbeezai`, and `nfinitycrm`) seemed to contain identical Third Party company data, specifically what appeared to be serialized (sequential) dummy company records. The primary concern was determining how this data was created and whether the databases were inadvertently synchronized or sharing tables.

## 2. Investigation Findings

A thorough verification script (`/var/www/html/check_sync.php`) was created and executed to compare the exact contents of the `llx_societe` (Third Party) tables across all three databases.

**Key Findings:**
1. **No Database Synchronization:** The databases are entirely independent. 
   - `aircrm` contains 43 companies.
   - `crmcbeezai` contains 49 companies.
   - `nfinitycrm` contains 188 companies.
   There is **no** exact match of company data shared across all three databases.

2. **The "Serialized" Dummy Data:** A search for structural serialization (like PHP serialized strings or JSON) within the database fields yielded no results. However, records matching the format `Company num [TIMESTAMP]` (e.g., `Company num 17815140218`) were identified in `crmcbeezai` and `nfinitycrm`. 
   - These are sequentially (serially) generated dummy records.
   - Because they follow an identical naming pattern, they give the false impression that data is synchronizing across the databases. In reality, they are locally generated in each database.

## 3. Root Cause Analysis

The dummy records were generated by Dolibarr's native developer testing tool:
`/var/www/html/<instance_name>/dev/initdata/generate-thirdparty.php`

**How it was triggered:**
Initially, it was suspected that a web crawler might have triggered this script. However, after verifying the Apache configuration, the web DocumentRoot correctly points to `htdocs/`. Because the `dev/` directory is outside of the web root, it returns a 404 Not Found if accessed via a browser, making it impossible for a web bot to trigger it.

Since the script can only be run locally via the server's command-line interface (CLI) and you confirmed you did not run it, there are only three ways these records were injected:
1. **Automated Deployment/Cron Scripts:** Another automated process or deployment script on the server (perhaps configured under a different user like `root` or `ubuntu`) executed `php dev/initdata/generate-thirdparty.php` during setup or maintenance on those specific dates.
2. **Another Developer:** Someone else with SSH/terminal access to the server manually executed the script for testing purposes on June 13 and June 15.
3. **Database Import:** The databases were imported or restored from an SQL dump that already contained these generated dummy records from a previous testing environment.

In all cases, the script's behavior of generating sequential timestamps (`Company num [TIMESTAMP]`) makes the data look synced, but it was simply generated locally.

## 4. Remediation & Security Steps

To clean up the environment and secure it for production, the following steps must be taken:

### Step A: Clean Up Dummy Data
The generated dummy records (`Company num...`) can be safely deleted via the Dolibarr user interface or by directly querying the `llx_societe` table.

### Step B: Remove Developer Tools (CRITICAL)
The `dev/` and `install/` directories must be entirely removed from all production deployments to prevent bots from executing developer scripts.
```bash
rm -rf /var/www/html/aircrm/dev /var/www/html/aircrm/htdocs/install
rm -rf /var/www/html/crmcbeezai/dev /var/www/html/crmcbeezai/htdocs/install
rm -rf /var/www/html/nfinitycrm/dev /var/www/html/nfinitycrm/htdocs/install
```

### Step C: Configure for Production
Ensure that the `conf.php` files for each instance (located in `htdocs/conf/conf.php`) are strictly configured for production:
1. `$dolibarr_main_prod='1';` (Turns off testing mode and suppresses system errors/paths from public view).
2. `$dolibarr_main_force_https='1';` (Enforces SSL encryption, assuming certificates are active).
3. Apply read-only permissions to `conf.php` (`chmod 444 conf.php`) to prevent unauthorized modifications.