When upgrading mail across the addition of the linked record's company
and mail alias, if the `composer.model` is not part of a module that's
already loaded (which is very likely) the compute will blow up when it
tries to look up the model in the env.
Add that check to the condition.
closesodoo/odoo#139845
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit it is impossible to find the qweb error when you preview an email template.
closesodoo/odoo#139668
X-original-commit: 1f373de5f218a1f43015f4f80e60d1da0188d6b5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
When composer runs in 'rendering' mode, it is often based on a mail.template
record that gives information about recipients. When having no template
default recipients are added to be sure to contact 'intended people'.
When rewriting code in 16.2, support of batch-comment was added in addition to
mass mailing. Result is that now default recipients are also computed when
posting in batch. However when posting we consider recipients are already set
on records using followers. Adding default recipients to avoid dummy emails
is present mainly for the mass mailing mode.
Followup of odoo/odoo#107356
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
Test are updated because the wizard is opened instead of the activity form to
schedule a new activity and as the form view is only used to edit already
existing activities, default_res_id and default_res_model are no longer passed.
We defines date_deadline and date_plan_deadline in the schedule wizard because
those date are managed differently (default value, required or not, ...).
Task-3390865
Part-of: odoo/odoo#137969
Purpose is to make it more widely available, as it can be used in other wizards
dealing with res_ids / active_ids.
Task-3390865
Part-of: odoo/odoo#137969
With this commit, we now raise a UserError if a user tries to save a template
with a composer that has no attached model.
Task-2504439
Part-of: odoo/odoo#126049
Before this commit, all mail templates were shared, which was cluttering the UI
for everyone.
Now, each user can have their own templates that they can edit and save. Access
is done through the mail composer wizard, where users can only access their own
templates and templates that don't belong to anyone.
Some groups are considered as admins and can access all templates in
Settings/Technical/Email/Email Templates:
- Sales Admin
- Project Admins
- Helpdesk Admins
- Accountants
- Event Admins
- Recruitment Admins
Task-2504439
Part-of: odoo/odoo#126049
In log note case, followers are not going to be notified of the message.
Therefore the recipients input should not be visible.
task-3504225
closesodoo/odoo#136661
X-original-commit: c60449a2efde457e8370928681f011c103ea1d60
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
As of rfc5322 section 3.4.1 local-part is case-sensitive. However most main
providers do consider the local-part as case insensitive. With the introduction
of smtp-utf8 within odoo, this assumption is certain to fall short for
international emails. We now consider that
* if local part is ascii: normalize still 'lower' ;
* else: use as it, SMTP-UF8 is made for non-ascii local parts;
Concerning domain part of the address, as of v14 international domain (IDNA)
are handled fine. The domain is always lowercase, lowering it is fine as it
is probably an error. With the introduction of IDNA, there is an encoding
that allow non-ascii characters to be encoded to ascii ones, using 'idna.encode'.
Also remove usage of 'email_re' in mailing email check. It is too restrictive
compared to real formatting we support (or try to). Valid outgoing emails
were directly canceled, notably when containing unicode.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@3ce5fb3072
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS: MAIL COMPOSER IN MAILING
When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.
We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.
Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.
SPECIFICATIONS: DEFAULT RECIPIENTS
Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...
This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.
In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@4a0d87d44f
Part-of: odoo/odoo#134934
When having several possible emails to contact the first one is saved on the
trace model. Indeed a trace is normally linked to a unique recipient but
in case of multi-emails in an email field, several emails are available.
This commit ensure computation keeps the original mail_to when making emails
adresses uniques before sending mails and creating traces.
Followup of odoo/odoo@213d5d396c
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@b9b6fae9c5
Part-of: odoo/odoo#134934
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
*: phone_validation
- Add sample data in the mass_mailing_sms blacklist phone
numbers tree view.
- Update the mass_mailing_sms demo data so that, instead of
the sms being stuck due to a lack of credits, they are
all sent.
- Swap the mass_mailing_sms list view with the kanban view
so that the list view is the main one like in Email Marketing.
- Rename the reset mail template confirm button from "Proceed"
to "Reset Template" to make the action more explicit.
Task-3280602
closesodoo/odoo#119321
Related: odoo/enterprise#40120
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently some auto_reply templates are internal as a means to prevent
notifying users everytime we send a reply to somebody.
This raises the issue that since responses to internal notifications
are themselves internal notifications, often nobody will be notified of
responses to these automated messages.
We fix this by marking these messages as auto_comments, which will
ensure responses to these messages are
considered non-internal (and thus 'discussions', by default).
task-2834304
closesodoo/odoo#94018
Related: odoo/enterprise#35466
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this, the resource_ref field is computed once in the default_get.
This means if the cache is invalidated, its value is unrecoverable.
Notably, the cache is invalidated when an attachment is generated
(triggering a commit).
So calling _generate_template could invalidate resource_ref,
which we use as a key to retrieve its result.
This results in a traceback for the user when trying to preview
a template where the first record hasn't yet generated its attachment.
As an example, trying to preview `Sales: Send Quotation`
on fresh installs.
task-3162320
X-original-commit: b4bd93c9b61736a7f41d70afe5db977a6e4b35e0
Part-of: odoo/odoo#118710
If the preview wizard was used to preview a template on a model that
has no record, error_msg would not be set.
This means the field is never set in that case and creating the wizard
results in a cache miss on that field.
The fix is to simply set it, and we add a test to cover that flow of
the wizard.
task-3162320
X-original-commit: 0976ce53e0a97a1f49dc2a262cf66355242fde25
Part-of: odoo/odoo#118710
Always apply the blacklist in mass_mail composition mode regardless of the
recipient model implementing mail.thread.blacklist or not.
This solves the problem of mail sent to black listed address for model not
inheriting from mail.thread.blacklist.
Technical notes:
- it has been done in mail.compose.message _get_blacklist_record_ids ignoring
the mixin mail.thread.blacklist to avoid model change in stable.
- some tests have one added query because the blacklist is now queried for each
batch mail sends even if the model of the recipient doesn't implement
mail.thread.blacklist.
Task-2834862
closesodoo/odoo#118497
X-original-commit: 263e86114c60650f421354e165364afcd4122461
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When using the composer on a non-thread model a notification is sent instead
of posting a message, as the model does not support the posting process.
However there is currently a crash due to the default subject computation
which is solved in this commit.
Task-3254379
Part-of: odoo/odoo#117763
To reproduce the problem:
- Install project
- Remove all tasks
- Go to settings -> Technical -> Email Templates
- Select the template "Project: Task Rating Request"
- Click on Preview
Without the fix, a stack trace is displayed. With the fix, the preview is
displayed with the message "No record for this model" for the field "Test
record".
Technical note: the error happens because error_msg was not assigned in the
compute method of that field when the reference to the record is missing or
incomplete.
Task-3196081
closesodoo/odoo#116431
X-original-commit: 1f296539210a07e0b1aed0d9d3cd736c5cb33375
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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: layout translated based on recipient lang or fallback on template
'lang' field definition, or current user's lang;
* mailing: no layout supported;
PURPOSE
Make those the two composer modes less different by supporting layouting in
mailing mode of composer. Consider it a bit experimental.
SPECIFICATIONS
When using the composer in mailing mode, render email layout if given. This
layout is used to encapsulate body.
To simplify rendering and sending, consider all recipients to be 'customer'
as defined in '_notify_get_recipients'. This means all recipients receive the
same basic layouting currently as a first attempt to improve this situation.
Considered lang is the one coming from the template 'lang' field, or fallback
on current user's lang.
Task-3186426 (Mail: Support notification layout in template / email composer)
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 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
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
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>
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>
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 field ``force_send`` in compute method.
It is currently computed in a default_get override.
It is set to True in mass mailing mode (send directly by default) and in
monorecord comment mode (send notifications right now). Batch comment delays
notification to use the email queue.
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 fields ``model`` and ``res_ids`` in
compute methods.
Model can be set from parent or using 'active_model' context key frequently
used as the composer is most invoked from list or form views.
Res Ids computation may come from parent in comment mode, if set. It takes
the parent message's res_id. Otherwise the composer uses the 'active_ids'
context key, unless it is too big to be stored in database. Indeed when
invoked for big mailings, 'active_ids' may be a very big list. Support of
'active_ids' when sending is granted in order to not always rely on 'res_ids'
field. When 'active_ids' is not present, fallback on 'active_id'.
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
This field will be used to remove low-level asserts using existence of
'message_post' on a given model instead of correctly checking the
inheritance on mail.thread.
This is going to increase a bit query counters but those queries should
be fast and have no real impact on performances.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
Sometimes due to new ids / not existing records for previewing crash may
happen when rendering the preview of templates. In this commit we rewrite
a bit the computation to try to be more resistant.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Xavier Morel