When computing recipients based on template we generally create new partners
based on emails. This is due to the mail framework managing mainly partners
and not low level emails.
This code is currently sequential: fetching or creating partners one by one
based on found emails, for each record. This is highly inefficient when
sending emails on a lot of records based on templates.
Purpose of this commit is to improve code and performances by batching. We
do queries in batch: one search for all records, create partner in batch. This
leads to code being a bit more complicated to correctly remember and dispatch
again emails and partners to the correct records.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract fields generation on template for fields
not belonging to recipients or attachments in sub-methods. Code is cleaned to
better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
First sub method is dedicated to 'scheduled_date' which is dynamic and has its
own post processing (to be UTC agnostic as expected by ORM). Second one is
dedicated to static values coming directly from template without rendering.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract attachments generation on template in
its own sub-method. As it contains code specific to attachments, better
have it separated from the main global generation method. Code is cleaned
to better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to improve recipients generation on template.
Code is cleaned to better support parameters and be easier to call. It
can now be called independently from the main ``_generate_template``
method. Docstrings are updated.
Changes
* removed support of ``tpl_force_default_to`` context key used to somehow
simulate the check of "use default recipients" (??)
* removed support of ``tpl_partners_only`` context key used to force to
find or create partners based on emails generated by the template. It
is replaced by a parameter to propagate;
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Currently some value are always computed and added even if not asked by the
caller. As asking a template to render some fields is now used notably for
a subset of fields (subject and body, from / to, ...) there is no need to
automatically add other irrelevant information.
Main callers already filtered out returned results (notably composer). However
better avoid computing / rendering unnecessary stuff directly at template
level.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to prepare further improvements in template and
composer rendering methods. First step is to
* make them private;
* correctly name parameters (notably rename fields to render_fields to avoid
collision with odoo.fields);
* remove the "single / multi" mode. This is a relic of old implementation
when rendering was done mainly record by record and sometimes by batch.
Now everything should be batched;
* split some lines to ease future diff in upcoming commits;
* improve some docstrings;
Next commits will rewrite and split parts of ``_generate_email``.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
'email_from' fields are not necessary on 'sale.order.cancel' and 'survey.invite'
as anyway we always use the current user's email and field is not present in
form view. Override of default_get to raise about invalid email_from is not
necessary as anyway it raises when posting the message. Giving author_id to
message_post is sufficient as it computes email_from based on author when given.
Add 'render_model' in views, as it is part of the domain given to 'template_id'
field of composer mixin. When missing, also add 'lang' and 'template_id' that
come from the render mixin.
Use '_render_field' when possible instead of '_render_template' as its API
is simpler and uses field definition for rendering parameters.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
A method ``_message_set_main_attachment_id`` exists to handle main attachment
reference, used notably in discuss and accounting. It is now called inside
``_message_post_after_hook``, so that it is part of the post processing after
having posted the message. Its API has been updated so that attachment_ids is
now a real list of ids, which is clearer.
A wrong override of '_message_post_after_hook' dealing with parameters is
cleaned while passing by.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Notification method 'message_notify' is sometimes used as a standalone method
to send notifications. In that case it is called directly on MailThread
abstract model, notably when there is no context record or when it does not
inherit from 'mail.thread' directly. This is done mostly in technical models.
However in that case some model-specific code is not called, notably methods
computing default subject. In this commit we improve some calls to be sure
notifications have content enough to be understandable.
When possible, we also redirect the notification method on real records
inheriting from mail.thread, enabling a more complete process.
See community PR for more details.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SPECIFICATIONS
Update methods parameters to look more like 'message_post' definition. Add
docstrings to explain parameter usage. Cleanup some parameter we do not
want. Add a api.returns on message_notify to wrap the value in case of external
call, as this method is public, like message_post.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When calling "_render_template_qweb_view", parameter can currently be an
XmlID or an id. It can now be a recordset, allowing easy calls from Odoo.
Slug is also added in evaluation context to prepare further cleaning in
message_post helpers.
Some error messages are also improved while passing by.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose of this commit is to clearly check input of ``message_post`` method
and its main helpers in order to prevent wrong usage of message post API.
Some values used to populate message fields should not be set directly when
posting or logging messages. Indeed they may be part of other process (like
notification process managed by ``_notify_thread``, or could be setup by
custom routes like 'reaction_ids', or custom usage of 'model' and 'res_id'
that could conflicts with record on which methods are called).
We therefore add checks and cleanup in those methods to be sure the API
is used as intended and avoid unwanted side effects.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose is to be able to create find or create partners in batch based on a
list of emails. When sending email in batch, notably using templates, doing
sequentially a search or create for each potential email to contact is not
efficient from computation point of view. This commit introduces a new batch
method for that purpose.
If no valid email is found for a given email, it is used as it to try to
find partners with same invalid email and/or keep the value in order to
allow updating it afterwards. Notably with notifications resend it is
possible to update emails, if only a typo prevents from having a real
email for example.
Falsy emails do not create partners as those have no real interest.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Fix usage of CCs when sending emails. Currently CCs are added to all outgoing
emails, which leads to unnecessary spam. Recipients are currently computed like
* create an outgoing email based on 'email_to';
* create one outgoing email / partner in 'recipient_ids';
* add CCs to all outgoing emails;
They are now sent only once, either with the email_to if given, either as
standalone. That way partners receive specific emails (due to tracking and
partner specific links management), email_to / email_cc are sent on their own.
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
In this commit we add some logs when we fail to evaluate the 'headers' field
on a 'mail.mail' record, used to populate the headers of outgoing emails.
Some tests are added to ensure we do not crash if headers is malformed, and
to cover the feature itself as it was still not really done.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
RATIONALE
When sending a ``MailMail`` some data preparation is done. This is done
directly in ``_send`` and in sub-methods. As a given MailMail may lead to
several emails being sent we have to go from a mail to a list of emails
to send :
* one email for ``email_to``. They all receive the same email, as those are
just a list of emails to contact and no specific post-processing is done;
* one email for each partner in ``recipient_ids``. It enables a partner-based
update of the body, for example for links or traces in mass mailing;
SPECIFICATIONS
In this commit we move code so that all preparation is done in a sub-method
``_prepare_outgoing_list``. That way it can be cleanly overridden to add or
modify values before sending the actual emails.
This commit does not change behavior and calls done to ``build_email``. This
will be updated in the next commits, notably to improve "cc" management.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
Composer holds code to check recipients email and avoid sending emails when
recipients do not have valid emails. Purpose is to avoid bloating the email
queue with emails that are about to fail.
It is done by analyzing recipients of emails, aka checking 'recipient_ids'
value before creating the mail.mail.
When being in comment mode, this code has no use as recipients are computed
by the notification process, not by the composer. We can therefore skip this
part. It adds the 'state' and 'failure_type' values that are used on mail
model, but not on messages.
The same kind of processing could be done in notification process to avoid
sending unnecessary notifications, but this improvement belongs to another
commit and task.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose of this commit is to add tests for exclusion list and duplicates
management in composer.
When being in email mode (mass_mail) state of emails is pre-processed in
order to already flag emails that should not be sent or will bounce back.
Notably emails in exclusion list or duplicates emails are set as cancel
with the right failure type.
Some tests already exist at higher level in mass mailing but having tests
at composer level is better when trying to improve code and add tests for
corner cases.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
In this commit we add a method to check MailMail, based on a given record.
When having duplicates to differentiate in a given mailing, having just
recipients is not sufficient as multiple emails may match a given recipients
list. Checking model / res_id is another method for finding emails.
This will be used notably to add tests for exclusion list and duplicates
management in standard mail composer, outside of mass mailing context.
While being at it, use subTests when having loops checking values. That
way it is easier to fix tests that have several failing values in the same
global assertMailMail_* .
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to avoid html entities in sent emails message by
correctly using string and html formatting.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose of this commit is to avoid html entities in logged message by correctly
managing enclosures. For that purpose a new tool 'nl2br_enclose' is added that
eases Markup management on top of 'nl2br' simple tool.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In website(_sale) messages are created from website forms. However those
are technical models, you should always use the MailThread API notably to
ensure values coherency. In our case using message_log seems to be what
original committers wanted to do (even creating a message as a comment
which has no effect as the notification process is not called that way).
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In this commit we correctly set 'error_msg' field as computed. As it was not
defined as computed, it was not really updated and therefore not displayed
in the preview form view. It is now the case.
ValueError are now also catched, for example when having badly configured
'partner_ids' field we may face this kind of error, which is now logged
in the preview wizard.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Sometimes the previewer crashes in rendering with cache-based records, hence
trying to check directly the id of the related reference record.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Mail holds an helper function to convert datetime from a char input into a
datetime value. It is used notably when having to store a datetime value
(e.g. on a mail_mail) from a string generated by templates with expression
like ``{{ datetime.datetime.now() + datetime.timedelta(days=2)}}``.
In this commit we explicitly remove microseconds, as otherwise we end up with
something that the web client cannot parse, not speaking of even going into
server side storage with this value not matching the expected format.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Update counters according to latest runbot counters. It allows to better spot
side effects of upcoming changes.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
There is a lot of use case where reports are exclusively in the company
currency, or have columns only in this currency. In these case, showing
the currency symbol is redundant, takes space and makes the reading
slower.
With this change, we will avoid displaying the symbol in a variety of
use case where it is not needed.
Task id #2868674closesodoo/odoo#109666
Related: odoo/enterprise#35671
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
* = digest, hw_posbox_homepage, im_livechat, mass_mailing, web_editor,
website, website_slides_forum
Since the migration of Bootstrap 5 [1], some CSS rules was automatically
converted (`border-left` and `border-right`) when it shouldn't be.
These conversions were made because the CSS rules was embedded in
HTML/XML code and the REGEX for the conversion had no protection for
these cases.
This commit restores the old correct value.
Ref:
[1] odoo/odoo@1fcd098af5closesodoo/odoo#110141
X-original-commit: 0cbf7c00ecc307fc725da345415647828e771bb4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Export tool is based on ORM method `_export_rows`. The method has special
processing of m2m fields when user checked *Import compatible* option [1].
Before this commit the negative value of `import_compatible` parameter wasn't
passed when data are exported in grouping mode. This led to empty values in m2m
fields.
STEPS:
* Order some products via website and pay via wire transfer
* Open Orders menu in backend
* group order by any field
* expand group with the order
* add field *Transactions/Acquirer/Display Name*
[1]: https://github.com/odoo/odoo/blob/b28c44a38698018ebbbc420f6567c17b2b97c279/odoo/models.py#L894-L914
opw-2864737
closesodoo/odoo#110151
X-original-commit: 6647ac83467207f4f4ef23aac96ebaf5333b967b
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
closesodoo/odoo#110149
See: 26dd1d9627cdd04e12c3187f0f53c0e11892a345
X-original-commit: b03d4c6436472d5e78bcdd612171ce56c56d906c
Signed-off-by: William André (wan) <wan@odoo.com>
There was an error in the XML template of the department org chart, the
opening tag was a `<t>` but closed with a `</div>`...
closesodoo/odoo#110142
X-original-commit: 10ce40dd6b181f6dd6e434f208aa9f13b33975d3
Signed-off-by: Kevin Baptiste <kba@odoo.com>
An analytic account was searchable in an invoice with the Ref field.
Before this commit, it is not possible, while it should.
So we add it to the search domain.
opw-3119740
closesodoo/odoo#110135
X-original-commit: f5e24b8f7ba4291b0e5ea970da948215b83e6184
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Before this commit, when somebody updated the status of recurrent meeting
the dialog was crashing because the component was destroyed and the orm call
could not be done.
X-original-commit: 544b7d9bf805f7860dd318293964cf822b05e0b9
Part-of: odoo/odoo#110133
Before this commit, when unfiltering a column in a kanban view, a
flickering occurs and the show more button is visible for a moment.
closesodoo/odoo#110130
X-original-commit: 0cd9c7dbba12e362a6445f47d52b43c48dffdb61
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the keep alive timeout could occur for many websockets at
the same time resulting in a burst of transaction (cursor is open when connecting,
disconnecting a websocket).
This issue was even worse because the cursor was opened even when it was
not needed: we don't need to open a cursor if there is no callback
registered for the lifecycle event (OPEN/CLOSE).
This commit fixes those issues by:
- adding a random delay to the keep alive timeout of every websocket.
- not triggering lifecycle events if no callbacks are registered.
closesodoo/odoo#110127
X-original-commit: b4fb1359021b6c882ece3037c82aaaf65cfc2e1e
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit fixes the export when all records are selected (full domain).
Since many records ids might be present when an entire domain is selected,
the request should contains 'false' instead of a list of ids. As a limit
is set in session.active_ids_limit, not all the records were considered.
This means that only the limit was actually exported instead of the full
list that is present. As the legacy implementation of the ExportDialog
allowed to export all records, the behavior has been fixed.
A test has been added to verify the correct parameter during the download
call.
closesodoo/odoo#110126
X-original-commit: 7200e1c5875bc148fb64187fd67d58a7d6c13c7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, exporting templates were not filtered as
expected. It means templates were visible even on other domains,
polluting the list of templates of a model.
This restores the legacy behavior by filtering the domain in the
rpc and only displaying the desired template list.
A test has been modified to verify the presence of the domain
filter in the parameters of the rpc.
task #3127779
X-original-commit: 30a673c044e53bfb1edc1e6733b2c83c67e0232c
Part-of: odoo/odoo#110126
When a message is processed through the mail gateway, the partner should
never be set as the assignee of that task.
This commit allow to correctly let pass `{'default_user_ids': False}`
context from `message_new()` down to `create()`
closesodoo/odoo#110124
X-original-commit: 08e24d683bf19a77982a7ffba6c64b5fc6fdf85a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this change, if a user left a string value in a m2m_tags
and removed it afterward without selecting a tag, the update method
of Many2XAutoComplete would be called with false.
As the update method for m2m_tags expects a record or record list
this caused a traceback.
The fix is to simply skip the update in that case.
task-3109811
closesodoo/odoo#110123
X-original-commit: 14f314feb7594dc888de6af4e4ad23a948044854
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, in the kanban view, if we click the progress bar to
filter the column multiple times, the count of records number's could
show an incorrect value. This occurs because when removing the filter
from the progress bar, an animation is done to the number (to increase
the value until the correct number of records). Contrariwise, when
activating a filter, the number of records is set directly without
animation. When we remove and add again a filter quickly, the animation
to increase the value of the number finishes when the filter is already
apply and the value shown is the old count of records (without the
filter).
To avoid this, in this commit, we stop the animation when the count of
record changes.
Unfortunately, testing this is very complicated (because it involves
animation frames and Date.now()), and as the cost/reward ratio is very
low, we didn't add a test of this behaviour.
closesodoo/odoo#110121
X-original-commit: 4c8bb53df6ad6382c5b168532c8493ddbb1f7252
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
How to reproduce:
- Have a report line with a custom creation with a 'balance' label
- Replace the expression by an `account_code_formula` in the xml
=> The 'balance' expression does not exist anymore in the xml,
so the ORM removes it, and a new one is not created.
We changed the update so only 'balance' label expressions are changed:
- if we have an expression with an xml_id, we remove the expression and
recreate a new one.
- if we don't (custom created or coming already from a formula shortcut),
we just update its values.
We also created a way to remove a formula shortcut (making it falsy will
unlink the expression that was linked to it)
closesodoo/odoo#110119
X-original-commit: d01a7b76bee4471444eeedacc05bd52fe9c0399c
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
before this commit, from the payment providers menu, even though the provider is not installed in the database, the company, website and image fields are editable for the users.
after this commit, the fields will be editable/visible only after the provider is installed in the db.
publish/unpublish button will be shown only when provider is installed.
closesodoo/odoo#110114
X-original-commit: e910dee3ce4b526aa956ad489e83442b3a425c36
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, a user opening a spreadsheet containing pivots/lists/graphs
that they don't have the rights to access (be it because of the parent
model or the domain applied) will end up in an infinite loop.
While starting the datasources, the fetch step will throw, potentially
spamming the user with access errors.
Manual forward port of https://github.com/odoo/enterprise/pull/35146
Task 3107650
closesodoo/odoo#110113
X-original-commit: 1555e79be0b52c30df43e8de50f5db56fbbda630
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Currently, when we select Transportation Mode with Rail, Air or Ship and try
to generate an e-waybill the system raises an error. because of using the wrong fields.
Also made some improvements:
- updated error message
- updated timeout params for jsonrpc because, in the test server, it takes around 61 seconds so we set timeout to 70 seconds.
- filter E-waybill Document Type based on the invoice type
closesodoo/odoo#110111
X-original-commit: d6e40019c137dc353ecaa4785f91d6afa4cf954d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
Thibault Delavallée