Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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
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
This commits introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
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>
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>
Steps:
- Install sale
- Go to Settings / Translations / Languages
- Activate Dutch
- Go to Settings / Users & Companies / Users
- Edit demo
- Language: Dutch
- Go to Sales
- Create a quotation:
- Customer: demo
- Go to Settings / Technical / Automation / Scheduled Actions
- Create a new action:
- Model: Sales Order
- Python code:
```python
last_id = model.search([], order='id desc', limit=1)[0].id
env.ref('sale.email_template_edi_sale').send_mail(last_id, notif_layout='mail.mail_notification_paynow')
```
- Click "Run Manually"
- Go to Settings / Technical / Email / Emails
- Open the last email you just sent
Bug:
Parts of the email are not in Dutch
Explanation:
This commit makes a template pass the rendering language to the layout
and the display name when calling `template.send_mail()`.
opw:2467640
closesodoo/odoo#71446
X-original-commit: 74da8e27c7e16fa92eb1547cec1a7ce82e15e0c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
This commit simply makes the mail.template name field translatable.
It had not been done yet since the model is quite technical but it's still
displayed for the end users within the composer so it's better to have it
translated if need be.
Task-2543495
closesodoo/odoo#71408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Merge two overrides of Base into the same file. Just moving code to clean
module, nothing changes functionally or technically.
LINKS
Task ID-2431217
COM PR odoo/odoo#67322
ENT PR odoo/enterprise#16876
UPG PR odoo/upgrade#2236
In database with frontend and live chat there are lot of bad query error.
bad query: UPDATE "mail_channel_partner" SET "write_uid"=5,"write_date"=(now() at time zone 'UTC') WHERE id IN (328111)
closesodoo/odoo#71207
Error: Could not serialize access due to concurrent update
X-original-commit: 36a9e761c8d6c1c6e9611cc410ecca82ff2b1659
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- using join on required fields ease PostgreSQL planner guessing
- skip useless join, the fastest code is the not executed one
- skip dynamic `or` insertion and replace with a union all in CTE
- replacing `where exists` with a join is then possible
- a bit of alignment
from some s to some ms execution time.
Submit an "Apply for a job" on website , goes from
`"POST /website_form/hr.applicant HTTP/1.0" 200 - 182 2.649 0.106`
without this patch, to
`"POST /website_form/hr.applicant HTTP/1.0" 200 - 185 0.492 0.107`
when this patch is applied
closesodoo/odoo#71028
X-original-commit: 783280375ff04955978a14f007f96d6c4d7443b1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
On large database with million of messages made by one partner.
When you try to update the image of partner, it take lot of time (CPU time limit).
closesodoo/odoo#70786
X-original-commit: b44272a662468d164277b265d33ba6f46e631118
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a retry button to enable the user to try and resend multiple emails at once,
purpose is to allow users to easily send back multiple emails which crashed for
a "one-shot" reason instead of asking them to resubmit them one by one.
Task-2492990
closesodoo/odoo#69880
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
ALIAS_WRITEABLE_FIELDS is used to write alias fields with sudo
Steps to reproduce:
1. Create a user
1.1. Give rights Services -> Project-> Administartor
1.2. Not given rights Administration-> administartor
2. Project app -> open any project -> Action -> duplicate -> it give validation error.
---
opw-2506566
closesodoo/odoo#70414
X-original-commit: 7ae1b4622c6743e28deca12476d6e70375c9417e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
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>
Give a coherent group as otherwise we could have access errors. Simple
case: an Admin Rights user goes into a mail message form which is only
available in debug mode which sets `group.no_one` into such user. This
model is only readeable by `base.group_sytem` so an AccessError will
raise.
closesodoo/odoo#70119
X-original-commit: 8930e08213d0b6805e6fc91fa07561107ef43acc
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
Steps to reproduce the bug:
- Try to export mail.message records
Bug:
A traceback was raised
Wrong forward-port of 69b27ac
opw:2514584
closesodoo/odoo#69912
X-original-commit: 9cf49ba3fa60c174abffc5c048616f91397f7b9d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.
From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.
The email sanitizing function have been updated so it takes care of the
above requirement.
See also #61811
opw-2448692
closesodoo/odoo#69864
X-original-commit: f0e840ae6db387e1dfc99cc21e09d84eb126e7b9
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
PURPOSE
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
SPECIFICATIONS
For better understanding, this commit renames ``no_auto_thread`` field of
``mail.message`` model to ``reply_to_force_new``, to indicate that if the
field is checked (☑) replies should check gateway alias rules instead of
updating mailed threads.
It is also more coherent with reply_to namespacing used in various mail models
(notably new composer fields and ``reply_to_mode`` of mass mailing and mail
composer models)
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
PURPOSE
Right now, `reply_to` field on email template is misleading due to poor
explanation. This commit improves the placeholder and tooltip of the fields
to make the purpose of the field clearer especially for non technical users.
SPECIFICATIONS
Update reply-to field placeholder to "Preferred email address when sending
via mass mailing options".
Update reply-to field helper message to "Preferred email address when sending
via mass mailing options. <br> Only used when the answer is not added into
the original discussion.""
Update the no_auto_thread field label to "Reply to" in composer and introduce
a new radio button replacing the checkbox
* The original discussion (thread)
* Another email address (new)
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Before this commit
When someone tries to send a mail to a restricted alias (which can be
anywhere in 'To', 'CC' or 'BCC') and if the sender is not allowed to do
so, the mail bounces. However bounced mail shows info as if it bounced due
to address provided in 'To', even though it is not always the case.
Example you send a message to
* 'To': 'valid@gmail.com' (okay)
* 'Cc': 'myalias@odoo.com' (not allowed for you)
Mail bounces because you are not allowed to send a mail to alias provided
in 'Cc', but it shows the message that: `The following email sent to
valid@gmail.com cannot be accepted because [...]`.
After this commit
Boucing alias is shown in message body. Above example becomes `The following
email sent to myalias@odoo.com cannot be accepted [...].`
Note: Because the alias can be present in `Bcc` too (which will not available
in the message values we get in `message_route_verify` method), we simply use
display name of the alias instead of finding mail address matching with alias
from the message values.
Task ID-2390310
closesodoo/odoo#69788
X-original-commit: 15325b19c15a649041db75bacbe8409ae4c58df7
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>
Steps to reproduce the bug:
- Go to Settings > Technical > Messages
- Select some records and export it
Bug:
A traceback was raised because
PS: When exporting data, the function export_date is called from web/controllers/main.py
with the attribute raw_data
opw:2504763
closesodoo/odoo#69308
X-original-commit: 69b27ac3f778b99a7d583ee6a9e8607a36d0a3b2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
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
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>
add mail_tz to calendar_attendee model in order to make it easier to change the
timezone displayed in the mail template so that we can use it to make the
appointment time shown on the email reminder sent to the attendees consistent
with the time shown on the website page.
Change the invitation mail template and use the mail_tz field to display time
field instead of using the partner's timezone in order to make the time shown
in the invitation consistent with the time shown on the website page.
Remove the get_interval method in the calendar_event model and use standard
formatting tools instead, as this is more conveniant than having a custom
method for formatting dates, For this reason the format_time function located
in tools/misc.py has been modified to be capable of handling timezones in
order to be able to display time in the correct timezone, furthermore, this
function has been added to the rendering context provided in the
mail_render_mixin file to be used in email templates.
see: https://github.com/odoo/enterprise/pull/16204
Task-2451154
closesodoo/odoo#65729
Related: odoo/enterprise#16204
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>
The code from v13 used to look for partners in JS before making the RPC, which
was much faster, and also gave better results by returning partners that were
already known and therefore more likely to be selected.
The same logic is reintroduced here, and further improved to take into account
all known partners and sort them according to the likeliness they will be
selected based on various criteria.
task-2413776
closesodoo/odoo#68045
X-original-commit: 930e090ced8134c3819a5a87b9052467ba23e8e4
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.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 ``channel_ids`` field from ``ir.actions.server``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to add them through server actions. 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 ``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
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
Channel now use only their members for notification purpose. Having followers
is redundant with members. Moreover as followers are not taken into account
for notification people may think followers mechanism is broken on channel.
Let us simply prevent from adding followers on channels and remove the widget.
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 the auto-follow mechanism on mail.channel. It is
used as a trick to have self-notifying channels. When posting on a channel
it listens itself. When a channel listens to a record its members are notified
depending on channel type. It means that a channel following itself notifies
its members in a magic way.
We decided to remove this magic and instead do a cleaner implementation of
this mechanism. ``_notify_compute_recipients`` method from ``mail.thread`` is
now overridden on channel model. It computes recipients to notify using a
custom SQL instead of the generic one given by ``mail.thread``. Some other
code adaptation is done to ensure notification on channel model is done as
intended on that specific model.
As channel model is somewhat different from classic mail.thread enabled
models let us implement its features in a more traditional way. More overrides
and less magic !
QUERY COUNTERS
Due to changes in ``channel_partner_ids`` fields being a computed inverse
searchable field there may be an additional query when performing a message
post as indicated by ``test_complete_message_post`` test. This is due notably
to message_format fetching channel_ids information. A call to ir rules on
channel is performed that uses ``channel_partner_ids`` as part its rule domain.
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
Purpose of this commit is to better differentiate channel members technical
model from partner members in code :
* ``channel_partner_ids``: contacts member of a channel, filtering notably
on active and checking ACLs on res.partner business model. This one
should be used whenever we deal with members of a channel at business
level;
* ``channel_last_seen_partner_ids``: memberships of a channel and technical
model. This one should be used for internal processes and members
management;
Also containing
* clean naming or API of methods managing channel members. This should
not change anything functionally as only code renaming / cleaning is
performed;
* improve performances of channel member auto subscription by aggregating
all members to add and creating them at once;
* check the use of ``mail.channel.partner`` and ``res.partner`` records
through ``channel_last_seen_partner_ids`` and ``channel_partner_ids``
Channel fields;
Functionally nothing should change with this commit. It only cleans code
in order to prepare future modifications.
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.
SPECIFICATION
Channel holds two fields computing current user's membership on channel.
``is_subscribed`` is a duplicate of ``is_member``. It is therefore removed
to keep a single field.
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
Purpose is to prepare modifications in models by doing a preparatory cleaning
of some fields and model definitions. Notably
* move mail.channel.partner im_livechat override in its own file;
* slightly re-order member-related fields on channel or mail.channel.partner
models, and split long lines;
This commit should not change anything functionally as it contains is only some
code move and reordering.
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 enforce model cleanliness by avoiding ugly
defined ``mail.channel.partner`` records.
``mail.channel.partner`` model is a decorated many2many relationship between
channels and partners (members). Both ``partner_id`` and ``channel_id`` fields
should be required. Members of a channel are always partners and belonging to
a channel is mandatory in that decorated m2m table.
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
A context key is added allowing to bypass user / channel synchronization
when creating users. This is used notably in tests to avoid subscribing
new test users to "general" channel created as default data.
Purpose is to avoid interferences in query-based performance tests. It also
avoids unnecessary data creation and/or update when it is not necessary
especially in tests.
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
Didier (did)