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
Purpose is to have tracking methods beginning with ``_track``, indicating
those are tool methods used for tracking. It helps organizing the mail thread
file and having short but precise method names.
We also remove the usage of ``mail_track_log_only`` context key that is not
used anymore in the code. It allows to shorten a bit the code and make it
easier to read.
Task-2671709
Part-of: odoo/odoo#78648
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
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The `distinct` keyword in query
```SELECT distinct res_id FROM mail_message WHERE model=%s```
is not strictly necessary for the correctness of the result, as
it will be inserted inside a sub-query that will be able to use
the main (model, res_id) index of mail_message.
For example, when the `has_message` field is used in a domain
by the website_livechat module[1], the complete query looks
like this:
```
SELECT "mail_channel".id FROM "mail_channel"
WHERE ("mail_channel"."active" = true) AND
("mail_channel"."livechat_visitor_id" = 112678387) AND
("mail_channel"."livechat_channel_id" = 1) AND
("mail_channel"."livechat_active" = true) AND
("mail_channel"."id" in (
SELECT distinct res_id FROM mail_message WHERE model='mail.channel'))
ORDER BY "mail_channel"."create_date" DESC LIMIT 1;
```
In this query, it's obvious that the `distinct` makes zero difference in
the results.
However, the presence of the DISTINCT keyword means that PostgreSQL will
factor the cost of applying that UNIQUE sort in the query planning, and
use MERGE JOIN strategy to avoid sorting multiple times (ok, it could
perhaps guess that distinct is useless here, but we asked for it.)
For a database with millions of mail messages, there can easily be
millions of hits for the generic "all res_ids for model" query, so
the cost of that part will be quite high.
The plan will then look like this (notice the "Unique" step and the cost,
730ms for the index scan + 200ms for the sort):
<details>
<summary>The query plan when `distinct` is used</summary>
```
QUERY PLAN
------------------------------------------------------------------------------
Limit (cost=151528.28..151528.29 rows=1 width=12) (actual time=1021.237..1021.239 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=767230
-> Sort (cost=151528.28..151528.29 rows=1 width=12) (actual time=998.799..998.801 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.create_date DESC
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=767230
-> Merge Join (cost=3.01..151528.27 rows=1 width=12) (actual time=998.786..998.790 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Inner Unique: true
Merge Cond: (mail_channel.id = mail_message.res_id)
Buffers: shared hit=767230
-> Sort (cost=2.44..2.45 rows=1 width=12) (actual time=0.043..0.045 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.id
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=5
-> Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel (cost=0.41..2.43 rows=1 width=12) (actual time=0.035..0.039 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Index Cond: ((mail_channel.livechat_visitor_id = 112678387) AND (mail_channel.livechat_channel_id = 1))
Filter: mail_channel.active
Buffers: shared hit=5
-> Unique (cost=0.57..143838.35 rows=614997 width=4) (actual time=0.033..993.210 rows=97187 loops=1)
Output: mail_message.res_id
Buffers: shared hit=767225
-> Index Only Scan using mail_message_model_res_id_idx on public.mail_message (cost=0.57..129884.36 rows=5581595 width=4) (actual time=0.032..730.233 rows=5586467 loops=1)
Output: mail_message.res_id
Index Cond: (mail_message.model = 'mail.channel'::text)
Heap Fetches: 17
Buffers: shared hit=767225
Planning Time: 0.471 ms
Execution Time: 1025.410 ms
(37 rows)
```
</details>
Now, if we remove the superfluous `distinct` clause, for the same
database, data volume, and result, the plan looks like this:
<details>
<summary>The query plan when `distinct` is not used</summary>
```
QUERY PLAN
-------------------------------------------------------------------------------------
Limit (cost=3.44..3.44 rows=1 width=12) (actual time=0.069..0.069 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=8
-> Sort (cost=3.44..3.44 rows=1 width=12) (actual time=0.068..0.068 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.create_date DESC
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=8
-> Nested Loop Semi Join (cost=0.98..3.43 rows=1 width=12) (actual time=0.061..0.061 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=8
-> Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel (cost=0.41..2.43 rows=1 width=12) (actual time=0.020..0.020 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Index Cond: ((mail_channel.livechat_visitor_id = 117513256) AND (mail_channel.livechat_channel_id = 1))
Filter: mail_channel.active
Buffers: shared hit=4
-> Index Only Scan using mail_message_model_res_id_idx on public.mail_message (cost=0.57..2.77 rows=10 width=4) (actual time=0.040..0.040 rows=0 loops=1)
Output: mail_message.model, mail_message.res_id
Index Cond: ((mail_message.model = 'mail.channel'::text) AND (mail_message.res_id = mail_channel.id))
Heap Fetches: 0
Buffers: shared hit=4
Planning time: 0.761 ms
Execution time: 0.095 ms
(23 rows)
```
</details>
Total execution time goes from 1000 ms to 0.1ms.
Reference: introduced by 9a01a2953f,
coming from #69812, which was fixing a performance problem.
[1] https://github.com/odoo/odoo/blob/9b224f35f45876c86dc34934379bfa9e8b3e2160/addons/website_livechat/models/website.py#L40-L44closesodoo/odoo#78186
X-original-commit: 3ab87a848c96b284eac3dbbd6f6f2a9ea971876a
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit adds a feature where users can reply to messages of other
users, doing this will show a reduced version of the message that has
been replied to above the message once posted, clicking on this reduced
version will scroll to the original message and highlight it if that
message is already loaded.
task-2362251
closesodoo/odoo#77941
X-original-commit: cec2e69e832072dd699274187ddfa122e29d03f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Just putting code where it belongs, in sections about access rights / discord
API. After a lot of updated some cleaning is always welcomes. This prepares
future code renaming and improvements.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
Step to follow:
- Create an Asset Models
- Set up the Fixed Asset Account:
Automate Asset -> Create in draft or Create and validate
Asset Model -> The one you have just created
- Create a Vendor bill
Account -> the Fixed Asset Account of the asset model created
Label -> insert a newline
Price -> (do not forget to set a price)
- Validate
- Go to the asset automatically created
- @ mention a user in the chatter
Cause of the issue:
The generated email subject comes from the record_name and it can
contain newlines
Email headers don't allow newlines and an exception is thrown here
https://github.com/python/cpython/blob/60b93d9e4922eeae25052bc15909d1f4152babde/Lib/email/policy.py#L143
Solution
Replace newlines by spaces in the email subject
opw-2522055
closesodoo/odoo#77712
X-original-commit: ed343998d39ff91a3f73cc8012be498d32c91b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When body does not contain any tag or content parsing currently fails
with an ``lxml.etree.ParserError``. To avoid that we can improve condition
about void body: stripping void characters allows to avoid that traceback.
Task-2641572
PR odoo#76159
Closes odoo#75625
X-original-commit: 708fe3e74991c144a05c6bdcafa1931672e36ce9
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Some emails are wrongly formatted mainly due to old servers. If Final-Recipient
header is void or wrongly encoded it currently crashes. This fix ensure there
is no crash, even if bounce detection could be incomplete.
Task-2641572
PR odoo/odoo#76159Closesodoo/odoo#75618
X-original-commit: f437967a1fa4fca56c88e1cf79586805101ab712
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies A, B
- Let's consider two contact with the same email E, C1 in A and C2 in B
- Let's create an alias AL for the vendor bill journal of B
- Send a vendor bill VB from E to AL
Bug:
A new bill is created in B with C1 as partner instead of C2
So an access error was raised when trying to open the bill in company B
opw:2495870
closesodoo/odoo#76963
X-original-commit: 1a58be583629af80af00f288dc5925c3940be1ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
While only notes can be deleted on threads, some tracking messages are
created with the type "notification", some messages are created as
notes. This commit prevents deletion and editing of messages that have
tracking values, as they are invaluable for traceability and not
user-created.
closesodoo/odoo#76593
X-original-commit: b51de3464e3c30ef23f0ee4e8d6128f9ca6ce8b1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Add a new stand-alone page "WelcomeView"
- Redirect people who join using an invitation link to the WelcomeView
- Add microphone/camera preview
- Allow guests to choose a name from the WelcomeView
- Add "Start a meeting" button to the discuss sidebar
- Create a new channel on click on the "Start a meeting" button
- Display ChannelInvitationForm on click on the "Start a meeting"
button
- Add a new field to `mail.channel` in order to define the display
mode to use for videos (e.g full screen) when joining a meeting
Task 2494829
closesodoo/odoo#75899
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
This commit allows users to "delete" their messages in discuss, as well
as their notes on other records. Admins can delete anyone discuss
messages or notes. Tracking messages such as a change in stage or other
cannot be deleted.
This "delete" is a "soft-delete" in that it only empties the message's
content, so that it is no longer displayed in the UI, but remains in the
database so that people who got notified by email can still reply to the
message, among other things.
task-2365646
closesodoo/odoo#74857
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Bug
===
The arguments model and res_id were declared on the method but never
used. This method was supposed to be callable from the model and not
from the records with those 2 parameters.
Make this possible.
Task-2599676
closesodoo/odoo#75779
X-original-commit: 07dbd96b3736efe84b670a7b4d45dd6cd07b14f9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Be aligned with mail_mail model naming as well as convention used in SMS
application (sms_sms_id, sms_sms_int) and mass mailing application (using
mail_mail_id on mailing.trace model).
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
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
Starting from this commit bounce addresses set in emails will not use any
plus addressing. They will always be ``bounce_alias#@alias_domain`` and
not ``bounce_alias+<mail_id>-<mail_model>-<mail_res_id>@alias_domain``.
Reasons are
* this plus addressing adds information we do not use anymore since a long
time as bounced messages are found using their message ID and not any
information coming from this bounce address;
* this generates unnecessary noise;
* not all email providers really support plus addressing as a mean to
generate "fake" additional email addresses;
This is the followup of odoo/odoo#71244 where a solution to avoid plus
addressing was done in table. We can now safely remove this feature in
master as a cleaning step.
Task ID-2577328
closesodoo/odoo#73363
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rationale
=========
Currently, mail channels have 2 modes
- They can be used like Discuss channel (chat, livechat, group)
- They can be used like a Mailing List (with the "email_send" field)
The mix of both feature in the same model causes some code complexity.
Several fields are not used in both cases (moderation related field)
and the future "Discord like" Discuss will even push the mail channel
further than the usage of the mailing list.
Because of all those reasons, we want to split the 2 mains features of
the mail channels into 2 different modules and models.
Purpose
=======
This commit remove the moderation feature of the mail channel
(email_send=True). This will be re-implemented in a separate module
in the next commit.
Do not be able to check messages in Discuss anymore because this
feature is only used to moderate the message and this feature will be
spitted in a new module "mail_group".
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
Steps to reproduce:
- Install 'Accounting' module
- Switch to "My Company (Chicago)"
- Create an invoice
- Set Invoice date to 1/1/21 and
- Set Due date to 1/3/21
- Add any product and 'Confirm' invoice
- Go to customer profile
- Click on 'Due' stat button
- Click on 'Send by mail'
Issue
In received email, logo displayed is of "My Company (San Francisco)".
Cause
Env company not used.
Instead, logo of customer.company_id is used if mail type have
company_id field,
else will fallback on user.company_id
Also, if customer.company_id is null, it will fallback on '0':
/logo.png?company=%s' % (company.id or 0)
Solution
If mail record have NOT a company_id field or is not set,
set company to self.env.company.
Else, set company to record.company_id.
opw-2474114
closesodoo/odoo#73099
X-original-commit: 316b5956844d6f77f6fef1efeb5a8a8505e36e8e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When sending a notification, the company used is:
- company_id of current record or if not available,
- company_id of author or if no author,
- company_id of user
This can seem unexpected if the author is the current user and the
company_id of our user is different than the current company switcher
company.
With this changeset: the company used is:
- company_id of current record or if not available,
- company_id of author if author is different than user or,
- current company in company switcher or if not,
- company_id of user
opw-2472622
closesodoo/odoo#73031
X-original-commit: 3f61d9e2dadf47d211ed078b36e9f3a416bbbff0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When a bounce has to be managed on a record already inheriting from blacklist
mixin it shoudl not be counted two times: one for email-based bounce and one
for "all records using that email linked to blacklist mechanism should
bounce".
A mechanism exists to prevent that double increase but it was not correctly
done. Protection was reset in a loop.
Task ID-2547347
PR odoo/odoo#72347closesodoo/odoo#72420
X-original-commit: 6e1bca5df19392d384d7c398b7aea66b62381938
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Gorash