Before this commit, archived and deleted partners had not their
im_status being updated automatically. There were some issues
with this, notably:
- odoobot 'bot' status was not displayed in chatter
- im_status of partners becoming archived were not updated.
This commit fixes both issues.
task-2329591
closesodoo/odoo#60567
X-original-commit: 63b081c49da089c839479b807de8c0cea45221da
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closesodoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In 6e25a510b3 `find_or_create` was
modified to return a recordset rather than just an id. This made it
incompatible with the RPC protocol and it was not annotated to
downgrade the return value back to an id.
Fixesodoo/odoo#54466closesodoo/odoo#54476
X-original-commit: a7e3894e20207b714cebefa908be090967866791
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
PURPOSE
Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.
SPECIFICATIONS
Track partner update of email and phone field. Now, when an user writes on the
email or phone of a lead, it also writes on the partner. That is why we want to
track those fields.
Task ID 2207636
PR odoo/odoo#48395
Related: odoo/upgrade#1025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rewrite code parsing name (_parse_partner_name) to make it easier to
understand. Tweak find_or_create to return directly a recordset with the
found partner / new partner instead of a name_get result.
Also inherit Partner.find_or_create() in mail in order to benefits from
email_normalized field, allowing to improve the search on matching emails
and avoid duplicates.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
Archived users are inactive, so we shouldn't be able to ping them.
Task-2046885
closesodoo/odoo#40814
X-original-commit: 8169e34a2230b9a2aff359dc6a69b59c04fc9908
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose of this commit is to improve performance of post and notify through
various code improvements.
Containing
* making of _notify_customize_recipients a mail.thread method;
* _message_auto_subscribe_followers optimized;
* renaming and optimisation of _notify_partners;
* message_post_attachements optization;
* remove unused mail_post_autofollow_partner_ids context key;
* minimize message create queries;
* only check record related access right for thread messages not in pending
moderation;
* get attachements from values instead of db;
* storing lang in ctx from the beginning;
* don't track on write on attachments;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to move notification methods to mail.thread. Indeed
currently they are split among several models: thread, message, partner.
It makes code difficult to understand. Base record has to be propagated in
order to run methods on it. It is therefore simpler to make those methods
on mail.thread and correctly have model methods.
All notification methods are moved into a single section in the mail.thread
file. This implies some more code move inside mail.thread but allow to have
methods classified by their purpose.
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
* mail.blacklist.mixin now clearly make inheritance on mail.thread. Indeed
we consider models using the blacklist mechanism as being used in mailing
features, meaning they will anyway inherit form mail.thread. In standard
Odoo it is the case for the 3 models using it (Lead/Opportunity, Contact
and Mailing Contact);
* define message_bounce directly in mail.blacklist.mixin. Bounce counter
is indeed linked to the blacklist and mailing mechanism;
* rename mail.blacklist.mixin to mail.thread.blacklist to ensure coherency
with mail.thread and mail.thread.cc (another mixin build on mailL.thread);
Inherit declarations in various addons are updated accordingly.
Related to task ID 1911679
Linked to PR #29483
Purpose: make some methods from mail.thread mixin private and update their
naming if necessary. Some methods prepare data for business flows and deal
with internal information. Public methods should either use of give some
access to those methods. Computation itself should be keps internal.
In this commit we put message_get_suggested_recipients as private. As it is
used in discuss JS we define a controller that controls access to this method.
It explicitly checks for related document access rule and rights before
calling the private method.
Some addons are updated accordingly to the method change.
Related to task ID 1911679
Linked to PR #29483
Purpose: make some methods from mail.thread mixin private and update their
naming if necessary. Some methods prepare data for business flows and deal
with internal information. Public methods should either use of give some
access to those methods. Computation itself should be keps internal.
In this commit we put message_get_default_recipients as private. Its API
is improved to clearly separate model-inherited method (overriden in some
addons) and general tool method given by the mixin. Finally all sudo hidden
in the computation are removed. Caller now give a sudo-ed record set in order
to be more explicit. Low level method just computes the result and does not
care about sudo-ing or ACLs.
Note a model approach for this method is necessary as mass mailing using
mail.template records does not ensure records to check inherit from mail
thread.
Some addons are updated accordingly to the method change.
Related to task ID 1911679
Linked to PR #29483
This commit renames the `groups` field into
`field_groups`.
The previous name was impossible to grep as
the word `groups` is everywhere in the code base.
Also the new name better follows the implicit convention
that fields related to the tracked field all start
with `field_`.
Purpose
=======
Currently fields with a `groups` attribute can't be tracked.
Otherwise changes would be visible by all in the chatter, including
users which normally don't have the access rights because they are
not members of `groups`.
Specification
=============
Filter tracking field values according to the `groups` attributes.
Users without the access rights should not see them.
If a message is only composed of tracking values and the user doesn't
have the rights to see them, an empty message should not be displayed.
This commit is a refactoring of im_status management.
This commit also add im_status in two places, near the author in a mail thread and on each suggestion when using mentions.
A service to manage im_status will have multiple benefits here:
-centralise information, avoid to call the server multiple time for the same im_status
-update all im_status at once and keep consistency in display.
With this commit, the im_status updates are now done by rpc call.
Updates where previously made with the bus but this has some drawback,
since the bus will only give the information 50 seconds after the beginning of
the request, in the worst case, we van wait 2*50 seconds to get an update.
More than that, the im_status where only updates for pinned dm_chat. Dm chat
are synchronized cross tabs, making the use of the bus possible for this purpose.
Since we will need to display im_status not linked to dm_chat, the list to update
will be different from tab to tab making the use of bus difficult for this purpose.
Technical notes:
-im_search has been moved from bus to mail addons since it concerns mail.channel
-Update of an im_status should be reflected everywhere in the page.
Since im_status is a rendered template used in multiple widget, we should add
the correct logic to all concerened widget. The current solution is simple:
use a jquery selector to find every place where im_status is rendered.
-we add a new im_status: im_partner. This will indicate that that
the partner has no user linked to him, making it possible to avoid to ask
for status updates for this partner.
-The update will only be done when the tab is focused. (and will be done
asap once the tab get focus back)
- Create a PO for a French customer
- Send by email
The body of the email is in French, but some parts (such as the View
button or the footer) are not translated.
The body is translated following the field `lang` of the email template,
in this case `${object.partner_id.lang}`. This is done when opening the
mail composer (so the message appears in French). However, other parts
are rendered only when sending: at this point, the language to be used
in the template is lost forever in the darkness.
To avoid this, we keep a specific context key `custom_layout_lang` that
we retrieve when rendering the custom layout.
opw-1908420
When creating a mail for a user in an other company then the
record, the "send" button fails with a traceback because on
specific template try to access the company.id of the user
which is not accessible due to the access controle.
This PR fixes the problem by sudoing the access to company id.
The mail now sends without problem.
Step to reproduce:
1. Use two companies (comp1 and comp2)
2. Use 3 users (user1, user2, user3)
3. Be sure every user has a confirmed account
4. Change the users to set both company as allowed.
5. Set the current company of the users as follow:
user1: comp1
user2: comp2
user3: comp2
6. Install the project module
7. In `settings > security > record rules`, archive the rules named:
- `Project: multiple-company`
- `Project/Task: multiple-company`
- `user rule`
8. Using user1, create a new project and a new task.
9. Using user2, go to `Project module > Search`, remove `My tasks` filter,
select the task created by user1, in the chatter add user3 as follower.
10. Send the mail => access error.
The `AccessError` is due to user2 trying to access comp1, in particular
`company.name`.
By adding a `sudo`, we also make sure that the template rendering won't
fail bacause of a similar `AccessError`.
opw-1907844
closesodoo/odoo#28710
Purpose
=======
- Apply the blacklist implementation to Improve mailing subscription to be more
compliant with the European GDPR law. Keep a list of people who does not want
to receive promotional emails (or mass mailing in general) anymore.
- Allows the recipient to update himself his mailing preferences
Specifications
===========
This commit is regrouping some main changes on mass mailing.
Apply Blacklist for following models through blacklist.mixin :
- crm.lead
- res.partner
- mail.mass_mailing.contact
- mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
as thoses pages should work without having the website module installed
Detailed implementation
===================
Mass-mailing :
- A blacklisted email is notified by the ban icon next to the email field.
(at the left of the email field for display purpose)
- Renaming the '_get_blacklist' method that was actually
searching opt_out list into 'get_opt_out_list'
- Opt out per mailing list : Add opt_out + related fields (for display and
ergonomy reasons) on the relational model
- Display relational model tree view instead of mass_mailing.contact tree
view when clicking on mass_mailing_list in kanban view
-> In order to be align between contact_nbr displayed in kanban tile and
the content of the tree view
-> mass_mailing contact is accesible via the user icon in this tree view
- Remove custom filters 'filter_contact_subscription' and
'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
model anymore
- Add 'is_public' to mailing list
The name of this mailing list can be seen (or not) by recipient in
the unsubscription page
If the mailing lists used in the mass mailing are not public,
the user in only informed that he has been unsubscribed.
If the mailing lists are public, the user is informed that he has been
unsubscribed from the mailing lists
and he has the choice to modify his subscription to all the public
mailing list he is or was subscribed to.
- Unsubscription Page :
- mass_mailing_contact :
Opt_out per mailing list, done by email and not by id, as multiple
contact can have the same email
The recipient can add/remove himself to/from the blacklist
The recipient can send a feedback about why he unsubscribed
- crm.lead + res.partner :
Once the recipient unsubscribe, he is automatically blacklisted
The recipient can 'Come back' and remove himself from the blacklist
if he changes his mind
- Show blacklist button parameter added in config :
The idea is to enable/disable the fact that the recipient can add
himself to the blacklist by showing or not the 'blacklist me' button
Only applies for mass_mailing.contact. The recipient, once
blacklisted, can always, no matter the value of this parameter,
'come back' and unblacklist himself
crm.lead + res.partner :
- Replace opt_out by blacklist in crm.lead + res.partner models.
As when a res.partner or crm.lead unsubcribe, we assume that the recipient
does not want to receive mass mailing anymore, at all, even if we adds him
to a mailing list afterwards. He is then blacklisted to avoid this.
With this behaviour, if a new lead is created with the same email address,
he won't be able to receive mail in mass_mode.
But he will still be able to receive '1 to 1' direct email.
Task ID 33224
Closes#25966
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit cleans code about sending email notification to recipients.
Purpose of this code is to prepare notification emails, group recipients
and finally send emails. In this commit we clean and optimize a bit by
* propagating some additional parameter to simplify code, like record
on which the notification process runs;
* inlining some code currently located in sub-methods. It eases code
understanding as there are less code jumps. As those methods are not
inherited inlining them can be done;
* simplifying a bit notification emails preparation and computation;
It allows to save a few query by avoiding to fetch and browse again some
data that were already computed.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
If notification layout used to encapsulate message send by email is not
found simply send emails without layouting instead of skipping it. We
should not avoid information to be send.
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
This commit proposes to ease the use and specification of layout used to
encapsulate email body when sending notification emails. This is done
through two means
* message_post_with_template now supports the custom layout parameter
that allows to set the layout to use when sending notification emails
in the message_post process. We have to rely on the context as it is
the current way of using it in the composer. It is likely to change in
a near future;
* composer now supports through context (as we have no other choice)
specific notification values to give to the notification layout rendering;
This commit is related to task 51122 (and PR #24052).
When a mail is in failure state, a red envelope appears next to the message
in a thread but it was difficult to send the mail again.
This tasks will allow users to send mail again easily, or mark notification
as cancelled if the user want to ignore this failure.
A notification will appear in sender systray while mail are in failure.
Task: #46158
PR: #24628
mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
Well, it seems we gain a lot of query when avoiding to format a message we
actually don't have to send on any bus. Cheers.
Formatting message for bus notification is quite costly as it has to fetch
data from message, partner, attachments, subtypes, ... meaning a lot of
queries. With this commit we avoid calling that method when not necessary.
It allows a gain of queries in simple cases when no-one has to be notified
as shown in the performance counters. On overall community runbot about 9K
queries are saved which is not bad for a 2-lines commit.
Use option recently introduced to use a minimal context when rendering
some mail templates such as
* notification template used to decorate messages sent to recipient
when using email-based notifications;
* user assignation template used when people are assigned on a record
and a notification is sent to inbox or email;
* message_post_with_template now uses minimal context meaning calls to
that method should be sure evaluation context is correctly set in
the given values;
This optimization allows to save some queries every time one of those
template is used, meaning all tests gain between 1 to 4 queries depending
on their complexity.
This commit is related to task ID 1817951. Closes#23291 .
Notification template has been converted into QWeb at commit 0f301bec25.
A variable renaming has not been correctly propagated, leading to
tracking values not being displayed in notification emails. This
commit fixes that.
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
Since notification emails are not mail templates anymore they do not go
through the mail_template.render_post_process() method that converts
local links to absolute links. This means that buttons and images were
not correctly displayed in notification emails. Indeed those still had
local links.
This commit fixes that by moving the method directly in mail.thread and
calling it accordingly when rendering the notification email. Note that
the method has been changed in order to use regex instead of html
parser. It is done based on work already done in mass mailing application.
Indeed using parsers is complex and time consuming and may create
changes in the html structure that are not intended.
Next step in master is to go through various link modifications in
mass mailing module to see how to handle them properly. Maybe.
Notification emails now use QWeb to be rendered instead of jinja-based
mail.template since 2f7593761c. Part of the notification emails was not working
anymore since its syntax was still using jinja. This commit fixes that.
This commit also removes strange ';' that should not be part of python code
as well as an unnecessary variable propagation.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
Purpose of this commit is to clean the use of custom_layout in context
in order to have more explicit argument.
Several mail.compose.message instances are called using the
custom_layout magic key. As this parameter is now managed directly
by message_post API we can remove its management in the notification
process and add it explicitly in the wizard's message_post call.
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
Notification emails contain a link allowing to follow or unfollow
documents directly from the notification email. However there are
several issues with this button
* it require people to login to follow or unfollow documents;
* it is not linked to the email;
* if the customer does not have a login it is not possible to perform
the action;
* there is no confirmation step;
This commit removes the follow / unfollow button in the notification
emails. Indeed as people have the "Access document" button there is
only one more click to perform in order to subscribe or unsubscribe.
Concerning customers adding a complete control of the follow mechanism
would be costly in term of code and access rights checks. We therefore
decided to remove this button.
It also allows to simplify a bit the notification process as there
are less parameters to take into account when grouping recipients. It
allows to lessen the number of required template rendering when sending
notification emails.
Thanh Dodeur