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
Purpose is to lessen noise and make tests less low-level. Including :
* clean and remove most of old tests, low-level and not very useful;
* add tests for several cases, like simple tracking, tracking linked to
a mail.message.subtype, trackink automatically sending emails based
on some template;
Purpose is to lessen noise and make tests less low-level. Including :
* add test for the various auto subscription cases, notably through
umbrella (like project -> task auto subscription);
* remove low-level tests; there is no need to test the output of add
followers method as it is only an implementation details;
Purpose is to lessen noise and make tests less low-level. Including :
* move mail_mail model specific tests to its own file;
* move feature specific tests to its own file;
* add missing loggers to lessen noise;
Purpose is to lessen noise and make tests less low-level. Including :
* tests should be more about channel listeners than followers as
channels should not have followers;
* test email_send that trigger the mailing list behavior;
* currently add some join and leave channel methods are those are
missing in the base model:
* test joining and leaving channels that should not change
followers but members;
* use less preconfigured data;
* add some mute loggers to lessen noise;
* remove some old code about patching that is not necessary anymore and
could actually create funny bugs;
Purpose is to lessen noise and make tests less low-level. Including :
* remove unnecessary fail string;
* remove unnecessary method return value test as this is low level;
Purpose is to lessen noise and make tests less low-level. Including :
* remove test of emails content as this is too low-level and not really
interesting. Purpose of test is to check followers have been added
and not the content of a template;
* remove unnecessary fail string;
* remove unnecessary low level checks;
Purpose is to be less low level and improve code coverage by adding
tests if required. Duplicated or redundant tests are removed to lessen
number of tests. Notably content of notification emails, recipients and
specific chatter control through context keys are more tested.
Some more tests about buttons present in notifications emails should be
added. Maybe in a near future. I hope so.
This is some remains of old message_read / message_fetch tests linked to
the old chatter using threaded display. Tests have been removed when the
feature was changed. Only the setup was left. Let us get rid of it.
This commit improves common classes and add helpers for mail tests.
Future commits will use this new stuff to improve the tests.
* improve existing models and add some of them. There are now several
models
* mail.test.simple: chatter-enabled record without any really advanced
feature. Can be used everywhere standard chatter and communication
tests are required;
* mail.test.track: chatter-enabled record with basic value tracking
and responsible tracking;
* mail.test.activity: chatter-enabled record using activities;
* mail.test.full: complete chatter-enabled record with advanced
tracking, automatic subscription and automatic email send based on
templates and tracking;
* mail.test: chatter-enabled record having an alias. It can be used
where umbrella record like projects or teams has to be used in
tests;
* add MockEmails test class: this class mocks the mail gateway so that
tests can work on emails without actually sending them. It is taken
out of TestMail class to clearly separate features from class;
* improve created data in the various classes and prepare work to
lessen created data during tests;
* add helpers on base test class, notably
* sudoAs: context manager to run a code snippet using a given user;
* assertNotifications: assert notification content, aka Inbox or email
notification and their content; may be subject to change depending on
mail evolution;
* assertEmails: check content of sent emails;
Purpose of this commit is to reorganize the mail tests. Containing
* move test models into mail/tests/models/;
* move data into mail/tests/data even if it is python code, as it is
likely that some additional data will appear soon;
* split test_mail_features into test for discuss app and test related
to message post and composer, to better identify test target;
* split and remove test_portal, those tests are now integrated in the
other tests;
There is no change in this commit. Only some renaming and file move or
split.
mergeup: remove / split test portal
No formal decision there, and the stdlib API seems like a PITA as it's
based around native strings, not bytes and not text.
* try to use cross-model API instead of random encode/decode
* unicode all the mail_template things
* formataddr *requires* a text tuple now
In P2, formataddr((False, False)) "worked" (generated "False
<False>"), in P3 it will fail and blow up.
* attachments are quite definitely bytes
* remove try_coerce_ascii because it's garbage
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
This commit cleans code to separate recipients computation in mail
message from notification mechanism in partner. There is no functional
change. Some variables have been renamed notably to know that
some of the record sets are sudoed during computation.
Currently almost all mail tests run on mail.channel model. Indeed it is
the only model inheriting from mail.thread and mail.alias when having only
mail installed. However channel model have several specific features and
is not totally a standard mail.thread model. For example notification
recipients are computed a bit differently.
Since 4f9105a4ef mail module has a test
model allowing to perform tests on a very simple mail.thread-like model.
This commit make mail tests use this test model instead of mail.channel
everywhere it is possible. Channel model should be used only when tests
are channel-dependent.
Currently if an user mentions someone in an internal note he is not
notified of any reply as replies create internal notes. This commit
ensure the author of the first note is notified of the reply even
if it is still an internal note.
Tests have been updated accordingly.
Replying to internal notes should create internal notes and should
not notify anyone. Future commit will change that behavior. This
commit ensure the current behavior is working as intended.
Thibault Delavallée