* = 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>
Since odoo/odoo@f4524f03c3 plus addressing is not used anymore
for handling bounces. Indeed it relies on references / in reply to to find
original message that bounced. It is therefore not necessary to enforce the
use of plus addressing.
As some provider do not support plus addressing as a way to contact left-part
of email with sub-informations people should have a way to deactivate plus
addressing used in bounce aliases.
To preserve backwards compatibility for stable versions old behavior is
retained unless a new `mail.bounce.alias.static` ICP is set with a truthy
value.
Fix https://github.com/odoo/odoo/issues/71242 by dropping requirement of plus addressing.
@Tecnativa TT29827
Closes#71242
Task ID-2547347
PR odoo/odoo#72347
X-original-commit: df2d955bf41b01556e1b84bb1204aac045c95a63
This commit allows to log a note and bypass notification process using a
template. The method _message_log_with_view has been added. This method
render the template using the given view and values (in kwargs) to make the
body before calling _message_log().
This process is done by the intermediary method _message_compose_with_view that
is now common to message_post_with_view and _message_log_with_view has it
follows the same template preparation process.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
using inselect operator to inline sql in the search method and avoid ORM
to fetch multiple useless messages to check if there's one
closesodoo/odoo#70410
X-original-commit: 505c7b0946689d3ac1ac4dd2f59cf4d535c36cbb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Mail holds a "Pay Now" notification template holding notably customized
links to portal for records like sale orders or invoices. It allow to
give a more personalized button than a plain simple "View document" link.
Currently frontend / backend links are not always correctly computed in this
template. This commit fixes that behavior.
Task ID-2513724
COM PR #69607
ENT PR odoo/enterprise#17849closesodoo/odoo#69714closesodoo/odoo#69744closesodoo/odoo#69774
X-original-commit: c417ea6243cb968d17f5db0919ec8cd034f4cb5f
Related: odoo/enterprise#17889
Related: odoo/enterprise#17902
Related: odoo/enterprise#17916
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>
Current behavior before PR:
mail notification not sent when using the full composer.
Desired behavior after PR is merged:
mail notification will send when using the full composer.
LINKS:
PR https://github.com/odoo/odoo/pull/66421
Task-2446855
closesodoo/odoo#67933
X-original-commit: 349f07670ea4938e7fc3d9fa3a6fc5fae40dac65
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When Odoo routes incoming emails it is looking for existing messages in
database using Message Ids which are coming from e-mail header
References.
In Odoo the message id looks pretty long like
743570479975566.1584086032.522504091262817-openerp-message-notify@ip-172-31-45-160
As it declared in [RFC2822] long header bodies can be "folded" using
CRLF+WSP. And some mail clients do that very thing. They split
References header body which contains Message Ids by "\n ". The example
of mail client where it can be reproduced is apps.rackspace.com We
created Sales Order in Odoo, sent this quotation to the client email. He
replied with e-mail, and this email can't be matched with any existing
message id and as result it's not attached to the Sales Order.
RFC2882: https://tools.ietf.org/html/rfc2822#section-2.2.3closesodoo/odoo#68077
X-original-commit: 559f6cf62711ad45557eddec3af7c66616724eb5
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Now that recipients in notification process are always partners due to
simplification of MailFollower model we can safely simplify the structure
used to collect and propagate recipients information.
Before this task it was a dictionary with a list of partner related data and
a list of channel related data. It is now simply a list of partner related
data, leading to various code cleaning.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
Purpose of this commit is to make low-level API of subscribe process a bit
easier to understand and use. Notably some parameters are now defined as
named parameters in order to better understand calls.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we force messages to belong to a single document using
``model`` / ``res_id`` pair. It is not possible anymore to link a message
to channels using ``channel_ids``. A message belongs to a document and
is displayed in that document's chatter.
This change implies modifying a lot of domains, notably in chatter. Indeed
discuss for channels does not use ``('channel_ids', 'in', [3])`` domains.
They now use ``('model', '=', 'mail.channel'), ('res_id', 'in', [3])`` like
other documents fetching their messages.
This commit also removes ``channel_message_ids`` field on ``mail.channel``
model. As channels are now considered as standard documents they will use
``message_ids`` field like all other documents. Linking a channel on a message
is possible only as a link in message from now on. It is not possible to push
it into a channel anymore (no more listener channels, no more channel link).
Finally a global cleaning also linked to all previous commits is done.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
In this commit we remove support of ``channel_ids`` parameter when posting
a message. This means we do not support notifying channels as side-part
of notification mechanism on a document. Either we post on a channel and
its members are notified, either we post on a business documents and its
followers are notified. There is no possibility to add channels as being
notified when posting a message.
This is done as a followup of removing followers being channel-based and
prepares ground to make channel use model / res_id as all other documents
inheriting form mail.thread.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
As there is no way to add channel-based follower anymore we can remove all
fields and code supporting this feature. Notably we can remove ``channel_id``
field on ``mail.follower`` model as well all code using it, notably compute
methods.
In this commit we also make ``partner_id`` field required as now followers
are always partners. Email, name and active fields are now simple related
fields on the partner.
Code computing data about subscription is also updated and simplified. As
we do not have channels anymore but only partners all custom SQL queries
are now simplified.
JS models for Discuss are also cleaned. Following python change, JS models
are simplified to match the backend models. Channel_id is removed, partner_id
is now required, and various code is updated according to the simplified
model.
Side note: we could probably get rid of specific index on ``partner_id``
field. However we have to ensure we never search for followers without being
in a model / res_id context. This will be done in another cleaning step to
be sure performance are not broken.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``message_channel_ids`` field from ``mail.thread``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to access them. We can now safely remove this field as it
has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` argument and support from ``message_subscribe`` and
``message_unsubscribe`` API. Indeed we do not support adding channel-based
followers anymore. Only partners should be added or removed from followers.
It also allows to simplify API and understanding of both methods.
Various addons are updated to match the simplified (un)subscribe API. Some
enterprise addons may also be impacted.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
As I was passing by I found some docstrings or helpers could be updated or
rephrased a bit more clearly. This is free as in free beers, without beers.
Some code about mail features (posting) may also be re-indented to ease
understanding of future modifications. Or just because we had to read
it and go through many files. Still free beers.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
In case of bad translation that doesn't contain the placeholder
Context:
A bad Japanese translation was inserted
#. module: mail
#: code:addons/mail/models/mail_thread.py:0
#, python-format
msgid "Create new %(document)s"
msgstr "新しい%(ドキュメント)を作成する"
The translation has been corrected but use the 14.0 syntax of _ method
to include placeholders and fallback on the English source term in
case of bad translation
cf odoo/odoo#52155closesodoo/odoo#65586
X-original-commit: 48cc6b1f2b3208e8affd5f6a261751fe973c2091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit contains a followup / rewrite / backport of #34150 :
* odoo/odoo@16dd3da
* odoo/odoo@0b11ed8
Fix: propagate generic internal subtypes from parent to childs with auto
subscribe.
With this commit, when the user subscribes to internal subtypes like
activities on a parent record (e.g. a project) then the user follows them
by default on every sub record creation (e.g. all new tasks of this project).
Fix: do not reset existing subtypes when changing parent of a record using
auto subscribe mechanism.
With this commit, when changing subtype subscription from a parent record
(e.g. project) avoid resetting all subtypes subscription on existing sub
records (e.g. all new tasks of this project). Only new records will use the
parent chosen subtypes. This is done through propagation of followers
existing policy (see Follower._insert_followers() for more details);
Note that fix done here is slightly different from the one done in odoo/odoo@16dd3da
as there was some mismatch with internal model-related subtypes. Thix fix
will be forward ported and improve the previous one.
Task ID-2205643
COM PR #47336
X-original-commit: 01254f06e8ea37887e190758cc479a098591ab8e
X-original-pr: odoo/odoo#47336
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Alexandre Khun <aku@odoo.com>
Co-authored-by: Priyanka kakadiya <pka@odoo.com>
If an email was sent with empty "To:" and a proper alias in "CC:" (or any of the similar valid headers that conform the `rpc_tos_localparts` array), before 40ae36b7f8c412cd96dc9592d8d1fb90de1e52d2 the email wouldn't get rejected. After that commit it would get bounced.
This comes from the not-so-obvious new python idiom used, `all()`. Check this out:
```python
>>> all([False])
False
>>> all([])
True
```
So, apart from the fix introduced in that commit, which seems valid, we have to make sure `email_to_localparts` actually has contents. Otherwise we are producing false bounces here.
@Tecnativa TT23437
closesodoo/odoo#64528
X-original-commit: 8f094d3c01a6ad150b7945115cda515dbde1f4bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to rewrite channel tests, notably moderation
tests. In this commit we
* use standard users instead of admin/root: this allows to test ACLs and
more real life oriented use cases;
* remove unnecessary tests or merge tests belonging to the same category;
* add some coverage for corner cases;
* make tests more readable;
We also improve some notification code and error messages that are not
really helpful for users.
Followup of odoo/odoo@e9571a403e
Task ID-2421795
closesodoo/odoo#64459
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Configure the incomming mail server, use another mail client to send a
message to Odoo with an EML file as attachment. The fetchmail server
fails.
Since the introduction of the new EmailMessage python API to
encode/decode email messages, every EML attachment is automatically
parsed into a EmailMessage.
closesodoo/odoo#63255
Task: 2329606
X-original-commit: e628defec14f3b36612951bc698fa51b7c9f56bb
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Thread search with `message_has_error` should only return threads containing
messages with failure of which the current user is author.
Follow up on https://github.com/odoo/odoo/pull/52403 that changed how
sub-queries were built. The current fix using `_search` is a non-ideal solution
until task-2366651 brings a new domain operator for this use case.
task-2409543
closesodoo/odoo#63231
X-original-commit: 337397eec5570fc9b3938d655a1ec0e4efcd73d9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
WHY:
Some mail servers may provide `Message-Id` header in a section typed
`text/rfc822-headers` instead of a `message/rfc822`
According to https://tools.ietf.org/html/rfc6522#section-4 that section's body
actually contains the headers from the bounced email.
STEPS: a way to reproduce it should be using postfix v2.5+ with setting
bounce_size_limit=1. See
https://github.com/odoo/odoo/pull/42340#issuecomment-617605521
BEFORE: `bounced_message_id` is empty and thus the little email envelope icon
doesn't turn red, nor do the email resend features trigger in the UI. You could
be sending an invoice and never knowing it was bounced.
AFTER: bounces from mail servers that return the `text/rfc822-headers` part will
be handled properly.
---
@Tecnativa TT21170
opw-2162067
opw-2344252
closes#42340closes#62551closesodoo/odoo#62732
X-original-commit: 375ba5b37053a599922dd61c9e787553d6171291
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
This commit cleans the default_* keys of the context before creating mail.mails
and mail.notifications when notifying the record by email.
Without this change, there can be a collision when the ORM tries to compute
default values for the state field (for example):
- Model "A" has a 'state' field ;
- Create an action that redirects to model "A" form view, setting some default
values in the context such as {'default_state': 'done'} ;
- Model "A" has an inherit on 'mail.thread' and a 'user_id' field to set a
responsible user ;
- Model "A" record is created with a responsible user, who is automatically
notified by email that the record "has been assigned to him" ;
(see mail_thread#_message_auto_subscribe_notify)
- A 'mail.mail' is in turn created ;
- The 'mail.mail' model ALSO has a 'state' field, and the context is propagated
so the ORM will try to assign 'done' to that field, which is an incorrect
value ;
- -> Crash.
If we ensure that the default_* keys are cleaned from the context, the default
values computation of the mail.mail record will not be affected and everything
works fine.
A test was added to ensure this behavior.
Task 2393259
closesodoo/odoo#62589
X-original-commit: 6b6e546ac95d9acb2964121dd52aa2896d31bc33
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Didier (did)