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'`
This commit prepares SMS refactoring by updating some mail models. Purpose
is to be able to store SMS notification information inside existing mail
flow and models.
Main changes
* mail.notification: define a notification_type field to store the medium
used to notify people. In mail two ways exist: inbox and email. It will
ease introduction of SMS notification mechanism. This field replaces the
is_email boolean field;
* mail.notification: make res_partner_id field not required. This means
notifications could be linked to something else than a partner. An SMS
for example. For Inbox and email notifications partner is still required
and a constraint is added accordingly;
* mail.thread: let notification methods handle the creation and update of
their notification instead of creating them in _notify_thread and tweaking
them in sub notification methods;
* mail.thread: clearly move inbox-style notification in its own method like
notify by email;
Some lighter code changes
* propagate message_type to notification recipient computation. It will
allow for example to be more precise when computing a notification type
depending on the message_type. For example, send a notification by SMS
when the message_type is SMS;
* ease inheritance of ``_notify_thread`` by returning computed recipients
data. It will allow to work on it without having to re-compute it;
* propagate kwargs from message_post and message_notify to notify methods.
This allow to avoid depending on context and set explicit parameters.
Drawback is that message_post and notify must separate kwargs used to
create a message and those that are propagated to notification methods;
* update various notification check to ensure they work on email
notifications, notably the resend and cancel wizards;
One side effect of this commit is that notifications are created by the
relevant notification method. Previously all notifications were created
by writing on needaction_partner_ids fields then updated according to the
notification process. Notably there could be too much notification created
when sending emails due to _notify_customize_recipients not being correctly
synchronized with notification. This issue is now solved as only really
sent emails create notifications.
Migration tips
* notification_type: notification.is_email and 'email' else 'inbox';
* remove is_email;
Related to task 1922163
Linked to PR #33510
Previously to commit [1] notification emails were send using the after commit
hook (see [2] for related code move and [3] for original code). That commit
changed the parameter default value without any reason, meaning this mechanism
is not used anymore. This commit fixes that behavior.
[1] See commit 581a74143e: code cleaning
[2] See commit 7a6269719f: code move
[3] See commit 38e181ee2c: use of post-commit hook in mail
closesodoo/odoo#34645
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This is mainly a typo / wrong computation introduced at 581a74143e.
This commit also fixes some typos in comments.
closesodoo/odoo#34443
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When an email is sent and is related to a record, there is a header with a
button link to access the record.
Before this commit, that button href was always linking to the base_url URL.
That was an issue on multi-website, since we need to use the website url and
not the base_url if the record is related to a website.
That's the case for a SO eg, after checkout you receive a confirmation email.
In a multi-website environment, we need to access the record website.
To do so, a previous imp/fix was done with c1be1993f9.
But this occurence still needed to be replaced.
Fixes#34309closesodoo/odoo#34397
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Some functional flows use sudo() to create records as current user is the
public user. This user has no email. Since 1e6c3bec2c using sudo does
not take superuser identity completely as it only bypasses access rights.
It means some messages are created with public user as author, meaning no
email_from.
In this commit we fix some functional flows by allowing message_log to store
messages with a void email_from. Indeed message_log does not propagate any
notifications, meaning email_from is not required in any email notification
or to compute a reply_to.
This reverts commit 6230f72d2b.
Crashing when user have no valid email is the expected behavior. Flows sending
emails must ensure either current user has valid login / email, either it
uses an user OR author_id / email_from that has a meaning in the functional
flow. Notably when public user is involved. Hiding functional issues is not
what we want.
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865closesodoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
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 is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
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
If no email layout is found when trying to render the layout around the
message content, just send body in notification emails instead of
crashing. See notably 89051058f4 .
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
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
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
Currently if a message has a res_id and a res_model it appears in the
matching record's chatter. Its access rights are computed based on this
record. This is the standard behavior of mail.message model.
User notifications are currently built on messages not having model and
res_id in order to avoid appearing on chatter. This has several drawbacks
notably access rights, redirection to the record, systray, finding back
records, ...
This commit solves those issues by adding new message_type 'user_notification'
that should be as a classic mail.message with model and res_id but without
the whole notification mechanism and without being displayed in the chatter.
An user notification is now a classic message pushed to a given partner only
and not displayed in the chatter.
Related to task 1943901
Linked to PR #32404
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Before this commit `_get_tracked_fields` was not called in batch because it took
the `updated_fields` parameter, but this parameter is not used.
By removing the parameter and calling the method in batch, creating 1000
products takes 20% less time.
Part of task-1918881
closesodoo/odoo#34347
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
* 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_receive_bounce as private. Future commit(s)
will probably rewrite part of the bounce logic.
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
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_partner_info_from_emails 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
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
fine-tuning commit 1120bffb66
Before this commit, the search on message_has_error (used when clicking
on a failure notification) only display errors linked to message of the
current user. Also, the filter Has_error is true, in the messages view
in technical menu only display the message with errors of current user.
Now, the filter Has_error is true display the message with errors of all
users. The search on message_has_error behave as before.
opw-1958813
closesodoo/odoo#32462
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create a record.
Add an attachment set as message_main_attachment_id (e.g. through log note).
Duplicate that record.
The new record has the message_main_attachment_id of the old record,
while it has no attachments.
Since attachments security is linked to the record id, we shall not copy them.
opw 1950403
closesodoo/odoo#31846
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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.
Adrian Torres