This commit renames the isMuted variable into isSelfMuted to reflect the
user action of self muting, as opposed to the state of being mute,
which will be distinct in an upcoming commit.
part of task-2720026
closesodoo/odoo#82199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this PR, the guest that just connect wouldn't receive the longpolling
message before the current one expire.
task-2664831
closesodoo/odoo#82170
X-original-commit: 0006123dba46d32d062a581e9a16f433f3ce05f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
- Settings -> Mail channel -> any chat-type channel
- Go to Members
- Add an user
- Refresh the page
Current Behaviour:
- Traceback
- Chat are designed for 2 users and you should not be able to add more
Behaviour after PR:
- Can only edit members of channel if it's not a chat
- User error if try to add more user
- Fix traceback if there is too much users
opw-2717341
closesodoo/odoo#82044
X-original-commit: 85f7b7c1304222966610833dc325bc47f1c13158
Related: odoo/enterprise#23156
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
This adds a test sending a mail with comments (MSO conditionals) in
mass_mail mode.
X-original-commit: 8778c10bc1856e57216785a8332b90878ff1b5ef
Part-of: odoo/odoo#80621
`_replace_local_links` ensures urls are given as absolute rather
relative paths, for link `href`, img `src` and within styles. This
failed when the style contained escaped single quotes (eg:
`background-image: url("/my_url/path");`). This commit adapts the
failing regex appropriately.
X-original-commit: 2af980e8cdc72d35729ef2fbaf5067fe7e72bbb8
Part-of: odoo/odoo#80621
This adds a test for the _replace_local_links function of mail render
mixin, in the case of urls in style attributes.
X-original-commit: 199b45c7f6b0155d3828487b2f7771e1500820b1
Part-of: odoo/odoo#80621
Since https://github.com/odoo/odoo/pull/73689 all internal users are no longer
known at init. Unlike what was stated in the corresponding PR, the code of
mentions wasn't actually good enough to allow it without any drawback.
This PR fixes the issue by prioritizing internal users on the result of the RPC.
As a bonus the internal user state is immediately returned when fetching
followers, which allows mentions to be accurate even before the RPC is done.
task-2695224
closesodoo/odoo#80645
X-original-commit: 86de2f231be87b289deb85c3b20b93d890cce918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Allow sales reps to add a closing note to their lead while it is being marked
as lost. This is currently already done by a lot of sales reps but manually
with the "Log a Note" button.
SPECIFICATIONS
In ``Lost Reason`` model: add a new html field allowing to log a note on the
lost leads. Below the m2o, add an Extra Comment field where users can add a
"closing note". When the wizard is submitted, log this message as a note on
selected records.
Add tests, allowing to test both the wizard and this new feature.
Task-2671709
Part-of: odoo/odoo#78648
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
* = 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>
Before this commit, the server could return outdated information to the
client about the state of their own rtc session.
The server should not return information about the client's own rtc
session as the source of truth is the client-side state.
A case in which this was causing an issue was when a user toggled their
mute state right before their client pinged the server and received
outdated session information before their most recent state could be
sent to the server.
This commit fixes this issue.
closesodoo/odoo#78028
X-original-commit: fe991edd2bca98b58fc5a49494871475c79bc22f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Post a message in the channel each time a guest is added to members of
the channel.
closesodoo/odoo#77915
X-original-commit: bf6af9b629a07d04bf582987b5144a37fa31729e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose is to assert current behavior as this may change in master. Two
kind of tests are added: performance and multi company.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
closesodoo/odoo#77845
Related: odoo/enterprise#21456
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Let us use existing data for multi-company tests created when calling a specific
method available in mail tools. We may then remove TestMailMultiCompanyCommon
that is used in a single test, with an hardcoded currency_id (hem).
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
* = test_discuss_full
Before this commit if 2 persons are joining the call at the exact same time, the
join RPC of each will return the list of RTC sessions without the other person
included.
In more general terms, the server should actually rarely send the full state to
the JS (in this case "use the replace command") because there is no guarantee
that a concurrent transaction is not changing the data at the same time. In
other words, even the python is actually working with partial knowledge
relatively to the database.
Using a DB lock would guarantee it, but we don't want to lock tables and wait on
locks if there are alternatives. In this case it is acceptable to keep obsolete
sessions for a little bit longer, as long as they are cleared eventually.
closesodoo/odoo#77656
X-original-commit: d3a84172fc78f5783f75aa1155f1a25e4f9614b7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
When merging partners through the ``base.partner.merge.automatic.wizard``
wizard, messages and followers are merged. However activities are not
probably because its underlying model is "newer" then messages and followers.
This commits fixes that behavior.
Task-2641572
PR odoo#76159
Closes#71654
X-original-commit: 7e17678ec6ebbbe37b807a5d264cc5afd46bae1a
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Purpose of this commit is to highlight an issue that may happens easily with
`crm` that is made generic here within `test_mail`.
`crm` alters the context when creating a new record adding in this case
`default_type` to it][1]. The returned record contains that altered context.
his results in other records created from it trying to assign that same default
value for `type`. This is a very common name for fields, and happens to exist
in `ir.attachment` too.
If you create an alias for incoming leads in your DB with default values
`{"type": "lead"}` (something very common) and then an email comes to that
alias that contains an inlined base64 image, the attachment creation process
would simply fail.
Obtained error is ``ValueError: Wrong value for ir.attachment.type: 'lead'`` .
[1]: https://github.com/odoo/odoo/blob/272602193f5647f7f2270ed6ec68777625a139dd/addons/crm/models/crm_lead.py#L310-L311
X-original-commit: 99434b2e8528c10fcc9cb6860765e0ddcaa364c8
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
As create_uid has no value on mail.compose.message model when being in onchange
or new mode, 'Mail Compose Message Rule' record rule may crash. In this
commit we fix that issue by adding a value for create_uid. An unit test is
added to ensure it effectively fixes the use case.
Steps to reproduce this warning:
1. Create automated action for the 'mail.compose.message' model
2. Try to open 'Email compose Wizard'
Warning:
"Due to security restrictions, you are not allowed to modify 'Email composition
wizard' (mail.compose.message) records.
Records: mail.compose.message,NewId_0x7f8e99762310 (id=NewId_0x7f8e99762310)
User: USERNAME (id=2)
This restriction is due to the following rules:
Contact your administrator to request access if necessary."
Task-2641572
opw-2628005
PR odoo#76159
Closes#75369
X-original-commit: 26d64c0b84b76bb9164a8895bcc21b66754478ae
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Purpose is to add some tests for newly added feature logging portal access
granting. Some code is also cleaned to avoid unnecessary computation when
groups are not modified on user model.
closesodoo/odoo#76040
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = 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>
- Channels
* "hash tag" avatar with different backgroud colors
* only private channels have lock thread icon
- DM groups
* "users" avatar with different background colors
* no thread icon
task-2584994
closesodoo/odoo#75653
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The commit is to refactor the discuss sidebar
- threads are now organized in categories based on the thread type e.g. chat, channel
- categories can be folded or unfolded by clicking the category title
- for active thread, even if the category is folded, it remains under the category title
- for channel category, a new cog button is added to view all channels
- the active indicator bar is removed. The active item now is highlighted with a different background color
- thread avatar is used for livechat, chat and channel
- for livechat and chat, threads are now sorted by last activity time (pin or message exchange)
closesodoo/odoo#70986
Task-id: 2440073
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose is to better understand the use of email_re regex (find emails in a
text) and email_split_tuples (find name and email in a string used in email
headers or as email_from / email_to / email_cc).
Task ID-2377974
Community PR odoo/odoo#61467
Since a few time, test_mail holds tests linked to specific test models.
Generic testing of mail features are located in mail. Followup of fix done
in 12 and forward ported until odoo/odoo@b7af68590e
Also rename test_mass_mailing_server.py unit test file to test_mailing_server
to match current naming of files.
Task ID-2377974
Community PR odoo/odoo#61467
PURPOSE
=======
We want to increase the score of the emails sent by Odoo and we want to
avoid them to be marked as spam by the mail clients (gmail, outook...).
SPECIFICATIONS
===============
From filter
-----------
Add a new field on the "ir.mail_server" which is "from_filter". This
field defines the email address for which the outgoing email server can
be used.
The "from_filter" can either define an email address or a domain name.
Use the system parameter "mail.default.from" which allow us to define
a default email address which is used to encapsulate the emails
(default: notifications@<catch.all.domain>).
Mail server priorities
----------------------
When sending an email, we read the FROM header and,
- We first look for a mail server which match the entire mail FROM
in that case, we do not change the email header (not needed)
- If not found, we search a mail server which matches the domain name of
the mail from (do not need to change the headers in that case)
- If not found, find the mail server linked to the "notifications"
email (defined in the system parameter). Then change the FROM header
to the notification email, and put the old one in the name part of
this header.
E.g.
Initial mail from: "Admin" < admin@example.com >
Final mail from: "Admin (admin@odoo.com)" < notifications@odoo.com >
- If no notification email is configured or if no mail server are
found for the notification email, fallback to the old system and
spoof the FROM header. In that case we do not have the choice if we
want to send the email, he will probably be marked as spam.
Sending method priority
-----------------------
In the mail server models, we defined some priorities,
1. Forced SMTP session
2. Forced mail server
3. Try to find the best mail server (see "Mail server priorities")
4. If not found, read the odoo-bin arguments
Bounce
------
As there's no standard for bounce address, we put it in the envelope
(smtp_from). But in some case, it might be considered as spoofing. So,
we use the bounce address ONLY if the mail server is configured for the
entire domain name.
One behavior which might be broken is the following; we send an email as
"std@gmail.com" and the bounce address is on the domain "odoo.com".
Before we received the bounce notifications but we were spoofing the
local part and the domain.
Now
- if a mail server is configured for GMAIL, we do not use the bounce
address (and we might not receive the bounce notification)
- if no mail server is configured for GMAIL, but one is configured for
"odoo.com"
- the FROM header will be "notifications@odoo.com"
- the FROM envelope will be the bounce address
=> In this situation we are spoofing only the local part of the email
but it's allowed as the mail server is configured for the entire
domain name
LINKS
=====
Task-2367946
odoo/odoo#61853odoo/upgrade#1903
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Opportunity is taken to clean the various follow/join/invite methods into only
one `add_members` method.
Part of task-2360169
closesodoo/odoo#74425
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
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
Purpose of this commit is to prepare ground for future improvements by already
supporting QWeb rendering in ``mail.render.mixin``.
We temporarily support new field parameters allowing to tune the rendering
directly from field. Notaby choosing engine (jinja or qweb) can be done
from field directly. This is considered as experimental, used mainly to
prepare QWeb support.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Bug
===
Since 4da64b3f3c , if multiple users of
different companies are in the same channel, and if the type of the
channel is "email", a traceback is raised when sending a message.
Technical
=========
"with_user" drop the SU flag and is not enough to bypass the multi
company ACLs. Moreover, we do not want to send a "channel_seen" bus
notifications and we can mark the message as seen on the JS side
directly.
Changes
=======
So now, the traceback is not raised anymore in that case, and the
message is marked as seen if the receiver has the web client open.
But, if the receiver has not the web client open, when he will login,
the message will not be marked as seen. This can be improved but at the
moment we just want to revert the fix that cause the traceback and fix
the issue in most cases.
Task 2427790
closesodoo/odoo#71320
X-original-commit: 8b5de95bea0087c48d17f40847750eb31fe97caf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add tests related to answers through mail gateway
when having reply-to mode of mailing set to either updating existing threads
(aka replying on mailed records), either creating new threads (aka using the
reply-to alias configuration).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
PURPOSE
Purpose is to have more tests when sending mail mailings, notably about
canceled or failed mails or sms as well as jinja and links rendering.
SPECIFICATIONS
In this commit we improve Email Marketing mailing tests. We notably
* add tests for void and invalid email and numbers. It allows to check they
correctly update their trace status;
* add tests for unsubscribe and view links embedded in mass mailing emails;
* add tests to simulate a click on links sent through mass mailing and
ensure click statistics are effectively updated;
* add tests to simulate bounce emails coming back to the mail gateway;
Default content of mailings used in test is updated to ensure jinja is
correctly rendered, including links and some corner cases. This will also
helps ensuring behavior is kept when converting to QWeb.
Various docstrings are added to helpers and custom asserts.
LINKS
Task ID-2508643
Followup of odoo/odoo#68874 (improve mail tests)
Prepares Task ID-27033 (support QWeb in templates)
Prepares Task ID-2377974 (clean trace and status management in mass mailing)
COM PR odoo/odoo#69461
ENT PR odoo/enterprise#17780
X-original-commit: 7b940ad46bde30f9bf16837f7bff5a70cd88c640
When using assertMailMailWEmails custom assert we now check that a sent
mail.mail matches a sent email. It allows to have a complete check from
mailing traces to sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
ENT PR odoo/enterprise#17558
X-original-commit: 59da8627e0d732b12fb98faa6e66e43b8c75dc9c
PURPOSE
Add some tests for ``mail.render.mixin`` in order to assert its base behavior.
SPECIFICATIONS
Add tests for
* jinja rendering tools;
* QWeb rendering tools;
* translation support;
Also add tests for jinja markers: block, variable and line statement markers
should be tested.
Also improve docstrings of tool methods. Add notably explanation of parameters
and better explain methods purpose.
LINKS
Task ID-2500615
Prepares Task ID-2484296 (improve markers use in Jinja)
Prepares Task ID-27033 (support QWeb in templates)
COM PR odoo/odoo#68874
X-original-commit: f3dba8e020a0be72321427ed839b80ad77386946
In this commit we backport some of 14.1+ improvements done in mail tools
in order to keep a coherent definition through sub versions. We also
improve docstring and add some explanations on available toold and asserts.
Task ID-2500615
COM PR odoo/odoo#68874
X-original-commit: d44c47697389866603f28ff2d5da60a97574ec5f
This commits is a bit a followup of odoo/odoo#62061 where new composer tests
were added. This commit finalize this work by merging all composer related
tests within the same file. It also backports some of tooling update done
in odoo/odoo#64459 or odoo/odoo#63677 in order to have coherent naming
through 14+ versions.
Some additional or deeper tests are added. Notably it now more cleanly
uses asserts for created mail.mail and sent emails.
Task ID-2500615
COM PR odoo/odoo#68874
X-Original-Commit odoo/odoo@67f31cbfcd
X-original-commit: e147ca2eb51a7008251f20f134bd021a1ae3705c
Before the commit, `_action_unfollow()` can be called by
`_message_receive_bounce()` and then multiple leave notifications
can be sent even if the partner has been removed from the channel,
when the partner is a follower of the channel and without a
valid email address.
Unfollow action should also remove the partner from the followers,
and only be processed if the partner is still a member of the channel.
Task id: 2456233
closesodoo/odoo#68314
X-original-commit: 5cf22425eb68f15d94a8b283c50198561bbc240a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In this commit we improve event communication scheduling tests. We make tests
more detailed and use mail tools to ensure content. We also check scheduled
dates and use freezegun to ease date management.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 1a66d9cb57dc17b697b7a56effa91de3a4b50bd7
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.
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
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
Support mentioning partners on channels like done on other documents. When
there is an user input (comment or email) that mentions someone that specific
recipient is not notified. Its notification will be done in Inbox or email
depending on its choice or customer state.
This feature somehow replaces the follower-based support that is now removed
on channels. It allows to ping people and send them notifications. It is
less broad (limited to a post with ping) but already gives flexibility when
using channels.
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
Thanh Dodeur