Returning after first loop iteration has the sad side effect of
somehow breaking batch version of methods.
Oversight of odoo/odoo@0ea27f430cclosesodoo/odoo#99630
X-original-commit: 6d6dbe16d4570372fe5fd3d28ebe5c43b646d3bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to add helpers on activity model, notably to ease batching based
on models. As activities are linked to records using a res_model / res_id
pair most code is not optimized (checking records one by one). Purpose of
this tool is to ease doing computation by batch of models.
Task-2883589 (Activity performance and cleaning)
Part-of: odoo/odoo#93682
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 use it notably in Voip where we link activities / phonecalls
to partners when possible. Future commits will use it more often in thread
methods.
Method to have the primary email is moved with that helper method in a sub
section, in order to have "model" helpers in the same section. Its code is
also simplified and fixed (return missing). Its name is made coherent with
other naming in the file.
Task-2884301 (Voip activity synchronization simplification)
Part-of: odoo/odoo#93682
Purpose
=======
When someone receives an email with a rating request, he can click on a
smiley. But if he does not write a feedback, nobody is notified. This means
some rating as somehow lost and people are not notified of it.
Specifications
==============
Now, when the user clicks on the smiley, a message is posted but notifications
are not yet sent. This uses the new ``mail.message.schedule`` mechanism added
in this PR. It gives the user some time to write their feedback and send it.
If they write and submit a feedback, the notification process is launched.
Emails and inbox notifications are created and sent.
If they don't write a feedback notification process is launch after 2 hours.
Testing
=======
Some cleaning is done in tests, notably to split some fields tests from
performance test. A bit performance test is also split into sub tests in
order to better understand queries.
Task-2207626 (Rating: Log ratings, post feedbacks)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to allow to update the scheduled date when using
``_message_update_content`` tool method. This allows notably to delay the
sending of notifications in some cases, then send it once all content is
updated according to business requirements.
When giving a scheduled date in kwargs
* either it is set, and we update message schedulers accordingly;
* either we force a void value, which means notification should be done
now and we trigger the schedulers for immediate sending;
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Stéphane Debauche <std@odoo.com>
Purpose
=======
Currently, only email sending can be scheduled with the `scheduled_date` field
defined on on <mail.mail>. It's not possible to delay the sending of
notifications.
We want to be able to delay the sending of the emails, but also the inbox
and bus bus notifications.
Technical
=========
For that purpose, we created a new model which stores the message we need to
notify with the scheduled date. When a scheduled_datetime is given we skip the
notification process. Instead an entry in that new model is created. A cron
regularly polls the scheduled message and launch the notification process on
messages that are ready to be sent.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose
=======
Move the code which updates the mail message from the message model to mail
thread. Most other thread methods (like `_message_update_content_after_hook`)
are defined at record model level. It makes sense to delegate the update to
documents and not to the message. Message is a low-level technical object
that should not really hold business code.
While modifying this code, an update is done in the update content. We now
also allow to update the body without removing all attachments.
Finally tests are added as this feature was added without really testing
model code.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Steps to reproduce:
1.) Create a custom email domain and incoming email server on a database, set the
Actions to Perform on Incoming Mails to Create a new record: Helpdesk Ticket.
2.) Set an email alias for a Helpdesk team, set the assignment method to
balanced/random, assign some users to the team.
3.) Set another email address to forward emails to the alias for the Helpdesk team.
4.) Emails received directly by the email alias will create tickets and assign
properly, emails that are forwarded to the email alias will fall back on assignment
defaults.
Explanation:
When we get the "Delivered-To" field for the message dictionnary we use
decode_message_header and the message.get_all() function, this function
returns a list with two addresses but it is transformed back into a string
in decode_message_header with a space as separator. This create an issue
when we use email_split_and_format on this string as it uses
email.utils.getaddresses that expects a list of headers field or a text
where addresses are separated with a comma instead of a string with the
header fields separated by " ". Because of that getaddresses fails to get
the right addresses and the recipients field of the message dictionnary is
missing the right address. Hence when we check if the alias is in this
values it does not find it and use the default fall back.
Solution:
To solve the issue we set the separator as a comma in decode_message_header.
opw-2917543
closesodoo/odoo#98761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = calendar, im_livechat, rating, snailmail, test_discuss_full, test_mail,
website_livechat
Distinction between "replace" and "insert-and-replace" can be guessed based on
the type of the provided data.
task-2957295
closesodoo/odoo#98404
Related: odoo/enterprise#30580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when the user creates a private task
and assign another user to that task and then removes
himself and save the task, the current user should no
longer access to that task since the task becomes this
private task of the other user assigned on it.
So when the current user changes anything in that task,
it will have a `Access Error`.
However if the user tries to remove a follower on that
task he will also have a traceback because no thread is found.
The reason why no thread is found is because the user has
no longer access to the record and so he has no longer
access to the chatter.
This commit checks if a thread is found before continuing
the process. If no thread is found then the user has no
access to the chatter instead of throwing a traceback
because no thread is found.
task-2857229
closesodoo/odoo#94665
X-original-commit: 2c68e397b3c12657024e70016808183c89260168
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
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
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Bug
===
Since 9c1cdd330e we ignore all incoming
email sent by mailing lists.
They are real use case when people want to be able to receive email
from mailing list (e.g. if they subscribed to an automated service,
or if someone is in leave and has done a auto-replier for that, etc).
Add a model to whitelist some email address. The alias limit
does not apply for those emails.
Task-2862092
closesodoo/odoo#92015
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose: Before it was hard to view expense attachments from sheet record.
To do so, the user should have gone through clicking on each expense first and
checking attachments, or could have clicked on a attachments smart button on embedded
expense table, which is redirecting to another view that only displays attachments for the one expense only.
Thus, checking all the attachments from sheet was an tedious task.
After this commit, the user can see in the sheet attachment preview all the associated expenses' attachments.
To make it possible, we ovveride 'mail.thread' method that is called to
fetch the data for the chatter. In the override, we fetch extra, associated expenses' attachments.
task - 2320177
closesodoo/odoo#92724
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
In this commit, we will fix the loops that occur when you send an email
to an alias (to create a ticket e.g.). In that case Odoo can reply
"Your ticket has been created" and then the auto-replier of the user
can reply to this email and the loop occurs.
Specifications
==============
To solve this issues, we add 2 system parameters
- <mail.gateway.loop.minutes>, 120 minutes by default
- <mail.gateway.loop.threshold>, 20 by default
When an email is sent to an alias, we look on the last records created
<mail.gateway.loop.minutes> minutes ago. If we overcome the limit
<mail.gateway.loop.threshold> the email is ignored.
Alias creation detection
========================
To detect the number of records created by a specific email address we
use the `_primary_email` attribute set on the model.
Task-2294034
closesodoo/odoo#78597
Related: odoo/enterprise#21772
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
which we don't know. Threading is therefore broken. Amazon requires to remember
new Message-Id and handle it ourself, which is complicated [1].
Possible solution: copy the Message-Id to References in outgoing message as if
we were pretending that the message is part of a pre-existing thread with
itself. Since Amazon does not alter References it is kept during transport.
Replies will therefore contain both Amazon Message-Id and Odoo Message-Id as
well as original parent Message-Id in case of nested replies.
* ``In-Reply-To``: Amazon Msg-Id
* ``References``: Odoo Parent Msg-Id Odoo Msg-Id
Task-2643114 (Mail: Message-Id in references to ease thread formation)
[1] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.htmlclosesodoo/odoo#89328
X-original-commit: bc568747bdf92c6bbca400ce3ba11f6487679f3a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of odoo/odoo@de7c119e66 where the parent finding was incorrectly refactored.
Indeed due to a typo new_parent was not updated. Instead of getting higher in
the parent chain until the first message, only the first parent's parent was
considered.
Moreover ``_mail_flat_thread`` is incorrectly taken into account. Due to the
hereabove issue it was not really impacting discussion channels, as anyway
parent finding was not working.
New parent management, depending on ``_mail_flat_thread`` is now
* ``_mail_flat_thread`` True: no free message. If no parent, find the first
posted message and attach new message to it. If parent, get back to the
first ancestor and attach it. We don't keep hierarchy (one level of
threading);
* ``_mail_flat_thread`` False: free message = new thread (think of mailing
lists). If parent get up one level to try to flatten threads without
completely removing hierarchy;
Tests show that parent is correctly flattened on business documents and left
untouched for channel-like documents.
Task-2822652 (Mail: fix parent message fetch / flattening)
X-original-commit: 86f21c1f384e37a4555b4b1ce4831904c8d40b6f
Part-of: odoo/odoo#89328
PURPOSE
Cleanup code and flow of customer rating: routes, rating_apply, rating and
message creation and update.
SPECIFICATIONS
Cleanup code about rating controllers and rating_apply. Notably correctly
link a message to a rating once a feedback is posted, whatever the flow.
Update ``rating_apply`` to use either a token, either an existing rating to
udpate it and post a message. Always link the message and the rating to
be sure DB data are coherent.
This requires an update in several demo data to correctly set tokens on
ratings and use it in calls to ``rating_apply`` done in xml files.
Extract default subtype computation of rating_apply in a sub-method to allow
setting this parameter without having to deal with ``rating_apply`` details.
CODE CLEANUP
Split behavior that is generic but actually used only in project about stage
update based on rating. Move it directly in project. As it is used only once
and as generic approach is hardcoded based on fields names better keep it
localized.
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
Current behavior :
When you delete a record (for example project.task), all the messages related
to this record aren't deleted.
This, in case a user has his notifications managed in Odoo, may prevent him
from accessing the History tab in the Discuss app because these messages are
linked to a record that doesn't exist anymore and it will raise a Missing Record
error
Steps :
*with demo data*
- Install Project
- Make Marc Demo notifications managed in Odoo
- Delete a task project to which Marc Demo is assigned
(*with Marc Demo*)
- Go to Discuss and try to access History tab
OPW-2764855
closesodoo/odoo#87732
X-original-commit: ee8feeb73c920827090b1a5ecf78e8b1d21bbae4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Skip the confirmation step when wanting to get rid of a notification
for emails, sms or letters that were not sent.
Technical:
- All 3 wizards to confirm the discarding of the notification have been removed
(the ones for mail, sms and letter) have been removed
- The method to discard notification has been centralized in MailThread
(notify_cancel_by_type in addons/mail/models/mail_thread.py)
- This centralization has been done as well on the client code as the same
server code is called whether it is a mail, a sms or a letter
(in addons/mail/static/src/models/notification_group/notification_group.js)
- Existing front and back test have been adapted
- A test of notify_cancel_by_type for mail has been added
(addons/test_mail/tests/test_mail_management.py)
- add missing author_id in mail_notification demo data
Task-2752190
closesodoo/odoo#84452
Related: odoo/upgrade#3246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps :
- Make sure the Admin is notified by mail;
- Set an Alias Domain for the company.
- Create a Project with an Alias e-mail address.
- Send an e-mail to this alias.
Issues :
In the admin mailbox, see the signature is: `<p>-- <br/>False</p>`, which means two issues.
- It is not unescaped from Html.
- The content of the signature is 'False'.
Cause :
When no user is related to the sender of the mail, we manually set a signature.
- It was written between html tags, so it should be sanitized.
- Its content was author.name, yet author is a partner, so if there is
no partner, name is False.
Fix :
- Sanitize the html code of the signature.
- If there is no partner for this sender, use email_from, or else ''.
opw-2728483
closesodoo/odoo#84329
X-original-commit: a1ac9c8171742c5622e5f310cec2fe4ab53c2717
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
We are currently lacking an index with (author, failure) due to the information
being spread out in two different tables which are both rather big (there are a
lot of non-failure messages for the current user, as well as a lot of failure
messages for other users), so the fetch of failures for the current user can
become extremely slow (> 20s).
With this new index, the query takes less than 1ms.
task-2742946
closesodoo/odoo#83451
Related: odoo/upgrade#3204
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Expected Behaviour
When a user get a mail from the data cleaning about records to examine, the View button should be linked to the same url as the 'here' hyperlink or not be in the e-mail.
Observed behaviour
Clicking the link in the View button lead to an error page
Reproducibility
This bug can be reproduced following these steps:
1. Duplicate a contact
2. Wait for the scheduled task to launch
3. Click on the View button of the mail you'll get about te duplicate
Problem Root Cause
This issue is coming from the way we create the 'View' and 'View Task' button, and can't be changed easily. The easier way to fix this issue is then to hide these button
Related Issues/PR
opw-2674138
closesodoo/odoo#83284
X-original-commit: 3a61747b366a315488837e2e560b305e89217dbd
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to add potential groups but de-activate them by
default. Indeed each group require about 20 queries for rendering and
sending. If no specific behavior (access button, content) is made for this
recipient group it can be included in lower-version of the group.
Specifications
* de-activate portal group in mail as it has no additional rights compared
to customers;
* add follower group but de-activate it for the same reason;
* activate portal group in portal_mixin and include links to the record in
notification emails, using standard mail/view link. ACLs are managed in
each specific model, generally based on followers;
Update a test in test_mail as it was playing with public and portal users
that are now not really differentiated when sending notification emails.
Better have more real-life scenarios with portal and internal users.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
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
A method that actually runs on recordsets should not have a model decorator.
Even if there is no issue this is may be confusing.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to support portal parameters in ``_notify_get_action_link``. This
method generates a ``mail/view`` link that may redirect to frontend e.g. with
portal. We already support parameters coming from auth_signup and tokens from
portal. Supporting pid / hash allowing to post on documents using the frontend
chatter is the next step to generic links. This is just adding them to the
accepted like, not changing any current behavior.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to cleanup flow of values going through message_post
and its sub methods until email generation for notifications.
SPECIFICATIONS
Ensure some values are given directly when creating message linked to post
methods to avoid browsing message when value is not known. Notably make
signature propagation (add_sign) more explicit in message_post and its sub
methods (notify, log, ...).
Prepare future language related improvements by allowing to force company and
lang values for rendering context. Also add ``is_html_empty`` tool method to
use it in notification templates. It will be used notably to check for empty
html blocks, e.g. user signature.
Rename some internal variables to better understand their purpose.
Finally update some outdated and/or badly indented docstrings.
Task-2726501 (Mail: Propagate message values in post methods)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to clean notification email values generation
while keeping possibility to override and tweak values. It now has clean
hooks on base mail value and final mail values.
SPECIFICATIONS
Base mail value are values independent from recipients. It allows notably
to tweak values depending on current record without having to browse and
access record for every recipient, saving unnecessary computation.
Final mail values are recipients-dependent and are the values that will be
use to create the final ``mail.mail``. With a mechanism of optional additional
values + hooks for base and final values it should be possible to keep any
custom behavior already implemented with a cleaner interface and code flow.
See notably odoo/odoo@b1a5bf95f8 for example of why some code exist just
for hook purpose.
As a side note, light variable renaming is performed (email -> new_email)
to avoid shadowing email.
Task-2710804 (Mail: Clean Mail.Thread API)
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
When trying to identify the user sending an email, do not match anyone
without email.
Sometimes we get an email without a valid From address (spammers or
bugs), the previous code was trying to find users with this email.
In historical databases, we often have many users without an email
address, they should not match the search.
This commit fixes two bugs:
_mail_find_user_for_gateway:
No longer match on the first res.users with no email when identifying
the user using the gateway. This was not problematic (as we have a
fallback on self._uid anyway) but it is more accurate for tracebality
of emails.
_find_members
This method is called from _alias_get_error_message to verify that the
sender is indeed in the group with the followers restriction. On large
mailing list, it is not uncommon to have members with empty emails
(migration, historical reasons,...). Sending an email without any From
was matching on these subscribers without email and the email was
accepted.
These emails are invalid and should not be accepted.
closesodoo/odoo#83122
X-original-commit: 8ec7b92467da2856a496210af1f2232eba6bafb4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
Records inheriting from portal mixin implement their own access to portal
using tokens. Activating the access button by default seems the right thing
to do instead of having to do it manually in each addon. Access is granted
at record level using tokens and access URLs anyway.
This eases future improvements of "Pay Now" notification template as it
will use the ``has_access_button`` instead of doing custom computation
directly in the template itself.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82627
Before this PR, user could edit notifications message.
task-2713602
closesodoo/odoo#81803
X-original-commit: 45e9f367d583ec8fafdf19c9e5451bdff0e16e62
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The `_insert_followers` wasn't batch in the `create` of `mail.thread`
for no reason, which call the create of a `mail.follower` one by one.
It is inefficient for the batch records creation (import or some
flows) of a model with `_inherit = [mail.thread, ...]`.
Then batch it, to miminize the cost of `_insert_followers`:
The creation of 100 `mail.follower` takes:
- 0.107 sec if you create one by one (before)
- 0.022 sec if you create in batch (now)
Also add two tests (on model with a chatter):
- One testing the behavior of follower and subtype in case of
multi-create
- One testing the number of queries done to create 5 records.
The old SQL request count was 23, now it is 19 (-1 by create
call).
task-2711448
closesodoo/odoo#80954
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Before this commit, when a partner was created through the
suggested recipient tool the langage wasn't considered...
The email was thus sent in the wrong langage most of the time
After this commit, the suggested recipient tool had the
langage correctly if present in the record.
LINKS
Task-2580065
PR : odoo/odoo#76812
PURPOSE
Concatenate feedback message and tracking when marking a lead as lost. This
currently generates 2 consecutive message about the same change, having a
single one is better from an UI point of view.
SPECIFICATIONS
Allow to link a body to a value change tracking. Tracking is currently done
by accumulating changes in a structure (see ``env.cr.precommit.data`` usage
with ``mail.tracking.<name>`` key). In the end those values are used to
generate a message with tracking value and a subtype.
In this commit we allow to manually set a body used as a message for the
tracking message, adding a new ``mail.tracking.message.<name>`` key. It is
used when posting or logging the tracking message, simply propagated as body
to ``message_post`` or ``message_log``.
In crm we use this when losting a lead through the dedicated wizard. A bit
of custom html allows to have a nice display.
Task-2671709
Part-of: odoo/odoo#78648
Thibault Delavallée