RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template to post on a composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered and translated if
matching template content -> ok;
Email layout situation when posting / mailing
* comment, monorecord model, using a template from UX: layout is partly
translated based on template 'lang' field to match the content translation.
Part of the layout still uses the current user lang;
* other comment use cases: layout is translated based on current user lang;
* mailing mode: layout not supported;
PURPOSE
Correctly propagate lang from template in all situations whenever a template
is used, and translate all layout parts.
SPECIFICATIONS
When using the composer to post messages (either as comment or in batch) the
language coming from the template is not propagated until the notification
process.
A hack has been done to try to guess the language inside the notification
process, based on context keys at odoo/odoo@9e71d228ed. This was done to partly fix
the bug in stable.
Since odoo/odoo@3eb9680602 it is possible to propagate a lang from 'message_post' or
'message_notify' calls until the notification process. We can therefore call
the posting methods using the rendered lang (in both mono and multi record
modes) and remove that hack.
When a lang is propagated using the 'force_email_lang' it is used to choose
the language of the layout (content, buttons). Currently all recipients
receives the same language for layouting. We plan to soon use the recipient
language when possible, then fallback on that forced lang. This will offer
more granularity and a better user experience.
When using scheduled messages (creating message but delaying the sending of
notifications) it is also working as notification parameters are saved when
creating the scheduling record, see odoo/odoo@9b11a9d82b.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
* layout is translated into spanish (customer's lang);
Both recipients (customer and follower) receive the content in spanish.
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Task-2555155 (Mail: Translate notification action/access buttons)
Part-of: odoo/odoo#106177
RATIONALE
Naming conventions
* content = core message / subject (+ other fields);
* email layout = layouting applied to messages when sent to recipients who
receive notifications by email e.g. access button, ...;
* comment mode / mailing mode: composer main composition mode: posting on
record(s) / sending a mailing on records;
Content situation when using a template on the composer
* comment, monorecord mode: choose a template, content is rendered directly
from template side according to 'lang' field definition -> ok;
* comment, multirecord mode / mailing mode: choose a template, content is
the raw content. At post / send, content is rendered on composer side.
As composer is not translated -> no translation -> ko;
PURPOSE
Take translations from template when composer content is the same as the
template one to benefits from their translations.
SPECIFICATIONS
When rendering some fields fetching translations can be complicated. Indeed
when using a template the translation is stored on template model while the
rendering is done on composer model. Translations are therefore not fetched
as fields of the composer record itself are not translated. It is a transient
record, not something people translate manually like templates.
As translations are not stored in a table anymore we can't really fetch
translations, except from using directly the template field. In this commit
we therefore do the rendering based on template value instead of composer
value when they are considered as equal and if a translation is asked either
through 'compute_lang' of 'force_lang'. This allows to fetch template
translations instead of composer translations.
If the composer content has been modified compared to the template we keep
the old behavior, which means probably no translations. Let us hope editor
does not mess too much with html content.
EXAMPLE
A user in english uses a template on a lead whose customer is in spanish
with a follower being in german. Template lang is customer's lang:
* content is translated into spanish (customer's lang);
Concerning layout (to be fixed in next commits):
* layout is partly translated into spanish (customer's lang) if coming from
form view, otherwise is in english (current user's lang);
LINKS
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose of this commit is to improve behavior or mail.compose.mixin when
removing the template. It now voids the value to avoid having half baked
definition on composers.
Summary of behavior
* when choosing a template: existing (non void) values override any value
in the composer mixin;
* when removing a template: reset values;
* when going from templateA to templateB: works like choosing a template
which means only non void values are taken. This may lead to half-baked
content but trying to remove old template content based on _origin and
content comparisons would be complicated for few added value;
This makes the 'mail.compose.mixin' behaves like 'mail.compose.message'
wizard which was recently updated at odoo/odoo#107356.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#106177
RATIONALE
Purpose of this commit is to add helper field knowing if body any model
inheriting from the 'mail.composer.mixin' is synchronized with their
template value.
SPECIFICATIONS
Add a field to check if body of a composer is the same as its template
* compare both current (raw) values and sanitized values, as sanitization
process may change some bits of html code;
* correctly check for void content using the tool;
Obviously this may be broken if editor usage changes the source template value
DOM when saving it in the composer. However we can't do much more than using
the original and sanitized values from template and compare them with the
current composer values.
It is used in this commit to simplify a bit code in '_render_field' override.
It is used to detect any change in body based on template. It highlights
potential changes in QWeb directives which requires usage of editor group.
This method is also cleaned in order to have less calls to super() in nested
if-elif structures. As some additional code will be added soon it is better
to have a simpler code flow.
Finally add some tests about current state of fields synchronization notably
when setting a template with void values, or removing the template.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Mail composer mixin already synchronizes subject and body based on a mail
template, easing calling rendering methods available through mail render
mixin.
In this commit we add the same mechanism on lang. Lang is taken from the
template and can be used to render content based on language defined on
template, generally based on a customer.
Some query counters are updated, without being sure those are really coming
from this commit. Anyway they will be updated in batch at the end of this
PR, as tracking them on each commit is tedious and not always really
useful.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Add message post with attachment test on record of another company than the
user company but for which the user has readonly access on. The goal is to
justify the sudo added in mail_thread:
- in '_message_post_process_attachments' method to create attachment linked
to the record (the creation of attachment linked to a record verify the
right to write to the record, so in readonly we need a sudo);
- in '_message_set_main_attachment_id' method to link the main attachment to
the record. Here we write directly on the record for which we only have
readonly access, so a sudo is needed. Here the attachment is already linked
to the model and we only "tag" it has main attachment (see odoo/odoo#30659)
Task-3178885 (Mail: fix 'readonly' post support)
X-original-commit: odoo/odoo@8486c7ee05
Part-of: odoo/odoo#114511
Purpose of this commit is to add tests to post in record user cannot access
especially in multi company environment.
Main observations
* ACLs are checked when fetching record_name, then when fetching reply_to
information, adding a bit of ACLs noise in the process;
* check_access_rule of mail.message is called when creating the message
(which is the real protection);
* posting on a document user cannot see is possible when they have been
notified of a parent message. Use case is: answer a ping, even on a
document non readable, should always be doable. However it currently
crashes notably due to attachments check, who always require the read
access on the related document even if the message is authorized;
In this commit we also move other tests about multi_company in the right
file (and add a test flag) in order to have all of them in the same place
easing debug and testing.
Task-3213982 (Mail: fix 'multi-company' post support)
X-original-commit: odoo/odoo@5656f4d20d
Part-of: odoo/odoo#114511
Purpose is to add some tests about email layout support in both comment and
email mode, as well as language support in those two modes. They are added
in a test targeting a complete template usage, testing globally the results
(outgoing notifications or emails, buttons, language, recipients, ...).
Posting in multi-languages environment with notification layout is also
tested. Finally a test about reply-to is moved into its own subtest to
avoid polluting core template tests. Other low level details should already
sufficiently tested. Normally.
Main observations
* translations are quite broken in mass mode (either batch comment either
mass mailing). Indeed translations are fetched based on <mail.compose.
message> body and subject fields, which are probably not translated
as they are linked to a transient model. Real translations are stored
at <mail.template> level when users translate their templates;
* layout translation is partly supported in comment mode, due to a small
context-based hack. However access buttons are not translated and some
use case (like using a 'res_domain') are not supported;
* mass_mail mode does not support layouting at all;
* when posting manually ('message_post') current users' language determines
the language of notification email layout e.g. a user using Odoo in French
will send a french layout to all followers, whatever their language and
whatever the language of the post (which is not known as user input);
Most of those use cases will be fixed soon.
Also update some query counters while passing by.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#114511
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Update tool method generating attachment data to ease name tweak when required
in tests.
Also update query counters, and fix a test not running locally.
Task-3046371 (Mail: Better Language Support in Composer)
X-original-commit: odoo/odoo@b32d937b37
Part-of: odoo/odoo#114511
RATIONALE
Currently email layout choice is done in code and is not controllable through
any user interface. In this commit we prepare improvements in template
management by allowing to choose the email layout directly from a given
mail template. As number of layouts is going to grow better be able to
choose the right one.
SPECIFICATIONS
Add a field on template to propagate email layout choice directly on
template and propagate it to the composer, then post/notify process.
We can now choose directly on a template which notification layout should be
used in conjunction with this template. Composer model already holds a field
'email_layout_xmlid', used in various places in code to give a specific
layout to use when sending notifications emails e.g. SO email layout. This
can now be specified directly from the template itself. It allows to
customize the look and feel of notifications without having to do it
explicitly in a given code flow.
Computation is coming either from template, either reset. When having a
template with a value set, set it on composer. When removing the template
reset it.
Currently no standard template uses it as this task targets mainly a code
cleaning that began with the composer code cleaning. It targets the near
freeze to have the base code updated once, then functional templates will
make use of it (hopefully).
Note that currently notification layout is still not supported at composer
level for mailings. It is simply ignored when generating outgoing mail
records. This will be improved soon.
Global followup of odoo/odoo#107356 / Task-2088884 (Mail: Use editable
computed stored fields in composer).
Prepares code for Task-3046371 (Mail: Better Language Support in Composer)
see odoo/odoo#106177 .
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#114462
Related: odoo/upgrade#4404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The bounce emails aren't stored in Odoo, which can complicate the
debugging of the email sending.
Now, we store this bounce email, and we allow the user to read it from
the interface, so he can easily find the issue when an email sending
fail.
Specifications
==============
The bounce email is stored on the mail notification for standard emails
sending, and on the mailing traces when using mass mailing.
For some email providers (e.g. Yahoo), the "Final-Recipient" header is
not present. Normally, it allows us to retrieve the original recipient
of the email which bounced and then the partner. So if this header is
not there in a bounce email, we take the first recipient of the parent
<mail.message>.
Change the way that we parse the email body, for the bounce email.
For most email providers, the first mail body is the one that contains
the error and the next one contains the parent email body. So, the
current logic might ignore this body for Outlook and Yahoo.
Task-2116296
closesodoo/odoo#105923
Related: odoo/enterprise#34051
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The test is based on a record that the user cannot read. It used to
work by accident, because some side effect leaked data in cache.
Part-of: odoo/odoo#112126
This is about the overrides of _search() on models mail.activity and
mail.message, which both make extra queries to implement their specific
access rights. We combine both queries made in _search() to retrieve
accessible records. This simply uses the API of the Query object to
retrieve the data that is necessary to restrict access to messages.
Move security check outside of _message_format() for performance. The
call to check_access_rule() inside _message_format() was redundant in
many cases and generated more SQL queries than necessary.
Also for performance, accessing fields from records should not actually
check permission. That's a bit freaky, but this reproduces the former
behavior of mail.message.
And finally, make method check_access_rule() on mail.message check
ir.rules, in order to make it consistent with method _search().
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Some code cleanup done when moving the main attachment into its own mixin:
- improved docstring
- early returns
- code simplification
No functional changes should occur with this commit.
Task-2648976
Part-of: odoo/odoo#110734
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``email_add_signature`` in
compute method.
When having a template, consider it defines completely body and do not add
signature. Without template, add signature by default in comment due to post
processing for notification emails. Mailing mode does not handle signature.
Followup of odoo/odoo#107356
Task-2088884 (Mail: Use editable computed stored fields in composer)
closesodoo/odoo#113522
Related: odoo/enterprise#37478
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Inactive users should not be added in followers of records, especially using
automated subscription. Indeed they mainly generate noise in notification
process and are generally skipped.
Few use case exists of inactive users creating records. One use case is the
mailgateway running as root but a context key 'mail_create_nosubscribe' is
used to avoid it. Other use cases include automated action for example who
are also generally protected.
Anyway better be sure and consider this is a standard use case. To extend
this rationale, inactive people are currently not added when posting. It
therefore makes sense to keep this behavior coherent through the mail stack.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Currently an inactive user that creates records is added in followers. Standard
use case is the mailgateway but it has the 'mail_create_nosubscribe' context
key that avoids the mailgateway user to be added in followers automatically.
A test is added without the context key that shows that inactive users are
added as follower when creating a record. This is due to the direct call
to '_insert_followers' that does not perform any filtering on inactive users.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
Allow model to provide default values for auto creation of related res_partner
such as name, title, company_id, ...
It is used when claling 'Partner._find_or_create_from_emails()' that now
accepts custom data when creating partners based on a given email_normalized.
This allows notably to flatten a loop due to multi-company when creating
partners from emails in template management. It is now done using this email
based dict allowing to create all partners at once.
Task-3024050
Part-of: odoo/odoo#105111
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Followup of odoo/odoo#95623 (introduce scheduled message notification) as well
as odoo/odoo#99482 (support scheduled datetime from template to composer in
both comment and mailing modes).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Update query counters now that fields are editable computed fields. Some
counters are higher as the usage of composer in code is now closer to the
usage in view, with fields being correctly computed. Some other counters
are a bit lessened, but it globally stays the same.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
PURPOSE
Purpose of this task is to remove the _onchange_template_id method on composer
model. Split it into editable computed stored fields. It gives a better control
of value generation and avoid having to call the onchange when composer is
invoked in code.
SPECIFICATIONS
Remove onchange as it is not used anymore. All fields have been converted.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``subtype_id`` in compute method.
It is currently always set to be a 'comment' subtype. However in mass mailing
mode it is not used, as we do not use the value. Better void it directly.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``attachment_ids`` and reports
(``report_template_ids`` on template that generates reports) in compute method.
Computation is based on template and composition mode. In monorecord comment
mode, template is used to generate attachments based on both attachment_ids
of template, and reports coming from report_template_ids. Those are generated
based on the current record to display. As template generation returns a list
of tuples, new attachments are created on the fly during the compute.
In batch or email mode, only attachment_ids from template are used on the
composer. Reports will be generated at sending time.
When template is removed, attachments are reset.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``partner_ids`` in compute
method.
Computation is coming either from template, either from context. When having
a template it uses its 3 fields 'email_cc', 'email_to' and 'partner_to' in
monorecord comment mode. Emails are converted into partners, creating new
ones when the email does not match any existing partner. Composer does not
deal with emails but only with partners.
When having a template in other modes, no recipients are computed as it is
done at sending time. When removing the template, reset it.
When not having a template, recipients may come from the parent in comment
mode, to be sure to notify the same people.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``scheduled_date`` in compute
method.
Scheduled_date computation is coming either from template, either reset. When
having a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``mail_server_id`` in compute
method. Copy value from template when updating it, if set on template. When
removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``body`` and ``subject`` in
compute methods.
Subject computation is coming either form template, either from context.
When having a template with a value set, copy it (in batch mode) or render
it (in monorecord comment mode) on the composer. Otherwise it comes from
the parent (if set), or computed based on the generic '_message_compute_
subject' method in monorecord comment mode, or set to False. When removing
the template, reset it.
Body computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONSS
Improve composer to correctly compute fields ``reply_to(_force_new)`` in
compute methods.
Reply_to computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template reset it.
Reply_to_force_new computation depends on model. If it does not inherit from
MailThread, avoid replies to be considered as thread updates, they will instead
follow the routing rules (alias, ...).
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``email_from`` and ``author_id``
in compute methods.
Email_from computation is coming either from template, either from context.
When having a template with a value set, copy it (in batch mode) or render it
(in monorecord comment mode) on the composer. Otherwise try to take current
user's email. When removing the template, fallback on default thread behavior
(which is current user's email).
Author computation is not controllable from the template currently. We therefore
try to synchronize it with the given email_from (in rendered mode to avoid
trying to find partner based on qweb expressions), or fallback on current user.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``auto_delete(_keep_log)`` in
compute methods.
For auto_delete, computation is coming either from template, either from
composition mode. When having a template, its value copied. Without template
it is True in comment mode to remove notification emails by default. In email
mode we keep emails (backward compatibility mode).
For auto_delete_keep_log, it is used only in email mode. It is used to keep
the core message when unlinking sent emails. It allows to keep the message as
a trace in the record's chatter. In other modes it has no use and can be set
to False. When auto_delete is turned off it has no usage.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``record_name`` in compute method.
Computation is coming either from parent message, either from the record's
display name in monorecord comment mode. In batch mode it makes no sense to
compute a single record name. In email mode it is not used anyway.
Computing it in composer allows to benefit from its computation to give it to
the message created afterwards during message_post.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
When using the mail composer in comment mode on models that do not inherit
from mail.thread, the post is transformed into notification process. Instead
of calling 'message_post' on the records (which would crash) 'message_notify'
is called, using MailThread as abstract class (which creates notifications
without having to inherit from mail.thread).
However some parameters from the composer are not supported when calling
'message_notify'. This commit fixes it and adds tests accordingly.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
When posting a message, author is added in followers in order to receive
answers. They also do not receive its own messages, to avoid being notified
of something they just posted.
However the real author is not always the message author. In this commit
we better define this author
* when current user is active, real author is the current user. It means
posting on behalf of someone will send answers to you, not to the
spoofed partner;
* when current user is inactive, real author is the message author. An
inactive current user means the post was probably done as sudo, aka
in the mailgateway or frontend. In that case we don't want to add
odoobot in followers, but the actual message author;
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Currently notification process called notably by message_{post,notify} does
not notify message's author by default. Rationale is that as he typed the
message he is already aware of it.
However in some cases we want to skip this step, notably when messages are
generated in the name of the author and when we want him to be notified if
he should.
This is currently controllable through a context key 'mail_notify_author'.
In this commit we add an explicit parameter propagated through the notify
process, allowing to remove some context key usage and instead use real
parameters.
Note that all context keys usage cannot be removed as it is not always
possible to propagate this parameter.
Followup of odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Replace them by admin, which should globally be the same as employee. Testing
with system is a remaining of old times, when bichons were running freely in
the court.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
As this matter is a bit complicated due to synchronization / desynchronization
of author and email, some asserts are added to help understanding the changes.
To ease converting field into an editable stored field, some additional
checks are added in tests to ease debugging and avoid regressions.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
Purpose of this commit is to add some tests about 'res_domain' usage in
the composer. As it takes over 'res_ids' when being set, being sure all
use cases are covered is better, especially in batch comment mode that
has been recently added.
Followup of odoo/odoo#99482
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#107356
As subtype has no usage in mail mode, let us consider subtype_is_log as being
True in mail mode, as it eases display of buttons. This is its main usage
aka display "Log" instead of "Send" on composer. In mail mode it should
always be send.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
Based on RFC3462, a Content-Type text/rfc822-headers
exists and provide a mechanism to label and return
only the RFC 822 headers of a failed message (bounce)
These are only the headers and not the full message.
The Content-Type-Encoding should be either 7-bit(US-ASCII)
or Quoted-Printable (QP) as in the section 2 of the RFC.
Spawn the error:
After getting reported by a customer, I had to reproduce
by spamming wrong outlook addresses and add logging
in a sh database on the message_process of mail_thread.py
and logged the `message` variable.
After few retry, I got one of the part that was defined
as followed:
Content-Description: Undelivered Message Headers
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: quoted-printable
The `get_payload()`function used was only assuming
that there is a full email on that part and that
it could only be encoded as an email, which was not
the case in this situation (quoted-printable:
76 characters per line, character `=` used
as the end of line character).
opw-3064589
task-3131561
closesodoo/odoo#110901
X-original-commit: f86f4b671696178f8fa42b81d8753d2591578431
Signed-off-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Baptiste Vergote <bve@odoo.com>
Update counters now that all changes in this PR are validated.
Main observations
* batch mode is improved: few tests effectively run on a real batch of
records but in those use cases there are more gains due to better batch
management of values rendering and recipients management;
* posting using a view does not call the composer anymore in all situations
allowing to gain a lot of queries by not creating a composer and calling
a dummy onchange on it;
* various small gains in various tests, notably linked to usage of low-level
reference fetch and various small code tweaks;
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#99482
Currently when using the composer excluded emails are computed when the target
model inherits from the blacklist mixin. This behavior can now be deactivated
through a new field 'use_exclusion_list', like what has been done in SMS
composer.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
Currently when using the composer to create a mass mailing emails are sent
directly, unless scheduled date is in the future.
With this commit it is now controllable through a field like what has been
done on SMS composer. Its default behavior is the same as before
* posting on a monorecord: force send notification emails;
* posting on multirecords: use the queue (force_send=False parameter given
to message_post and propagated to _notify_thread);
* mass mailing: use force send to send emails directly;
Usage of mail_notify_force_send context key is also removed when possible
as it is a standard parameter of posting API.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
Thibault Delavallée