We now return generated records when calling ``_action_send_mail`` on mail
composer. This allows to have access to generated emails (in mass mode) or
posted messages (in comment mode). Otherwise we have to access sub-fields
like activity_ids / message_ids, which may be inefficient or generate extra
ACLs checks.
Also replace some |= with += when usage of OrderedSet is not necessary. To
keep ordering, ordered sets are used when doing an or between record sets.
However in some cases we know we are simply adding records not already in
a previous record set, meaning we can just use +.
Task-2883589 (Activity performance and cleaning)
Part-of: odoo/odoo#93682
Purpose is to better spot field and classify them by usage. This code will
be modified soon and this prepares future modifications.
Task-2816845
Prepares Task-2088884
Part-of: odoo/odoo#98287
When sending a mass mail through the composer, if the field ``reply_to`` had to
fall back to being ``email_from``, reply_to would take the value of the template
syntax instead of the rendered value.
This is notably the case when mass-mailing invoices through the accounting app.
Resulting in reply_to fields such as: '{{user.email}}'
On some mail clients (including mailhog), this could also result in template
syntax being shown as part of the subject or sender field.
This commit fixes that by correctly taking the rendered value of 'email_from'
Task-2816845
X-original-commit: e320b852e8f1958ac3dccaa5333420bb7b8d8f3d
Part-of: odoo/odoo#98287
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Render safe option was used with Jinja rendering to tell Jinja that content
was safe and was not expected to be escaped. This was used notably in subject
as characters like ``&`` was escaped in email subject (e.g. `R&D News`).
This is now supported directly by the "inline template" rendering engine that
is used to render text-based templates since Odoo v15 [1]. This option is not
supported by code anymore anyway and leads to nothing.
Task-2088884 (MailComposer: Onchange to editable computed stored)
Task-2710804 (MailThread Api Cleaning)
[1] See odoo/odoo@68182baff4
Prepares Task-2088884 (Mail: Composer Onchange to Editable Computed Stored)
Part-of: odoo/odoo#94660
This commit mainly fixes an override of ``_message_compute_author``. It is
done with an incorrect default parameter value for raise_exception defaulting
to False instead of True). By the way we also fix parameter naming in order to
ease understanding.
Part of Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#94660
When sending emails from CRM, you can save the mail as a new template.
Despite having selected the desired recipients, the mails sent will not
have any recipients.
Steps to reproduce:
1. Install CRM and open the app
2. Trigger the list view of the pipeline
3. Select any opportunities, go to Action and click on 'Send email'
4. Give a subject to the email and click on 'SAVE AS NEW TEMPLATE'
5. Send the email
6. Go to emails, there are no recipients for the emails generated
Solution:
Set the `use_default_to` to true by default when using the 'SAVE AS NEW
TEMPLATE' button
opw-2827177
X-original-commit: 1180b8cd9f0ed5bebdef97d702f29a5652fa6ac8
Part-of: odoo/odoo#93025
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Cleanup and improve composer-related tests. As composer will soon be improved
better ensure we don't break flows.
SPECIFCIATIONS
Cleanup existing tests: rename, make it use tools, reoder them.
Add some tests about composer in order to better spot changes and differences
as well as to help debugging mail composer code update. Notably add tests
with Form tool, add tests for reply-to computation, auto-delete, mail server.
Performance tests about composer are added, notably using the Form tool. This
helps determining differences between creating / manipulating a composer in
code and in UI. Indeed notably onchange and some side effects may lead to
different query counters, which is the case as highlighted here. Tests
involving attachments are also added to see their impact on posting process.
Task-2673913 (TestMail: Cleanup and improve test coverage)
Part-of: odoo/odoo#86393
Those indexes probably come from previous implementation of composer model
when it was inheriting from mail.message. It was also inheriting from the
custom search / read manual ACLs implementation doing some SQL directly to
check access. Those indexes should not be necessary anymore as anyway this
is a transient model.
Prepares Task-2088884 (MailComposer: Onchange to editable computed stored)
closesodoo/odoo#85841
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.
This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].
Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.
A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.
Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.
issue 2746483
[^1] well not entirely true, see 4th paragraph
X-original-commit: 60723fb311ed7cc1cf901fe90e8745835cf4d54d
Part-of: odoo/odoo#85271
This field is a duplicate of email_layout_xmlid and is actually never used.
Followup of odoo/odoo#76418 .
Task-2732660 (Mail: Remove duplicate layout field on composer)
Part-of: odoo/odoo#82167
In order to make fields a bit more explicit, let us rename "add_sign" to
"email_add_signature". It indicates it is linked to the email notification
process, adding the signature depending on the notification layout itself.
This is done on both mail.message and mail.compose.message models. It is
also updated as rendering value parameter used in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Traceback on the ticket:
https://pastebin.com/mCAFJVWG
A browse should take an id or a list of ids as parameter.
```python
record = env['mail.compose.message'].browse(1)
attachments = env['ir.attachment'].sudo().browse(record.attachment_ids)
print(attachments)
attachments = env['ir.attachment'].sudo().browse(record.attachment_ids.ids)
print(attachments)
```
OPW-2728748
closesodoo/odoo#82664
X-original-commit: 74cfe2bc95827b52232995cd075757f54041d289
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
To be able to copy an attachement, we need to be have write access on
the linked record.
In this wizard, write access on mail.template is then required which
is no longer the case since cc012a0864
Read access on the template is already checked when reading the values
of the tempate.
closesodoo/odoo#79900
X-original-commit: ce342f42f21cad3aa5606f6ab0b5739f29f0c456
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
On the CRM module, the user can send an email to all the contacts
associated to the leads matching some criteria by (1) displaying the
list view, (2) applying a search filter, (3) clicking on the "EMAIL"
button and (4) checking a checkbox on the mail composer to ask the
server to use the active search. To do the same thing, the user can
(1) display the list view, (2) apply a search filter, (3) select all
the records and (3) click on the "EMAIL" button.
To avoid redundancy and improve the usability of the composer, we will
remove the search domain passing from the mail composer. Note that it
will still be possible to pass a search domain programmatically.
To improve the guidance of the mail composer, we will add helper
messages, update the labels and move the options in a dedicated pane.
The wording of the buttons will also be updated dynamically based on
the selected options.
Example: When the user enters something in the `mass_mailing_name` field
to create a new mass mailing campaign from the new message, the label of
the "Send" button will be set to "Send Mass Mailing" which gives more
indication on what will happen when the user clicks on it.
task-2523036
Part-of: odoo/odoo#71413
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
As create_uid has no value on mail.compose.message model when being in onchange
or new mode, 'Mail Compose Message Rule' record rule may crash. In this
commit we fix that issue by adding a value for create_uid. An unit test is
added to ensure it effectively fixes the use case.
Steps to reproduce this warning:
1. Create automated action for the 'mail.compose.message' model
2. Try to open 'Email compose Wizard'
Warning:
"Due to security restrictions, you are not allowed to modify 'Email composition
wizard' (mail.compose.message) records.
Records: mail.compose.message,NewId_0x7f8e99762310 (id=NewId_0x7f8e99762310)
User: USERNAME (id=2)
This restriction is due to the following rules:
Contact your administrator to request access if necessary."
Task-2641572
opw-2628005
PR odoo#76159
Closes#75369
X-original-commit: 26d64c0b84b76bb9164a8895bcc21b66754478ae
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to keep blacklist and optout lists computation
at mailing level and correctly call it in composer. This allow to have
a clearer and more readable code as well as more robust.
Currently it is done by adding this information in context before invoking
the mail composer. It is now correctly done in composer: if a mailing is
linked to the composer, it calls both blacklist and optout lists methods.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
RATIONALE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Purpose is to prepare future changes by easing its grep. Notification is too
much heavily used through the codebase and finding it was quite hard among
other noise.
Rename ``notification`` field to ``is_notification``.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently most of mail related failure types are computed in mass mailing.
This is mainly due to historical reasons. We could move some of this
computation directly at mail level and store failure information directly
in mail.mail records.
SPECIFICATIONS
Overall purpose is to get near SMS implementation where base composer prepare
more advanced pre computation: blacklist, optout, seen list.
Detect and store failure types directly on mail.mail: blacklist, optout,
duplicates, missing email, wrong email, ...
State computation is moved from mass mailing to mail. It is also improved as
currently everything is based on "first recipient found". This is globally
valid for mass mailing who uses default recipients (customer). However when
dealing with generic mailing this is not true anymore.
We choose to store and update status on mail.mail records only when having
a single recipient. When several recipients are defined on a given mail.mail
we cannot really decide a status prior to sending it and skip this computation.
Mass mailing override now uses information from mail.mail to update its linked
traces as computation is now delegated to base composer model.
LINKS
Task ID-2377974
Community PR odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
``mail.compose.message`` is still overriding default mixin behavior to keep
a minimal fix. Rewriting composer code is planned but will not be done with
this task. Here we keep current behavior, technically and functionally.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
When using the "Send & Print" functionality, if the user adds an
attachment, the latter won't be linked to the record.
To reproduce the error:
1. Open a posted invoice
2. Send & Print
3. Attach a file > Select a file on your device
4. Send the email
Error: The invoice's PDF is added to record's attachments, but not the
other file (from step 3).
When the module selects the attachments that need to be linked to the
invoice, it only keeps the ones currently linked to `mail.compose.message`:
https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725
This is correct when the user creates a message directly in the chatter.
However, when the mail is created thanks to `Send & Print` functionality,
the attachment is linked to `account.invoice.send`.
Another flow have a similar issue: from invoices list, select few ones,
Action > Send & Print: the generated PDF won't be attached to their
invoice. In such a situation, here is the source of the problem:
https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367
There isn't any information about the invoice, therefore it is not
possible to linked the attachment to it.
OPW-2438457
closesodoo/odoo#71495
X-original-commit: 98d3748aca724ef06db89294531d82679df45b74
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The optimization 2ccf0bd0dc does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.
Added test without the fix fails with:
AssertionError: False is not true : MailTrace: email
test.record.02@test.example.com (recipient res.partner(), state:
sent, record: mailing.test.blacklist(166,)): found 0 records (1 expected)
opw-2536304
closesodoo/odoo#71277
X-original-commit: 965c67cb16d2a4ac10d35a01da3af311867a47e6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
PURPOSE
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
SPECIFICATIONS
For better understanding, this commit renames ``no_auto_thread`` field of
``mail.message`` model to ``reply_to_force_new``, to indicate that if the
field is checked (☑) replies should check gateway alias rules instead of
updating mailed threads.
It is also more coherent with reply_to namespacing used in various mail models
(notably new composer fields and ``reply_to_mode`` of mass mailing and mail
composer models)
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
PURPOSE
Right now, `reply_to` field on email template is misleading due to poor
explanation. This commit improves the placeholder and tooltip of the fields
to make the purpose of the field clearer especially for non technical users.
SPECIFICATIONS
Update reply-to field placeholder to "Preferred email address when sending
via mass mailing options".
Update reply-to field helper message to "Preferred email address when sending
via mass mailing options. <br> Only used when the answer is not added into
the original discussion.""
Update the no_auto_thread field label to "Reply to" in composer and introduce
a new radio button replacing the checkbox
* The original discussion (thread)
* Another email address (new)
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Before this commit:
When someone sends mail with help of mail_composer(mail.compose.message)
without having a mail template set, mail is not deleted after being sent
(and causes unwanted/unexpected burden on DB). This bug was introduced
with commit[1], where auto deletion was disabled if template is not set
on the composer.
After this commit:
If there is no mail template set on the composer, or if the template is
set and 'auto_delete' is enabled on that template, the mail sent from
composer will be deleted after being sent successfully.
A context key is added to allow controlling this behavior. It is notably use
to check query counters differences.
commit[1] - https://github.com/odoo/odoo/commit/8a026e26c6ae25e3fdb5369a7fa3343d70fab782#diff-898a3d5c08a567c1a7b82c026a213d796e850e376cbdb1c9e7936409f440d37aR257
Task id: 2484915
PR odoo/odoo#68870
Original Pr #68403closesodoo/odoo#69203
X-original-commit: d54973ee1b4457e3d1c0c8d9bf226928530d8b30
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Connect with Admin
- Go to Contacts, edit himself by adding a Private Address
- Create an Internal User without "Access to Private Addresses" right (i.e. User X)
- Go to any app implementing chatter (i.e. Sales)
- Create a SO
- Add the created Private Address as follower
- Make sure User X can access the record (i.e. Sales: Administrator)
- Connect with User X and open the SO
An Access Error is raised while trying to fetch data about the followers.
This commit prevents to:
- add a private address as follower of a record
- add a private address as Recipient in full composer
- propose private addresses when adding a mention to a partner
opw-2428936
closesodoo/odoo#68493
Task-id: 2463622
X-original-commit: 20536e1bbeb641539c0de44364f8376e7cef651b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The `{'infos': 'mail_sent'}` property returned by `action_send_mail()`
was apparently unused, and orginally intended for debugging, according
to its author.
Since previous commit adds a warning for such unknown properties,
removing it entirely keeps the testsuite green. And it's cleaner
than explicitly allowing that extra key, since it's unused.
closesodoo/odoo#63009
X-original-commit: 7c8c5a9cd716d35783734493cbb15b194e7b787c
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
As default is called numerous times with sometimes all fields, sometimes
only one field we have to ensure we avoid computing and setting unnecessary
or wrong values. We suspect this comes from default_get being called more
often at creation time since Odoo v14.
Default values for some fields in mail composer are dependent on each other.
Especially composition mode and model / res_id(s) are important for some
fields as behavior is not the same in comment or mass mail mode (subject
set / not set, template values rendered / displayed raw, ...).
Especially subject is wrongly computed in mass mail mode. For example use a
mass mail composer action on leads without template. Indeed a default_get
is called on subject alone. As web client adds active_model / active_id
automatically default returns a value for subject while it should not as
other values (model, res_id) are not asked and therefore not correctly
computed. It makes composer compute values in comment mode while it should
stay in mass mode.
In this commit we fix that behavior by
* computing only requested values (better match returned values and asked
fields);
* avoid computing values if context values are not given (model, res_id or
res_ids, composition_mode);
Task ID-2390314
PR odoo/odoo#62061
X-original-commit: 1c8ca358d75c9fe00631731d5061674c0a3a040b
For large lists of blocked emails, the time taken to load the records in
cache becomes prohibitive. For instance on a sample blocklist of 600k
entries, the `search([])` to load them could take 80-90s to run!
And this toll is taken every time the mail composer processes an email
batch in mass-mailing mode. Technically, most of the time is spent
iterating on the list of ids many time, in order to prefetch fields
into cache by determining what's missing.
Loading the contents of the list in raw SQL takes a fraction of that
time (400ms vs 90s).
Subsequently using a set for lookups in that blocklist is also much
faster (average time complexity O(1) vs O(n)).
Example: looking up an item in a 600k-entry blocklist is easily 5
orders of magnitude faster!
```
In [1]: blocklist = set(x[0] for x in self._cr.fetchall())
In [2]: len(blocklist)
Out[2]: 634610
In [3]: self._cr.execute("SELECT email from mail_blacklist")
In [4]: blocklist = set(x[0] for x in self._cr.fetchall())
In [5]: %timeit "hello@hello.com" in blocklist
The slowest run took 35.29 times longer than the fastest. This could mean that an intermediate result is being cached.
10000000 loops, best of 3: 31.6 ns per loop
In [6]: self._cr.execute("SELECT email from mail_blacklist")
In [7]: blocklist = [x[0] for x in self._cr.fetchall()]
In [8]: %timeit "hello@hello.com" in blocklist
100 loops, best of 3: 2.24 ms per loop
```
closesodoo/odoo#57129
X-original-commit: 3b9a85754f30f0bef508d0b576ff679c87ead5da
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
PURPOSE
Since v13 some commits added code in mail thread file. This file is already
quite long and keeping it organized allow to understand its content.
SPECIFICATIONS
Some methods defined on mail.thread may actually be called on models
not inheriting from mail.thread . Instead of having model methods on mail
thread receiving a records parameter it seems better to have those available
directly on BaseModel.
Move static_message_track on BaseModel in models.py. This method is now called
_mail_track, to be coherent with othe rmail-related naming. It is used in
accounting to track values in line model that does not inherit from mail.
thread. Update accounting accordingly (followup of d862965).
Move _message_get_default_recipients_on_records in models.py. Renaming it
_message_get_default_recipients() allow to be compatible with current behavior
and current override available in some addons (like CRM, event, ...).
Move _notify_get_reply_to_on_records in models.py. Renaming it
_notify_get_reply_to() allows to be shorter and coherent.
Move _alias_check_contact_on_record in models.py. Renaming it
_alias_check_contact_() allows to be shorter and coherent. Its override in
hr is also moved on BaseModel.
LINKS
Task ID-2327096 (code cleaning)
PR #56631
X-original-commit: f5df1ed912455e5ed52a65df3149f30a9d424de0
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
We also have to update code calling directly the rendering itself. Indeed
some code bits does some rendering directly on jinja-enabled input and not
through templates. Those calls have to be updated accordingly.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
Currently the message for help tooltip of auto_delete field is not sufficiently
clear for user to understand.
In this commit, improving message for help tooltip by adding some extra details
in it so user can easily understand about it for models mail.mail, mail.template
and wizard mail_compose_message.
Task-2055702
Closes https://github.com/odoo/odoo/pull/45063closesodoo/odoo#45063
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Thibault Delavallée