I'm adding two approvals before a Dolibarr mass mailing can be sent

I contribute to Dolibarr, the open-source ERP and CRM. I am working on this now, on issue #41892: a mass mailing should need two validations, one for the message and one for the recipient list, before Send appears.

This is the change I am building. The pull request is still ahead of me.

What the screen does today

A mailing has one status: draft, validated, partially sent, or sent. Validate sits on the message card. It stays disabled until the mailing has at least one recipient, and it asks for the "Validate mailings" permission.

That click writes one stamp: status validated, date_valid, and fk_user_valid. Send appears after that single stamp. The message can still be edited. On the recipients page, adding targets is hidden once the mailing is validated, and the New button turns it back on.

One stamp covers two different facts: the text is ready, and the list of people is ready. They are not the same fact.

The shape I am using

The mailing table already has a second pair of columns, date_appro and fk_user_appro. Mailing::fetch() already loads them. Nothing in current develop writes them.

I am giving each pair one job:

• date_valid / fk_user_valid records who approved the message, and when.
• date_appro / fk_user_appro records who approved the recipient list, and when.

The status values stay the same. Send still requires status validated. Status validated now means both stamps are set.

Validating the message does not require a recipient. The mailing stays a draft until the list is validated too. Validating the list with zero recipients is refused. When the second stamp lands, status becomes validated.

This is the decision in validMessage(). The recipient method is the mirror image: it writes date_appro, and it sets status validated only when date_validation is already set.

public function validMessage(User $user)
{
    if ((int) $this->status === self::STATUS_SENTPARTIALY || (int) $this->status === self::STATUS_SENTCOMPLETELY) {
        return 0;
    }

    $now = dol_now();

    $sql = "UPDATE ".MAIN_DB_PREFIX."mailing";
    $sql .= " SET date_valid = '".$this->db->idate($now)."', fk_user_valid = ".((int) $user->id);
    if (!empty($this->date_appro)) {
        $sql .= ", statut = ".((int) self::STATUS_VALIDATED);
    }
    $sql .= " WHERE rowid = ".((int) $this->id);
    // ...
}

Editing the subject or the body clears the message stamp. Adding, deleting, or emptying the recipient list clears the list stamp. If the mailing was ready to send, it goes back to draft. The other stamp stays. A mailing that has already been sent keeps both stamps.

For installations that already have validated mailings, the migration copies the old single stamp onto the recipient columns, so those mailings remain sendable:

UPDATE llx_mailing
SET date_appro = date_valid, fk_user_appro = fk_user_valid
WHERE statut > 0 AND date_appro IS NULL AND date_valid IS NOT NULL;

Why an edit has to drop the stamp

Two DEV posts settled this for me.

Approve Emails Before Your AI Agent Sends Them by @sekeraradim argues that the send step has to depend on a human decision about the text that will actually go out and that the reviewer should be able to change the subject or the body before that decision. Read the full discussion on DEV.

Human-in-the-Loop AI Drafts in ASP.NET Core by @rahmatafridi goes one step further: an approval covers one revision, one recipient, and one set of attachments. A later change of body, subject, or recipient is a new revision and needs its own approval. Read the full discussion on DEV.

Dolibarr is not an agent inbox, and I am not adding an AI drafter. The same rule still fits a mass mailing. The approved message and the approved list are what Send is allowed to use. Change either one, and that half of the approval is gone.

What I have checked so far

On a local mailing:

• Validating the message alone leaves the mailing as a draft. Send stays hidden.
• Validating recipients with an empty list is refused.
• With both stamps set, status becomes validated and Send appears.
• Saving a changed subject returns the mailing to draft, clears the message stamp, and keeps the recipient stamp.
• Validating the message again brings Send back.

Who can see the recipient list is a different wish, #35730. The existing advanced permission that hides the Recipients tab stays as it is.

I am still on the branch. When the pull request is up, I will link it from the issue.