The following changes were implemented:
1 - Added Failed Message component and related components to reuse the
Message component when rendering failed messages. This allows us to
dispose of the messagefailed JS model altogether, since failed messages
are now just regular messages that were marked as failed.
2 - Added Owl reactivity to failed message actions so that browser does
not have to be reloaded each time a message is marked as reviewed or
resent.
3 - Fixed 'Retry' and 'Set as reviewed' flows for failed messages.
4 - Fixed `Failed sent messages` filter on models by overriding `get_view`
instead of `_fields_view_get`
5 - Refactored folder structure to more closely resemble the `mail`
module's folder structure.
6 - Refactored module to utilize `Command` as a means to create, write,
etc. instead of `[0, ...]`, `[4, ...]`.
7 - Fixed and added unit tests.
8 - Removed dead/unused code from `v15`.
- As the tracker img in the body is currently also used to set the
X-Odoo-MailTracking-ID mail header we can remove the tag only
after this is done
- Added tests to check for the presence and absence of the tracking
image tag depending on the new configuration parameter
In the forward port of the permission check, a column was dropped from
the tuple, but the following code wasn't adapted to the new tuple
length. For clarity sake we also name the tuple unpacking into proper
variables.
TT43453
If a user tries to read a thread on a record and one message is from a
partner on which he has no permissions, there will be an exception as
this method tries to fetch info from such partner.
TT43075
Refine which mail tracking record is allowed to see. We can rely on the
ACLs of the related records so we minimize inconvenient message subject
leaks.
A regular user can read these mail.tracking.email records:
- Those with a linked mail.message that the user can read
- Those with a linked mail.mail that the user can read
- Those with no message/mail link but a linked partner that the user can
read.
- Those with no linked records.
TT31399
Up until now, the `sent` event type was never processed, probably because it "made no sense", as an unsent email would never trigger an event.
However, it makes sense to process it because you may have a local relay that transmits mails over to the mail provider. In those circumstances, you should have 2 "sent" events (one from the relay and another one from the provider).
Also marked some useless parts of code for removal.
@Tecnativa TT32365
Mass mailing are tracked from mail.trace as the don't store a message in
the db. In order to gather the message_id and be able to do manual
checks to mailgun, that's the table where we should get the message id.
TT40816
Before this commit, some methods with views crashes trying to
process 'failed_message_ids' field.
After this commit the 'failed_message_ids' field description
is properly generated.
Previous this commit, failed messages widget data wasn't updated properly when you
set as reviewed/retry the last message displayed.
This commit resolve the problem and improves the "set as reviewed" action to avoid
multi-user inconsistencies (don't toggle the value).
- Any model inheriting from mail.thread will have a filter available to
obtain records with errors in their messages trackings.
- The messages can be marked as done to avoid false positives when the
issues are solved.
On our server,
queries based on "mail_tracking_event"."tracking_email_id" improved from 501,924 ms to 1,840 ms
queries based on "mail_tracking_email"."mail_message_id" improved from 167,436 ms to 3,223 ms
The last ones are run several times when a thread has many messages
payen000
filoquin
David
dhx
Thierry Ducrest
sergio-teruel
jb
Jairo Llopis
EAJGlobal
Jasmin Solanki
houssine
simonev
Areeb Siddiqi
Alexandre D. Díaz
nmadhoc
Wolfgang Pichler
Pedro M. Baeza
ernesto
eLBati
Antonio Espinosa
Pedro M. Baeza