This reverts commit fbd30f4266d86b53aa4b13b72a93bccee0d7eb69. Indeed kwargs
are used to build a link, meaning message value are given to some links when
using message_notify.
A better fix will be provided soon. Reverting to avoid issues in stable.
closesodoo/odoo#61632
X-original-commit: e861f7294a7bd6bde056b987f15e48df4b0ab877
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
opw-2358846
closesodoo/odoo#61478
X-original-commit: 075325226d6f7c2af638013f25613ddd391e506b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Purpose
=======
Make the "activity_state" searchable on the "mail.activity" mixin.
This field is not stored as it depends on the current time.
Technical
=========
To make the search, we perform a SQL query.
The "activity_state" depends on the state of each activities on the
record. And this state also depends on the timezone of the user of
the activity. That's what made things tricky and we need to make the
conversion in SQL for performance purpose (we can not fetch all records
and compute them in python).
There's a special case, where there's less than 24 hours between the
deadline and the current time but one day of difference. In that case
the state should be "planned" and not "today". This case is handle by
the function "DATE_TRUNC" (e.g. 23h 01/01/2020 & 1h 02/02/2020).
Also for performance purpose, we compute the delay only once and we use
the function "SIGN" so we can use a switch/case instead of duplicating
3 times the expressions.
Task 2354754
closesodoo/odoo#60074
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is simply to add tests about alias defaults.
Code protects it against being badly formatted. However having
tests ensuring it is always a good idea to avoid regression.
Task ID-2361179
closesodoo/odoo#60026
X-original-commit: 0075cc02f9a11dcddaf9ca7d70cc1adf7596f6d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- channel_seen is now called even for own message and only when needed
- channel_seen is now called with a message_id which transfer the
decision of what is seen to the client which makes more sense
task-2282235
task-2282248
closesodoo/odoo#57956
X-original-commit: 04edfa50ccea305050d017c4a1996e561bc7bd57
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Incorrect override of message_post.
Without this decorator, message_post returns a string `mail.message(ID,)` via
RPC. Discuss needs the message ID to scroll chat window
closesodoo/odoo#57123
X-original-commit: 3939d3aa3b60e0f606a9f7defd695417f7b3f383
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Document creation or update is still done without auto subscribe. Indeed user
running mailgateway or owning alias is not necessarily linked to the email
author. That way we avoid auto subscription of irrelevant people.
Posting message based on incoming email is now allowing auto subscription if
there is an author found during email parsing. We also ensure this author is
not root, to be sure he is not added in followers of documents.
LINKS
Task ID-2326281
PR odoo/odoo#56560Closesodoo/odoo#38383
X-original-commit: fe27f9fe0cf9581c15a2a9e45125abe82dd303ad
Tested flows
* posting a message through an inactive partner (like automated actions
posting a message on behalf of an inactive partner);
* automatic subscription based on parent record (like an archived user and
partner following a project that should not be added as follower of sub
tasks);
* automatic subscription based on responsible field: this is already fixed
as user has to be active to receive a notification and be added in
followers;
LINKS
Task ID-2326281
PR odoo/odoo#56560
X-original-commit: 42910ce25f06a31af3cfbc8d5d41e443ee754c34
There is no test ensuring standard message_subscribe API does not subscribe
inactive partners. As this is part of this method purpose, let us add a test
to avoid any regression.
LINKS
Task ID-2326281
PR odoo/odoo#56560
X-original-commit: f45d7ace687911f4090c081bdc0e8127c382bd64
- flush must be done before executing queries
- when the current partner is given, it shouldn't be checked twice
- when a channel includes the given partners but also has more partners, it
shouldn't be returned
- query can be limited to 1 result, minor performance gain in the rare case
where more than one canonical channel exists
task-2324119
closesodoo/odoo#56680
X-original-commit: b716dd9e62991997e03556f2d3e2483921fedef9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Make the method `_search` return a `Query` object, and make that object
generate a subquery when used on the right-hand side of a condition.
closesodoo/odoo#52403
Related: odoo/enterprise#10945
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When users are archived / deleted, they are still listed under the members
of a channel. This means that those users could potentially still receive
internal communications.
This commit fixes the issue by removing archived / deleted users from the
members of the private channels they were part of. However, they are not
automatically removed from the public channels.
Public channels are kepts as in most common cases public channels are
mailing list (e-mail based) and so user's partner should always receive
updates from public channels until they manually un-subscribe themselves.
Task ID-2276681
closesodoo/odoo#55496
X-original-commit: 1a3dc58f3d987054c643556dc4b7c3dbcd3d074c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Currently, there is an on-change to set an activity summary to the default
summary of an activity type. This can be useful if types are properly
configured. The problem is, the activity summary will be updated even if there
isn't any default summary on the type. Meaning that it simply removing a
relevant custom summary the user might have already entered.
SPECIFICATIONS
When triggering the on-change on activity_type_id, only update the activity
summary to the default summary if there is a default summary defined on the
activity type.
LINKS
Task-2254825
PR #51373
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Bug
===
Since 0bd14547a7,
When editing a record which has a tracked field with a group, and if
the current user is not in the group, an error is raised.
Technical
=========
When we get the tracked fields, we must care about the group of the
current user and keep only the tracked fields the user have access to.
To do that, we use `fields_get`, which will return only fields accessible
by the current user group.
The method `_get_tracked_fields` is cached, but it need to depend on
the current user (and also if we are in sudo mode or not), because the
function will return different results, depending on the group of the
user.
Task-2250070
closesodoo/odoo#51915
X-original-commit: c7010058a93ca2fd3b65ac978d8333b273f04fac
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Message with type user_notification are special "invisible"
notifications that are not accessible to users normally. That's why they
were excluded from the automatic message deletion in
mail.thread.unlink(), to avoid permission errors. But this caused
orphans leftover notifications in the database, and the fix here is to
instead do the deletion of messages in sudo mode, and make sure
user_notification messages are deleted as well.
Doing this is not a security risk because the deletion of the record
itself (the super call) is still done without sudo, and if it fails,
the whole transaction will be rolled back. And it is part of the
expected ACLs for messages that if you can delete a record you are
allowed delete its messages. The fact that user_notification messages
are not accessible by normal users is for usability reasons (noise in
chatter), not security reasons.
opw-2234282
closesodoo/odoo#51010
X-original-commit: 094559aef4fdfebcba43a089cec4da5f4028a8f2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce:
- Create a second company
- Enable this company only
- Create a new company
=> Access error is raised because the `intercompany_user_id` is
OdooBot by default and OdooBot's partner cannot be read from
other companies. Hence, the company creation fails.
Like all other internal users/partners, OdooBot's partner should
be shared across companies, even if its user is inactive.
Task 2157039
See also 2390ba6
Task 2157039
closesodoo/odoo#50372
X-original-commit: 379d14d4aa7862176fb7e3f79292a1228c254aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Umbrella -> Container, easier to understand that we target a ticket / project
like model using mail.test.ticket and mail.test.container .
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Keep only mail-related tests, move odoobot in test mail full, send "update
notification" tests in mail (specific to mail). Merge some test files to
lessen number of files, perform light file renaming.
Split test mail models file to prepare some cleaning in those models and tests.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
PURPOSE
Have a cleaner test_mail addons
SPECIFICATIONS
Keep only mail-related tests, move odoobot in test mail full, send "update
notification" tests in mail (specific to mail). Merge some test files to
lessen number of files, perform light file renaming.
Split test mail models file to prepare some cleaning in those models and tests.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
Many users have complained about the automated OdooBot answers like
"Pong" when the bot is pinged, that fill the chatter when the user has
the mail_bot module installed, and add no real value.
In v12, the hr module did not have a hard dependency on mail_bot, so the
users could uninstall it if they did not want/need its functionality. In
v13, mail_bot was added as a dependency to include the notification
widget and the odoobot state in the user forms modified by the hr
module. However, this also brings potentially unwanted functionality to
anyone who installs an hr related application.
This commit removes the dependency on mail_bot by adding the mail_bot_hr
bridge module, which provides integration between mail_bot and hr if
both modules are installed.
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Make aliases usage more unique, prevent re-using bounce or catchall aliases
and remove auto-uniqueness of aliases.
SPECIFICATIONS
Before this commit, user could create an email alias having same name as
catchall/bounce email alias, which should not happen. Also, while creating
or duplicating alias, if the same name was already available, a new unique
name was generated by adding a sequence number to existing name.
This behavior is not considered as a good one as it magically creates aliases
different from what user expects. User could even not own the newly-created
alias, leading to a broken mail gateway.
In this commit we improve that behavior by ensuring that no duplicate alias
name should be entered while creation / updation for both catcall/bounce and
mail alias. Also, while duplicating an alias, name will now be blank by default
to force user to enter the name. Finally when creating an alias an error is
raised if the name is already taken.
Task ID 2160070
From opw-2200219 opw-2210285 (v12)
Use case (2200219):
- Install CRM, sales and Automated Action
- Create the automated action
* Model -> Sale Order
* Trigger Condition -> On creation
* Action To Do -> Add followers
* Add Channels -> sales
- Create a new CRM opportunity with a partner set, Save
- Click on the "New quotation"
- Save
A Traceback "Error: A follower must be either a partner or
a channel (but not both)." will popup, blocking the user from
completing the action.
Use case (2210285):
After adding a channel as a follower to a sales team it is not
possible to create a sale order from a contact or opportunity. You can
only create a sale order from the sales app in that case.
End of use cases-----
This occur because the context flag default_partner_id is used by
the model to override the empty partner_id which should remain empty
Fixed in v12, forwarding the test for v13 and upward
closesodoo/odoo#48476
X-original-commit: 049aa5c2297938bcd378d1dee1aa766a646cb461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A commit merged very recently added 1 more base query to both users, but because
the count of that particular test is non deterministic, the issue is only
spotted later on runbot, and it has to be fixed now.
closesodoo/odoo#48331
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
PURPOSE
When incoming emails bounce due to alias security bounce email is quite
generic. Purpose of this task is to ease its customization and update.
SPECIFICATIONS
In order to improve the flexibility of alias, add a customizable html field
on the alias model. This html content will be send as bounce email core content
in case of bounced/unauthorized mail received for this alias,
Obviously it has no effect on 'everyone' security setting as no email will
bounce due to that issue.
If it is not set a default generic mail will be send depending on security
setting. It allows to keep void html fields when no specific bounce content
is required
In HR, an old template allowing some light customization for employee based
security option is removed as it is completely replaced by the new feature.
Also add references message-id of the mail received to the answer so that
threads are correctly set.
LINKS
Task ID 2126509
Fine tuning of 1e411e3a6d
- It moves the attachment in the message when we mark an activity as
done.
- It adds a test
OPW-2196668
closesodoo/odoo#47349
X-original-commit: 2033066426a6af6eed5f80f1bcde6e650e998f0d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the subtype data were already in the cache, by
not always reading them again.
Part of task-2180311
PR: #43841
in `message_format` and in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the notifications and tracking data were already in
the cache, by not always reading them again.
Part of task-2180311
PR: #43841
in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the attachment data were already in the cache, by
not always reading them again.
The `has_access_to_model` is removed and replaced by `sudo` because:
- from portal everything is sudo so it's pointless to check access on top of it
- from backend, it's almost impossible to trigger the case, and it's not like
returning is_main True would leak any sensitive information to an employee
Part of task-2180311
PR: #43841
It was partially tested already as part of some other performance tests, but
this new test will cover more specific cases of `message_format` and
`_message_read_dict_postprocess`.
The goal is to ensure the performances are not made worse by the following
commits, or even to be able to notice when they are made better.
Part of task-2180311
PR: #43841
Similar to what is done for the other tests, mute unnecessary log such as
`odoo.tests: skip sending email in test mode`.
Part of task-2180311
PR: #43841
When mailgateway receives an incoming email being a reply to a thread but
containing a recipient being an alias linked to another model, it is
considered as a forward to that new alias. It therefore skips the reply
step in routing and applies rules related to new thread, aka checking
all recipients.
Consider this use case: receives a email on a task from "project@domain"
project being the alias of the project which creates new tasks when not
routing replies. Reply / forward it to "project@domain, sales@domain" in
order to transfer it to the sales team (sales alias creates new leads).
As this is a forward, both aliases are evaluated, leading to a new task and a
lead which is not what we expect.
We solve this issue by removing alias linked to the ignored reply model
when considering recipients.
PR #46764
Task ID 2121551
closesodoo/odoo#46784
X-original-commit: 7cff7787cb42cc9d3d0cb4c5af41a9f09d59d1ff
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
/!\ This commit is a manual forward-port of two PR targetting originally
11.0: #40442 and its fix / partial revert #41042. /!\
Purpose of this commit is to check all recipients of incoming emails when
trying to determine the route to apply. Notably
* an incoming email should be considered as a write to catchall only if all
recipients are catchall. Catchall + a valid alias should take the alias
into account;
* an incoming email sent to the bounce alias should be considered as a bounce
even if another valid alias is in recipients and whatever the order. Indeed
it indicates an issue and bounce is considered as more important;
* forward to an alias linked to another model should check all recipients
and not only the first one. Otherwise reply_alias, forward_alias is
considered as a reply whereas it should be considered as a forward when
considering all recipients;
Tests are added according to those specifications.
Please see original PRs for more details about the content, the comments
done on it and the various discussions.
PR #46764
Task ID 2121551
X-original-commit: df00bd2d3bddf9a2b56e8554380669025e146d21
When the `select` returns nothing more than ids that are already known, there is
no need to make it at all.
This removes one query from `_read` every time it has to fetch only fields that
are stored in a different table (o2m, ...), which happens all the time when
reading a stored field first (triggering prefetch) and then reading a o2m.
The query that is now removed was used to check access rules, but the trick is
to use `check_access_rule` to verify the rules in python instead.
Part of task-2061122
closesodoo/odoo#36263
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order
as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created.
This causes duplicate entries in the mail.notification table, and can
crash when an old unique constraint is still present in that table (from
earlier Odoo versions)
To prevent this, we deduplicate the notifications and order by notification
type to get 'email' first in case the user have different notification
type ('email', 'inbox').
How to reproduce:
- Create a first user test1
- Create a second user test2
- Merge the contact test1 and test2
- Create a customer customer
- Set the user test1 as salesman
- Create a new sale.order with customer as partner
Add a test to reproduce the pathological scenario
Solution
add distinct on partner.id and order by partner.id,
users.notification_type
closesodoo/odoo#45386
X-original-commit: 00f36c60e4790c8f5341cbc4f2c67e22e6d68f87
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Thibault Delavallée