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
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
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.
