`mail_tracking` technical debt and roadmap

[ivantodorovich]

Hello 👋🏻

From my PoV there's a big technical debt in this module, with many features overlapping with the standard. So, perhaps it's a good idea to discuss and come up with a clearer roadmap.

From what I can see, this module contains the following features.

I put my analysis on each, but this is just to open the discussion. I'm biased because I really only care about the event tracking feature -- all the rest is not useful to me.

1. Track email events (⭐ main feature)

Adds the “To:” section to every email in the chatter.
The status icon quickly shows whether the email has been sent, received, opened bounced, or failed.
Clicking on the name/icon, it expands the tracking model to show all tracking events related to this email, for that recipient.
The captured event shows how many times the email was opened, at what time, and from which IPs.

Odoo core alternative

❌ -- Nothing like this

Although events related to sending failure and bounces are also captured by Odoo.
So perhaps this module should only track user events.

Thoughts

• Keep, but focused on user events

2. Add the Failed Messages section in chatter

A new section above the thread messages to quickly spot any failed messages.

From there, users can:

• Set as Reviewed (ignore this alert)
• Retry (re-send)
• Go to the message (to see it)

Odoo core alternative

There’s no section like this, but failed messages have a red envelope.

This red envelope helps identifying messages that haven’t been delivered and can be clicked to show a popup that let users:

• Re-send the email
• Ignore the exception

Thoughts

• ❌ Drop this feature. Overlaps with core.
• Alternatively, move to a separate mail_chatter_failed_messages module, basing the computation on top of the core features instead of mail_tracking. ❓

3. Failed messages mail box in Discuss App

Adds a “Failed” mailbox to quickly see all failed outgoing emails send by the current user.

Odoo core alternative

❌ -- Nothing like this

Thoughts

• ❌ Drop feature
• Alternatively, refactor to compute on top of the core mail.notification model and move to a separate module (e.g: mail_failed_mailbox) ❓

4. Failed messages filter

To every model having a chatter, it adds a “Failed sent messages” filter to easily spot records with unmanaged failed messaged.

Odoo core alternative

Odoo will create a notification for the Email Failure, directly from the discuss app.
The notification can then be handled by the user

Thoughts

• ❌ Drop feature
• Alternatively, refactor to compute on top of the core mail.notification model and move to a separate module (e.g: mail_failed_filter) ❓

5. Email Score and Email Bounced fields

In the res.partner model, there are two new fields used to analyze a partner’s email deliverability.

The score is computed by aggregating the email tracking events data.

Odoo core alternative

Odoo does things differently, perhaps smarter, and invisibly.

Every partner has a message_bounce (Integer) field, which tracks the number of bounced emails.

This counter is reset when an email is successfully delivered, or when an email is received from this address. Meaning, it actually tracks the number of bounced emails in a row.

When an email is sent from a thread to a partner who’s emails have bounced more than 5 times in a row (BLACKLIST_MAX_BOUNCED_LIMIT), then it automatically blacklists this email to not send any more mails to them.

Blacklisted emails show with a prohibited icon (🚫) in the partner form, with a tooltip: “This email has been automatically added in blocklist because of too much bounced”

Thoughts

• Not clear. From my POV this is not useful.

6. Email bounced contact’s filter

There’s an “Email Bounced” res.partner filter that shows partners whose email address have been used to try to send an email that finally bounced. Meant to help identify mistakes in the partner’s email addresses.

Odoo core alternative

There’s no pre-defined filter, but it’s possible to search on the fields message_bounce (number of bounced emails in a row, 0 if the last email succeeded).

There’s also the is_blacklisted field, which could be used in combination to know if the email has been blacklisted due to bounced emails.

Thoughts

• ❌ Drop feature
• Alternatively, refactor to use the core fields and move to a separate module (e.g: mail_bounced_filter) ❓

[diggy128]

I totally agree with removing duplicated functionality (and moving to separate modules if someone wants it).
Dealing with the chatter is complicated enough to train new employees and having two routes in the workflow for overlapping features leads to unexpected results.

[pedrobaeza]

I don't agree that some functionalities are duplicated, and they are all related to the mail tracking task. They are there as a way to fill a gap in the existing core features. For example, having to scroll to find the red envelopes is not a viable alternative to have all of the failed messages summarized and located at the top as a critical thing to repair. And I don't want that to be an extra module, as the interfaces required to connect everything will require more code than the feature itself.

[AquaMCU]

I agree with Ivan. We should keep it as simple as possible. Question: Ivan can you upgrade and contribute to bring it into ODOO 19? I think it is a good time to implement the changes. I can help by testing on ODOO 19.

[ivantodorovich]

I don't agree that some functionalities are duplicated, and they are all related to the mail tracking task. They are there as a way to fill a gap in the existing core features. For example, having to scroll to find the red envelopes is not a viable alternative to have all of the failed messages summarized and located at the top as a critical thing to repair. And I don't want that to be an extra module, as the interfaces required to connect everything will require more code than the feature itself.

In the current status of the module, a split would be very difficult -- I agree.
However, most features could (& maybe should) be refactored to use core's mail.notification as a base, rather than trying to re-implement it. In which case a split would be much much simpler, as each feature would be pretty much isolated

Question: Ivan can you upgrade and contribute to bring it into ODOO 19? I think it is a good time to implement the changes. I can help by testing on ODOO 19.

To be honest, we finally decided to stop using this module for the project that motivated raising this issue -- so I'm not longer actively working on it.

[pedrobaeza]

It's true that the features have been there for a long time, where they were built more or less from scratch (as Odoo itself didn't have the features), so any refactoring could alleviate the amount of code, but the latest migrations have been done to only get the features working without investigating a whole refactor.