Purpose
=======
Currently, only email sending can be scheduled with the `scheduled_date` field
defined on on <mail.mail>. It's not possible to delay the sending of
notifications.
We want to be able to delay the sending of the emails, but also the inbox
and bus bus notifications.
Technical
=========
For that purpose, we created a new model which stores the message we need to
notify with the scheduled date. When a scheduled_datetime is given we skip the
notification process. Instead an entry in that new model is created. A cron
regularly polls the scheduled message and launch the notification process on
messages that are ready to be sent.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Currently only an email action based on template exists in server actions when
having mail app installed. It basically sends an email based on a mail template.
However being able to post a message on record is also useful. Instead of
sending emails it post on a document as a comment or as a note, like what
users can do using the chatter. Notification flow for those cases is the
classic from post: followers, specified partners, Inbox/Email, ...
Task-2613245 (Server actions mail update / cleaning)
Closes#45640
Part-of: odoo/odoo#75906
Purpose of this commit is to add tests on ``failure_reason`` usage of
notification model. Tests already exists for MailMail and other fields
but not that specific one. Followup of odoo/odoo@d895f3514e
New tests are added to check the usage of email_to and email_cc when
sending emails. Notably wrong usage of email_cc (lost formatting, copy
of all sent emails) is asserted to be fixed afterwards.
A performance test about batch sending is also added.
Prepares Task-2684479 (Mail: Better send error storage and display)
Part-of: odoo/odoo#96223
Purpose is to ease addition of new tests related to email sending, notably
to check failure reasons.
Prepares Task-2684479 (Mail: Better send error storage and display)
Part-of: odoo/odoo#96223
TestMail holds a tool to create test records in batch, notably with inline
partner creation. Allow its usage in some sub modules and tests depending
directly from the base mail test class. This allows notably usage of this
tool in performance tests (see enterprise PR).
Also explicitly set some test data to ease sub tests writing.
Prepares Task-2150462 (Mass Mailing: Unsubscribe flow improvement)
Part-of: odoo/odoo#94660
Purpose
=======
Improve the performance of mass mailing by removing the <mail.mail>, in
batch, all at once. The unlink operation is very expensive for the ORM,
in terms of SQL queries.
A new field `to_delete` is required to know which <mail.mail> we need
to delete. The reason is that the `failure_type` is stored on the
<mail.notification>, and it's possible to have <mail.mail> without
<mail.notification>.
Task-2587345
Part-of: odoo/odoo#73271
Purpose
=======
In this commit, we will fix the loops that occur when you send an email
to an alias (to create a ticket e.g.). In that case Odoo can reply
"Your ticket has been created" and then the auto-replier of the user
can reply to this email and the loop occurs.
Specifications
==============
To solve this issues, we add 2 system parameters
- <mail.gateway.loop.minutes>, 120 minutes by default
- <mail.gateway.loop.threshold>, 20 by default
When an email is sent to an alias, we look on the last records created
<mail.gateway.loop.minutes> minutes ago. If we overcome the limit
<mail.gateway.loop.threshold> the email is ignored.
Alias creation detection
========================
To detect the number of records created by a specific email address we
use the `_primary_email` attribute set on the model.
Task-2294034
closesodoo/odoo#78597
Related: odoo/enterprise#21772
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to ensure tools are called like intended, notably by filtering
input and raising if an unexpected value check is asked. Some code is also
made a bit more generic to have the same kind of parameters when searching
for mail.mail.
In this commit we therefore fix some bad calls to assertSentEmails which
were not checking the right stuff.
closesodoo/odoo#90082
X-original-commit: d9759b2ee86b79b4fb2739a4aebd24a8044cf947
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
When we called assertMailNotifications in batch, with different
notification status, it might raise an error when it shouldn't.
The reason for that is we check that no mail at all are created, for
the entire batch instead of filtering on the related partner.
`assertNoMail` should only check if no mail are created for the partner
it receive in arguments.
Task-2782150
closesodoo/odoo#89965
X-original-commit: 91be8b1eb2c3592029987524942ae2864988a7d3
Related: odoo/enterprise#26718
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
which we don't know. Threading is therefore broken. Amazon requires to remember
new Message-Id and handle it ourself, which is complicated [1].
Possible solution: copy the Message-Id to References in outgoing message as if
we were pretending that the message is part of a pre-existing thread with
itself. Since Amazon does not alter References it is kept during transport.
Replies will therefore contain both Amazon Message-Id and Odoo Message-Id as
well as original parent Message-Id in case of nested replies.
* ``In-Reply-To``: Amazon Msg-Id
* ``References``: Odoo Parent Msg-Id Odoo Msg-Id
Task-2643114 (Mail: Message-Id in references to ease thread formation)
[1] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.htmlclosesodoo/odoo#89328
X-original-commit: bc568747bdf92c6bbca400ce3ba11f6487679f3a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
mail_* = mail, test_mail, test_mail_full, test_mass_mailing
PURPOSE
Improve tooling of mail tests. Use SMTP mockup class available in base tests
in mail tests to have a better and simplified mock tool when dealing with
mail tests. Remove old fashioned code.
SPECIFICATIONS
Include ``MockSmtplibCase`` directly into ``MockEmail`` so that we re-use
existing components for mocking outgoing emails. Also make parameters for
gateway coherent between those two classes (use same test values).
Remove 'sim_error' weird parameter of Mail ``mock_mail_gateway`` and use
standard mock 'side_effect' instead in some specific tests, notably on
SMTP.connect() mock.
Add some assert / tools method and improve existing tools, used for creating
or improving test data. This will be used in future commits when adding new
tests.
Add outgoing mail servers data in mail tests, allowing to make tests closer
to real life use cases.
Remove unnecessary calls to ``_init_mail_gateway`` as it is automatically
done in ``MailCommon.setUpClass()``.
Try to consolidate starting test data, notably with countries, phone numbers
or email in mind to be sure test mail are deterministic.
Task-2673913 (TestMail: Cleanup and improve test coverage)
Part-of: odoo/odoo#86393
We are currently lacking an index with (author, failure) due to the information
being spread out in two different tables which are both rather big (there are a
lot of non-failure messages for the current user, as well as a lot of failure
messages for other users), so the fetch of failures for the current user can
become extremely slow (> 20s).
With this new index, the query takes less than 1ms.
task-2742946
closesodoo/odoo#83451
Related: odoo/upgrade#3204
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to add tests for language-based tweaks of email
notification layouts and composer usage. Purpose is to assess current
behavior before going into some cleaning or refactoring. Notably
* check layout content is translated;
* check "view document" button is translated;
* check action buttons are translated;
* check content based on templates is translated;
This is currently mainly available through the "lang" context key being
correctly set. Partial support of translations when posting based on template
is tested (content and model description but not notification layout).
Failing support in mass mail mode is tested. Future improvements will be
done in order to improve language support.
Note that ``MailTemplate.send_mail()`` email sending method language support
is tested in ``test_mail_template`` file. Those tests are updated to share
a common base with new tests about language setup.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Allow sales reps to add a closing note to their lead while it is being marked
as lost. This is currently already done by a lot of sales reps but manually
with the "Log a Note" button.
SPECIFICATIONS
In ``Lost Reason`` model: add a new html field allowing to log a note on the
lost leads. Below the m2o, add an Extra Comment field where users can add a
"closing note". When the wizard is submitted, log this message as a note on
selected records.
Add tests, allowing to test both the wizard and this new feature.
Task-2671709
Part-of: odoo/odoo#78648
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose is to assert current behavior as this may change in master. Two
kind of tests are added: performance and multi company.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
closesodoo/odoo#77845
Related: odoo/enterprise#21456
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Let us use existing data for multi-company tests created when calling a specific
method available in mail tools. We may then remove TestMailMultiCompanyCommon
that is used in a single test, with an hardcoded currency_id (hem).
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Purpose of this commit is to highlight an issue that may happens easily with
`crm` that is made generic here within `test_mail`.
`crm` alters the context when creating a new record adding in this case
`default_type` to it][1]. The returned record contains that altered context.
his results in other records created from it trying to assign that same default
value for `type`. This is a very common name for fields, and happens to exist
in `ir.attachment` too.
If you create an alias for incoming leads in your DB with default values
`{"type": "lead"}` (something very common) and then an email comes to that
alias that contains an inlined base64 image, the attachment creation process
would simply fail.
Obtained error is ``ValueError: Wrong value for ir.attachment.type: 'lead'`` .
[1]: https://github.com/odoo/odoo/blob/272602193f5647f7f2270ed6ec68777625a139dd/addons/crm/models/crm_lead.py#L310-L311
X-original-commit: 99434b2e8528c10fcc9cb6860765e0ddcaa364c8
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
=======
We want to increase the score of the emails sent by Odoo and we want to
avoid them to be marked as spam by the mail clients (gmail, outook...).
SPECIFICATIONS
===============
From filter
-----------
Add a new field on the "ir.mail_server" which is "from_filter". This
field defines the email address for which the outgoing email server can
be used.
The "from_filter" can either define an email address or a domain name.
Use the system parameter "mail.default.from" which allow us to define
a default email address which is used to encapsulate the emails
(default: notifications@<catch.all.domain>).
Mail server priorities
----------------------
When sending an email, we read the FROM header and,
- We first look for a mail server which match the entire mail FROM
in that case, we do not change the email header (not needed)
- If not found, we search a mail server which matches the domain name of
the mail from (do not need to change the headers in that case)
- If not found, find the mail server linked to the "notifications"
email (defined in the system parameter). Then change the FROM header
to the notification email, and put the old one in the name part of
this header.
E.g.
Initial mail from: "Admin" < admin@example.com >
Final mail from: "Admin (admin@odoo.com)" < notifications@odoo.com >
- If no notification email is configured or if no mail server are
found for the notification email, fallback to the old system and
spoof the FROM header. In that case we do not have the choice if we
want to send the email, he will probably be marked as spam.
Sending method priority
-----------------------
In the mail server models, we defined some priorities,
1. Forced SMTP session
2. Forced mail server
3. Try to find the best mail server (see "Mail server priorities")
4. If not found, read the odoo-bin arguments
Bounce
------
As there's no standard for bounce address, we put it in the envelope
(smtp_from). But in some case, it might be considered as spoofing. So,
we use the bounce address ONLY if the mail server is configured for the
entire domain name.
One behavior which might be broken is the following; we send an email as
"std@gmail.com" and the bounce address is on the domain "odoo.com".
Before we received the bounce notifications but we were spoofing the
local part and the domain.
Now
- if a mail server is configured for GMAIL, we do not use the bounce
address (and we might not receive the bounce notification)
- if no mail server is configured for GMAIL, but one is configured for
"odoo.com"
- the FROM header will be "notifications@odoo.com"
- the FROM envelope will be the bounce address
=> In this situation we are spoofing only the local part of the email
but it's allowed as the mail server is configured for the entire
domain name
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
Purpose of this commit is to add tests related to answers through mail gateway
when having reply-to mode of mailing set to either updating existing threads
(aka replying on mailed records), either creating new threads (aka using the
reply-to alias configuration).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
PURPOSE
Purpose is to have more tests when sending mail mailings, notably about
canceled or failed mails or sms as well as jinja and links rendering.
SPECIFICATIONS
In this commit we improve Email Marketing mailing tests. We notably
* add tests for void and invalid email and numbers. It allows to check they
correctly update their trace status;
* add tests for unsubscribe and view links embedded in mass mailing emails;
* add tests to simulate a click on links sent through mass mailing and
ensure click statistics are effectively updated;
* add tests to simulate bounce emails coming back to the mail gateway;
Default content of mailings used in test is updated to ensure jinja is
correctly rendered, including links and some corner cases. This will also
helps ensuring behavior is kept when converting to QWeb.
Various docstrings are added to helpers and custom asserts.
LINKS
Task ID-2508643
Followup of odoo/odoo#68874 (improve mail tests)
Prepares Task ID-27033 (support QWeb in templates)
Prepares Task ID-2377974 (clean trace and status management in mass mailing)
COM PR odoo/odoo#69461
ENT PR odoo/enterprise#17780
X-original-commit: 7b940ad46bde30f9bf16837f7bff5a70cd88c640
When using assertMailMailWEmails custom assert we now check that a sent
mail.mail matches a sent email. It allows to have a complete check from
mailing traces to sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
ENT PR odoo/enterprise#17558
X-original-commit: 59da8627e0d732b12fb98faa6e66e43b8c75dc9c
In this commit we backport some of 14.1+ improvements done in mail tools
in order to keep a coherent definition through sub versions. We also
improve docstring and add some explanations on available toold and asserts.
Task ID-2500615
COM PR odoo/odoo#68874
X-original-commit: d44c47697389866603f28ff2d5da60a97574ec5f
This commits is a bit a followup of odoo/odoo#62061 where new composer tests
were added. This commit finalize this work by merging all composer related
tests within the same file. It also backports some of tooling update done
in odoo/odoo#64459 or odoo/odoo#63677 in order to have coherent naming
through 14+ versions.
Some additional or deeper tests are added. Notably it now more cleanly
uses asserts for created mail.mail and sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
X-Original-Commit odoo/odoo@67f31cbfcd
X-original-commit: e147ca2eb51a7008251f20f134bd021a1ae3705c
In this commit we improve event communication scheduling tests. We make tests
more detailed and use mail tools to ensure content. We also check scheduled
dates and use freezegun to ease date management.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 1a66d9cb57dc17b697b7a56effa91de3a4b50bd7
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` argument and support from ``message_subscribe`` and
``message_unsubscribe`` API. Indeed we do not support adding channel-based
followers anymore. Only partners should be added or removed from followers.
It also allows to simplify API and understanding of both methods.
Various addons are updated to match the simplified (un)subscribe API. Some
enterprise addons may also be impacted.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose is to use available tools, easier for debug and asserts than doing
everything manually. It prepares future changes in channel model that may
have an impact on bus notifications.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Add the currency symbol for the monetary tracking field to better
represent the change of a monetary field.
The currency will be fetch from the currency defined in the
monetary field or on the record's company in case there is not.
For example, if we have a record with a monetary field displaying
"$ 500". If we modify the currency and the value to have "450 €",
the message containing the tracking values will display:
"500 € -> 450 €".
We only use one field to track the currency of a monetary field.
Indeed, in the case where the currency is changed with the value
of a monetary field, only the new currency is tracked. We focus
on the fact that the more important thing is the new value.
Furthermore, when modifying a currency of a monetary field, the
user can already see the new currency before saving the changes.
This allows him to adapt the value of the field if he needs it.
(N.B. we assume that this case will happen very rarely)
Using only one field takes also into account that there are
millions of record for this model and adding a new field would
take a lot of memory.
odoo/odoo#61999odoo/upgrade#2060
task-2387268
Purpose of this commit is to rewrite channel tests, notably moderation
tests. In this commit we
* use standard users instead of admin/root: this allows to test ACLs and
more real life oriented use cases;
* remove unnecessary tests or merge tests belonging to the same category;
* add some coverage for corner cases;
* make tests more readable;
We also improve some notification code and error messages that are not
really helpful for users.
Followup of odoo/odoo@e9571a403e
Task ID-2421795
closesodoo/odoo#64459
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Improve channel related test content, notably
* use more often real users to avoid doing all tests as admin;
* remove unnecessary variables creation, use content created during
setUp;
* improve overall code;
* remove join/leave channel custom tool method and add real methods on
channel model;
Moderation tests are left untouched because... well.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 19de1303d015613973115cc01941ae8ca0e82cec
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
Purpose of this commit is to add some mass mailing tests in test mail full
(with all community mailing capabilities installed). In this commit we notably
tests unsubscribe and view URLs computation in sent emails, as well as
the invisible preview block for email clients.
Task ID-2239327
Task ID-2239327
PR #49886
Related: odoo/enterprise#10091
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
Consider an email going through the mail gateway. Its headers References
and In-Reply-To are used in mail gateway to find if it is an answer to an
existing discussion thread.
Notably in mass mailing it is used to set mailing traces (called statistics
before 13.0) as opened and replied. However currently only the References
header is used.
In this commit we now use References or In-Reply-To like what is done in
mail gateway.
== 13.2 FORWARD PORT SPECIFIC ==
Code in tests has been updated to use new mockups tools and variables available
in test_mail
LINKS
Task ID 2257717
PR #51445
Forward-port-of: #51319
Forward-port-of: #51247
X-original-commit: 9921e38692e7dc4547afc34acc395da340eca410
In this commit we order fields more logically to ease reading and prepare
future modifications. We also rename the class and some field strings to
be more user friendly.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closesodoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We now also support formatting a return path when emulating incoming emails.
Purpose is to integrate some more tests in a near future about incoming
emails, notably in CRM.
This commit is a preliminary cleaning coming from task 2088565 about CRM
onchange to compute methods update.
LINKS
Task ID 2088565
Community PR #42344
Enterprise PR odoo/enterprise#7403
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in application tests or force them
to write custom quick and dirty tools and asserts. Purpose of this merge
is therefore to move tools classes and mocks to mail directly and use them
in various sub modules.
SPECIFICATIONS
Have class, mocks, tools and asserts available in mail so that all modules
below from mail can use them.
Including
* mock mail gateway in a clean way: mock server connection, email building
and sending;
* allow to simulate errors while sending emails to test corner cases;
* provide tools to insert emails in mail gateway;
* mock mail application to check record creation (message, notifications,
mails, ...);
* mock bus notification;
* provide clearer assert methods for bus and mail notifications;
* provide clearer emails sending and content methods;
* provide a with_user tool context manager for tests allowing to quickly
change current user given a login;
Most of those tools, asserts and mocks come from test_mail/tests/common.py.
They have been partially rewritten to be easier to use or to perform tests
more cleanly.
Future commits will gradually update existing tests in test_mail, test_mass
mailing and test_mail_full.
LINKS
Task ID 2068986
PR #38070
