Use dict.get() instead of a subscriptable call. This way we let through
selection values that are not loaded into the registry, instead
of raising an error.
This is especially useful in the upgrade environment
where such values may be unavailable (because of being
lambda-defined in a custom module for instance).
closesodoo/odoo#94530
X-original-commit: 36a6943740f9b4fbd9a78986bee4cd84bb8469c7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to test behavior when having multiple references in mail headers.
We have to check that parent_id is correctly taken (as it impacts internal
flag), and that flattening is performance when posting the message (always
attaching to the thread first message being the default behavior).
Note that tests highlighted that flattening is currently a bit broken as it
does not go up until the first ancestor, which is the expected behavior for
business documents having ``_mail_flat_thread``. Next commit will fix that.
Task-2822652 (Mail: fix parent message fetch / flattening)
Task-2643114 (Mail: Message-Id in references to ease thread formation)
X-original-commit: f7d4f1d29213c71e76564c485db2bbecf0bbf37c
Part-of: odoo/odoo#89328
PURPOSE
Purpose of this commit is to add a company field on test mail models used to
replicate ticket / project behavior (``mail.test.ticket`` and ``mail.test.
container``).
SPECIFICATIONS
To avoid messing with existing tests and ease comparison through all Odoo
versions (notably performance) this is done by adding new models inheriting
from current mail models. A company_id field is added as well as MC rules.
Those models will be used to add tests for mail thread behavior in a multi
company environment (aliases management, performance, emails and notification
layouts, ...).
In this commit we also update ACLs for ticket-like models to add rules for
portal users, based on followers. This mimics classic rules from Odoo used
notably in a light project-like environment. This allows to test a bit more
in details recipients, access tokens, links in emails, ...
Task-2673913 (TestMail: Cleanup and improve test coverage)
Part-of: odoo/odoo#86393
*: hr, hr_holidays, im_livechat, mail, snailmail, test_mail, website_livechat,
website_slides.
This commit will remove the need to duplicate models definition for
test purposes. Indeed, for now, we need to mock the model definitions
on the client side. Those models definitions are often very different
from the ones found on the server.
This approach will allow us :
- to ease model definitions during tests
- to get closer from the real models
task-2767820
closesodoo/odoo#84828
Related: odoo/enterprise#24486
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
Extract translations and preparation to setup of TestTemplate class. That
way those are usable in other tests.
Create a new model to test language computation. It holds both a string
and a partner field, allowing to test a bit jinja-based language computation.
Task-2643750
X-original-commit: 7896cbc4f2256122b5cf6c5506921398f2ebc931
Part-of: odoo/odoo#76458
This commits introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
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
Have a cleaner test_mail addons
SPECIFICATIONS
Keep only mail-related tests, move odoobot in test mail full, send "update
notification" tests in mail (specific to mail). Merge some test files to
lessen number of files, perform light file renaming.
Split test mail models file to prepare some cleaning in those models and tests.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
The tracked field is now a relation to the corresponding ir.model.field.
This prevents potential privacy issues should the field be deleted or renamed.
closesodoo/odoo#39232
Taskid: 2088634
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit add some tests related to the mail gateway: more bounce management
tests and some additional thread formation tests. Some test asserts about
bounce / blacklist management are commented as they are not completely working
currently. This will be improved in master soon.
Some cleaning in also done in all mail gateway tests. Notably some call to
tool methods are cleaned / simplified, duplicate tests are removed. Some
low-level checks are removed.
A new test model is added for mail gateway: mail.test.gateway. It is a
chatter model with blacklist enabled on it. It allows to tests the
various blacklist-related overrides and features as well as all basic
mail gateway features.
Sub-part of task 1853147 (pre-cleaning before implementing mail gateway
improvements)
Linked to PR #32974
*: crm, project, maintenance, hr_recruitment
When a record is created from an email, cc can be lost. This commit
proposes a new mixin to keep cc on the record and allows to create
partner for each of them when sending a message from the chatter.
The mixin is added on the mail recors that can be created from mail.alias:
document
helpdesk.ticket
mrp.eco
quality.alert
hr.applicant
crm.lead
project.task
mail.channel
maintenance.equipment
Task: 1925001
Test performance will now hold the base class for performance tests as
well as tests related to the ORM, depending only on base. A new module
test_mail is introduced at this commit that contains performance tests
related to mail module. This commit contains only code move and should
not impact anything.
Future commits will move mail tests into test_mail so that all mail
related tests are located in the same optional module. This allows
notably to avoid creating a lot of unnecessary tables when installing
mail module on production databases.
diagnoza