[19.0] mail_composer_cc_bcc: Migration to 19.0

[cyrilmanuel]

No description provided.

[bosd]

@etobella Can you please merge?

[tuffstuff9]

LGTM

[visionsrlsolution]

When merge? any ETA? thx

[StefanRijnhart]

/ocabot migration mail_composer_cc_bcc

[StefanRijnhart]

Method was renamed: odoo/odoo@e147c778ebbd0#diff-e46e2629963b0ad64aed7a7b02f49caea5bfacd952b77abcb2954f2437c9222aL668-R646. This implies a missing test.

[davidepedraii]

Hello, we are experiencing some issues in the Version 19 of Odoo.sh , the issue is that: When sending emails with the BCC Module, we found an issue that when sending an email we encountered that the destination email didnt apparently exist, even if it exist and we have control of it, moreover the email resulted sent from Microsoft Outgoing email, but never recieved from the destination.

[giusybloomup]

When merge?
LGTM
thx :-)

[StefanRijnhart]

@giusybloomup When the code is fixed

[NICO-SOLUTIONS]

Reviewing prepare_email_message_ override and updated hash

[NICO-SOLUTIONS]

Suggested change

	def _prepare_email_message(self, message, smtp_session):
	def _prepare_email_message__(self, message, smtp_session):

[NICO-SOLUTIONS]

An extra double underscore was added to the method

[NICO-SOLUTIONS]

Suggested change

	"mail.composer:_compute_partner_ids": ["4e49f0d6c53f41ac24b02176e97b600a"],
	"mail.composer:_compute_partner_ids": ["c3903ab78bf2e5d9aba078ac2689d974"],

[NICO-SOLUTIONS]

Updated hash to match the current upstream _compute_partner_ids

[NICO-SOLUTIONS]

Suggested change

	smtp_from, smtp_to_list, message = super()._prepare_email_message(
	smtp_from, smtp_to_list, message = super()._prepare_email_message__(

[NICO-SOLUTIONS]

Call updated prepare_email_message_ method with extra double underscore

[Linekio]

Hi,
Bcc mails doesn't works, even after renaming this method.

[NICO-SOLUTIONS]

@Linekio

Could you be a bit more specific? Please describe what happens, what you expected, and what you’ve already tried.

[Linekio]

Sorry, it seems to be working, but it's sending multiple emails.

I did this test:

There are three identicals emails sent to acme_corp and brandon freeman, but not colleen diaz

Furthermore, the X-Odoo-Bcc header should be removed before sending. Recipients should not be able to identify hidden recipients simply by reading the header.

See odoo/odoo@2445f9e

[NICO-SOLUTIONS]

@Linekio
I just quickly looked over the code again, and I think you are raising a valid concern.

The X-Odoo-Bcc handling seems questionable: the code reintroduces the value as a Bcc email header (message["Bcc"] = x_odoo_bcc_value) before sending. This looks like it could reintroduce the BCC leak that was fixed in Odoo core.

The smtp_to_list = [smtp_to] handling also looks suspicious. Combined with mutating recipients via pop(0), this could be related to the reported duplicate emails.

@cyrilmanuel
Could you please have another look at this part? It seems the implementation may need another pass to align with Odoo's current BCC handling (BCC should remain only part of the SMTP recipient list and should not be exposed in the outgoing message headers).

[Borruso]

LGTM

[StefanRijnhart]

@Borruso if this looks good to you, then you weren't looking very closely

[Borruso]

@StefanRijnhart @NICO-SOLUTIONS

camptocamp#1

[skanndar]

I tested this branch on a clean 19.0 database and the Bcc feature does not work at all: the Bcc recipients never receive the email. Reproduction and root cause below — sorry for the late review, and thanks for keeping this module alive.

Setup: official odoo:19 image (build 19.0.20260723), fresh database, only this module installed. The SMTP session is replaced by a stub recording exactly what Odoo hands to the server (send_message(message, smtp_from, smtp_to_list)), so the envelope and the headers below are the real ones.

Scenario: composer on a record, To = to@example.com, Cc = cc1@example.com, Bcc = bcc1@example.com + bcc2@example.com.

Result: 3 emails handed to the server, with envelopes [cc1@], [to@], [cc1@]. Neither Bcc address ever appears in an envelope, and cc1@ gets two copies.

1. The ir.mail_server override never runs on 19.0. It defines _prepare_email_message, but 19.0 renamed that method to _prepare_email_message__ (odoo/addons/base/models/ir_mail_server.py). Nothing calls the old name any more, so neither the X-Odoo-Bcc → Bcc translation nor the context['recipients'] envelope restriction ever happen. Without a Bcc header, _prepare_smtp_to_list() — which builds the envelope from To/Cc/Bcc — simply never yields the Bcc addresses, hence the silent loss.

On 19.0 the envelope is already restricted by the send_validated_to context key that MailMail._send() fills with the normalized recipient of each email, so the override can be dropped in favour of setting a real Bcc header on the Bcc recipient's own email only. _alter_message__() strips that header right after building the envelope, so it is never transmitted.

2. The headers dict is shared by every email of the batch. In _prepare_outgoing_list(), m["headers"].update({"X-Odoo-Bcc": ...}) mutates the same dict instance that all the other emails received, so after the loop every email carries the last Bcc address. In my run all four prepared emails ended up with X-Odoo-Bcc: "B2" <bcc2@example.com>. Copying instead of mutating fixes it:

m["headers"] = {**m["headers"], "Bcc": m["email_to"][0]}

3. X-Msg-To-Add (new in 19.0) puts the Cc and Bcc addresses into the To header, once delivery works. MailThread._notify_by_email_get_headers() adds every external recipient to X-Msg-To-Add, and IrMailServer._alter_message__() merges that header into To at send time to enable Reply-All. It does not show up on this branch because the Bcc emails are never sent — but as soon as point 1 is fixed it does. I verified it A/B on a fixed version: dropping the header, each email carries the intended To/Cc; keeping it, every recipient (including the plain To one) receives To: to@…, cc1@…, bcc1@…, bcc2@…. Since this module builds the whole To/Cc itself, dropping it in _prepare_outgoing_list() looks like the right call:

headers = {k: v for k, v in m["headers"].items() if k != "X-Msg-To-Add"}

A related detail: when mail.email_to is empty Odoo builds an extra Cc-only email, which is a duplicate here (this is what #233 addresses on 18.0) — that is where the second copy to cc1@ comes from.

Points 1 and 2 apply to #163 and #189 as well, since all three migrations carry the same code.

I have a 19.0 version with the three fixes and tests covering them running on a real database. Happy to push it here as commits, or to open it wherever you prefer — whatever helps this land.

[NICO-SOLUTIONS]

@skanndar
Feel free to push your version as commits. We can review it directly there.

[skanndar]

Thanks @NICO-SOLUTIONS — pushed: camptocamp#2, against the branch of this PR.

It is built on top of @Borruso's camptocamp#1 (his commit is included unchanged: renaming the override to _prepare_email_message__ and copying the headers dict is what makes the Bcc emails reach the server at all). On top of that, two commits' worth of changes in one:

• The last recipient was silently losing its email. The Cc-only entry Odoo builds when mail.email_to is empty was being dropped with if len(res) > len(recipients): res.pop(), but recipients is a set in which a Cc partner is counted once, so the count is short and pop() removes the last entry instead of the duplicate. With one To, two Cc and two Bcc: cc1@ got two copies and bcc2@ got nothing.
• X-Msg-To-Add dropped, as described in my review: 19.0 merges it into To at send time, which puts the Cc and Bcc addresses in everyone's To.

Plus two tests that fail before and pass after, and the existing suite green. The reproduction is the same setup as my review: official odoo:19 image, fresh database, SMTP session replaced by a stub that records exactly what Odoo hands to the server.

Happy to rebase onto this branch alone if you prefer #1 to be merged separately first.