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#112331
Related: odoo/upgrade#4320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Bug
===
When we remove some mail messages, we invalidate the cache of the
related documents. But in the same loop we call _invalidate_documents
which invalidate the cache, and so at the next iteration we will need
to make a new SQL query to know if the message is a "thread message".
So because of the prefetch ids, and because we invalidate in the loop,
if we unlink 1000 message, we will make 1000 SQL queries to fetch the
fields values of the 1000 messages.
Note that the unlink method will invalidate the entire cache anyway,
so unlike the write / create methods, we shouldn't need to invalidate
manually the related documents.
Task-3171093
closesodoo/odoo#112494
X-original-commit: f8958e9bbd4c7c37f614b20f7ed4d4825d438362
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The goal of this revision is to re-use the environment among the
different steps of the registry loading,
instead of creating a new environment for each step.
1. Simply To avoid to repeat the line
`env = api.Environment(cr, SUPERUSER_ID, {})`
multiple times in the code
2. This also allows to share the context among the different
steps. This is not yet used in this revision, but it could
be, for instance to avoid the current repetition to add the keys
`install_module`, in `convert_csv_import` and `xml_import._tag_record`
Part-of: odoo/odoo#108254
Warnings show up when using a recent pylint. It's only a fraction of
what e.g. pycharm flags as "local variable might be referenced before
assignment" but seems a good idea to fix anyway in prevision of
possibly eventually updating the reference pylint.
closesodoo/odoo#107968
Signed-off-by: Xavier Morel (xmo) <xmo@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
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
In some cases, a given user may create a message in behalf of other people.
This happens for example
* when calling message_notify to send notifications in a given flow, while
setting author_id to someone else (e.g. appointment flow who send invite
as notification, using the event responsible as author);
* when using templates with email_from set which may update the author_id
to match the email_from;
Notably with message_notify the current user may create a message he cannot
read afterwards, as he is not the author (as in 'author_id' field value)
and cannot read the message even with access on related record (as it is
a 'user_notification').
In this commit we relax a bit the 'read' rule on mail.message to allow reading
a message the user created.
Task-3093257 (Mail: The Composer Update)
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
Method 'message_notify' is a simplified version of 'message_post' to use
to notify people of something, without posting on a document. It creates
a "user notification", a specific kind of message.
In this commit we make 'message_notify' process attachments like posting
does. That way the API is more similar between those two methods. Moreover
it allows to give 'attachments' to notify. Those are then transformed into
real 'attachment_ids' and converted if they come from the composer.
That way the mail composer can be used in notification mode with attachments.
This happens notably when using a template on a record that does not inherit
from MailThread. It is a classic usage of 'message_notify' which allows
notifying on documents that have no chatter, notably technical or admin
oriented models.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
When activating the option "Restrict Template Rendering" the employee
group no longer gets the group automatically via the Implied Groups
field. However this did not have much effect because
- all the existing employees still had the group
- new users had the group via the template user
Remove the group with active_test=False to include the Default
Template User in the list.
Before this commit it was a bit confusing that new users still got the
group by default, even after deactivating the option in the settings.
closesodoo/odoo#110900
X-original-commit: ea0f674ac15964aaeb3def31758cec558b354a99
Signed-off-by: Martin Trigaux (mat) <mat@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>
This commit aims to notify the user (currently through an email) that some
important security parameter of his account has changed.
Here is a list of what is currently notified:
- password change
- login change
- email change
- 2FA enabled/disabled
- trusted device (for 2FA) added/removed
This email is rather simple and only invites the end-user to take actions if
that change was not done by him (reset password, contact administrator, ...).
Task-2639168
closesodoo/odoo#94922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, the email field is not required in the model level as well as in the view level, and this is the only normal(other than compute) field in the model. as it is not required now, user can create as many record without inputing any values.
Settings -> Technical -> Emails -> Mail Gateway Allowed
after this commit, the email field will be required and record can be created only by adding the email.
closesodoo/odoo#110026
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Purpose is to ease understanding of those default values and prepare move
towards editable stored computed fields by rewriting a bit the code to better
understand its purpose.
While being at it, some tests introduced recently are moved at their right
place now that everything is ready to rewrite the posting API and the
composer. Some tests are added to ensure notification-specific methods are
called along with the newly-introduced '_message_compute_subject', aka methods
to add custom header and custom mail values.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in compo
Part-of: odoo/odoo#99482
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
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
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
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
This commit adds checks in the view validation, to detect the use
of implementation details in archs. The goal is to prevent people
from using owl directives in archs (e.g. t-on-click). Recall that
a view arch isn't an owl template, it must follow the DSL of the
given view type.
In kanban, gantt and activity archs, using `t-xxx` attributes is
forbidden, except for directives historically supported by qweb
(e.g. `t-esc`).
In other views, using `t-xxx` attributes is forbidden (except for
`t-translation`).
In all views, using attributes `data-tooltip`, `data-tooltip-template`
and `data-tooltip-info` is forbidden.
Task 3085357
closesodoo/odoo#107083
Related: odoo/enterprise#35352
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
All emails sent from the chatter start with "Re:" followed
by the name of the record. The name of the record alone is sometimes not enough for
the followers to understand what the mail is about.
Additionally, "Re:" does not make sense when starting a conversation.
This commit gives better default subject
for event registrations and allows thread models
to override the default subject of messages.
This also removes "Re:" from default mail subjects.
Task-2833215
closesodoo/odoo#95817
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The field `notified_partner_ids` has type Many2many with relation table
`mail_message_res_partner_needaction_rel` [1] which is a regular Odoo model
`mail.notification` with some extra fields. One of those fields is required:
`notification_type`.
On copying `mail.message` record, ORM copies Many2many fields directly without
using `default_get` method for `mail.notification` model. Particularly,
`notification_type` get null value and we get an error.
STEPS
1. Create Server Action for `mail.message` model:
```py
for message in (records or record):
message.copy({
"subject": message.subject + "(SA copied)",
})
```
2. Add contextual action
3. Open `mail.message` which has non-empty value on
`notified_partner_ids` (*Partners with Need Action*)
4. Run the Server action via Action menu.
PROBLEM
```
ValueError: <class 'psycopg2.errors.NotNullViolation'>: "null value in column
"notification_type" of relation "mail_notification" violates not-null constraint
DETAIL: Failing row contains (11, 210, null, 3, null, null, null, null, null,
null, null, null, null).
```
SOLUTION
Fix it by adding `copy=False`, because we don't want to copy those values
anyway (confirmed by TDE).
[1]: The relation table is renamed to `mail_notificaiton` in v15+
opw-3069556
closesodoo/odoo#108599
X-original-commit: d68b0f7d6b8f973ddaafdd7526d4f753a1b6abd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
The tests consist in sending a mail related to a record to a customer and
checking that the record can be viewed through the embedded link:
- either in the backend if the user is connected and has the right to
- or in the portal otherwise
It also test that if the embedded link is tampered, the access is forbidden.
Task-2797311
closesodoo/odoo#105405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour
Start odoo without -d and with a --dbfilter that allows multiple
databases. Via JSON-RPC access the /web/session/authenticate route
providing a non-filtered database and valid credentials. Traceback,
`request.env` is None.
Since httpocalypse the initialization of the ORM (cursor, registry,
environment) is greedy. It means that the connection to the database is
established very early during the request routing or skip altogether in
case no dbname was known at that time. This contrast with prepocalypse
where the various ORM thingies were lazily setup the first time they
were accessed.
This changement has an important implication regarding authentication.
In prepocalypse, thanks to the lazy approache, a cursor/registry/env
would be setup on the database you just login upon using the
`request.env` for the first time. This was very nice in this regard but
had other problems.
Since httpocalypse such operation is no more possible. Devs must
initialize and use their own cursor/registry/env in case they
authenticate on another database than the one `request.cr` is (maybe)
connected to.
The `/web/session/authenticate` controller is an example of such case.
It crates its own cr/registry/environment after authentication. The
problem the controller uses `ir.http.session_info` and that not all
overrides were updated to use `self.env` (=the env created in the web
controller) instead of `request.env` (=the missing env of the request).
closesodoo/odoo#108063
X-original-commit: 7b9bd9d37731fae724dc5d91da656dab70aa9ad4
Related: odoo/enterprise#35012
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
Some mail clients set a wrong content-type for PDF attachments, they
set `binary/octet-stream` which doesn't exist[^1]. Odoo would crash
with a traceback in case it tried to extract the content of such
malformed attachment because Python doesn't know how to decode such
content-types.
Looking at the actual content of the emails we received, we would had
expected the content-type to be `application/octet-stream` instead. It
is fair to assume that the mail client software is buggy or poorly
configured and that it assumes that `application/octet-stream` and
`binary/octet-stream` represent the same thing.
Following Postel's Law[^2], it is better to still handle those malformed
emails, assuming the content-type is `application/octet-stream`.
opw-3030113
opw-2716507
[^1]: https://www.rfc-editor.org/rfc/rfc2046#section-3
[^2]: https://en.wikipedia.org/wiki/Robustness_principleclosesodoo/odoo#107317
X-original-commit: e6169325b968711a0a28444818b34aa1932a6bae
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Account_edi and various l10n submodules hold some custom code to generate and
handle EDI attachments. It is used to add attachments linked using AccountMove
specific 'edi_document_ids' field when sending emails based on templates.
Currently MailTemplate is overridden in accounting modules to hold code related
to AccountMove and AccountEdiDocument attachments manipulation. This is linked
to EDI and report naming, not mail specific. This should therefore not be
implemented at template level, but in those specific models.
For that purpose we introduce a method in MailThread that allow to handle
attachments when being in a template context. An override in account_edi
allows to implement its specific behavior.
By the way an old docstring in l10n_it_edi that was quite unrelated to the
override is also removed, as it was more confusing than helping.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Purpose of this commit is to try to make code a bit easier to follow using
dicts, sets and tuples, as well as updating some variable names.
Also rename the method to be clearer. Tools methods may omit the namespacing
to avoid too much confusion in naming.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
std-odoo