Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
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
Right now on few business objects (like leads, invoices, tasks, helpdesk
tickets etc) creation message contains
* subtype description;
* generic creation message;
This looks like multiple creation message on chatter after creation of the
record as you generally have "Task Created - Task created" (subtype description
then generic message).
This happens when we provide custom subtype on creation by by overriding
`_creation_subtype` method.
This commit fixes the issue by only using provided creation subtype and
removing default body. If creation subtype is not provided default creation
message is posted as before.
In this commit we also fix subtype for Lead/Opportunity creation and make
it generic ('Lead/Opportunity created') to avoid inconsistent behavior.
Finally some cleaning is made in method naming. Semi followup of 92e9e84b63
LINKS
Task ID-2288458
PR odoo/odoo#56631
PR odoo/enterprise#12707closesodoo/odoo#56688
X-original-commit: 2ebbeb4b5443c6405dd9a3b202a1eee9c5c67ebb
Related: odoo/enterprise#12728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Since v13 some commits added code in mail thread file. This file is already
quite long and keeping it organized allow to understand its content.
SPECIFICATIONS
Some methods defined on mail.thread may actually be called on models
not inheriting from mail.thread . Instead of having model methods on mail
thread receiving a records parameter it seems better to have those available
directly on BaseModel.
Move static_message_track on BaseModel in models.py. This method is now called
_mail_track, to be coherent with othe rmail-related naming. It is used in
accounting to track values in line model that does not inherit from mail.
thread. Update accounting accordingly (followup of d862965).
Move _message_get_default_recipients_on_records in models.py. Renaming it
_message_get_default_recipients() allow to be compatible with current behavior
and current override available in some addons (like CRM, event, ...).
Move _notify_get_reply_to_on_records in models.py. Renaming it
_notify_get_reply_to() allows to be shorter and coherent.
Move _alias_check_contact_on_record in models.py. Renaming it
_alias_check_contact_() allows to be shorter and coherent. Its override in
hr is also moved on BaseModel.
LINKS
Task ID-2327096 (code cleaning)
PR #56631
X-original-commit: f5df1ed912455e5ed52a65df3149f30a9d424de0
PURPOSE
Since v13 some commits added code in mail thread file. This file is already
quite long and keeping it organized allow to understand its content.
SPECIFICATIONS
Clearly separate CRUD / CRUD HELPERS / TRACKING / ... . Notably tracking
code was split accross two code sections.
Make some internal tools methods private. They do not require to be public
* with_lang: does not makes sense to be available outside of odoo. It is
renamed to _fallback_lang as it does not allow to set a specific lang in
the environment like with_user. It is used to fallback on user's lang
in context;
* get_mail_message_access: purely internal method used for access rights;
LINKS
Task ID-2327096 (code cleaning)
PR #56631
X-original-commit: 4a5fc70cfc3c86da33e2480fbd59c8f6d575c6e9
Update mail alias layout, makes email address
clickable (mailto) and fix a couple of typos.
Task ID 2287394
closesodoo/odoo#53960
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Configure a catchall address in Odoo, send an email to that very
address, it should bounce back to the user asking him not to send any
email to the catchall but the email is never sent.
Internally, Odoo reply to the user using the `To` header of the original
email as `From` of the bounced email. It should never use the catchall
address as it is not a valid email to send email from.
closesodoo/odoo#53036
Task: 2277661
X-original-commit: 86c8f0960f709692aa787ae62d446b4427a7c312
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
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>
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
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>
PURPOSE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
LINKS
Prepares task ID 2238597 (notification and trace models cleaning)
Task ID 1906925 (mass mailing tests cleaning)
PR #50169
PURPOSE
Be able to customize notification email values in a given model by overriding
a simple method instead of having to hijack the email creation process.
SPECIFICATIONS
Add a hook in mail.thread that can be overridden in specific addons, either
by model or globally by inheriting mail.thread.
Include _notify_email_headers in it so that it is correctly embedded in
model-specific values computation.
This removes the need to replace _notify_record_by_email long method in a
custom module.
Closesodoo/odoo#48213Closesodoo/odoo#50097closesodoo/odoo#50129
X-original-commit: 1ba8712d7a797cf2e821ae881cb1f1c4ea2fc11d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
PURPOSE
Move links shortening tools on mail.render.mixin to have rendering and
post procesing tools available on that mixin.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
MailThread._mail_search_on_* was obviously never called with an
extra_domain yet, or it would have raised an exception: expression.AND
expects only one argument, with the list of expressions to AND, and here
we were passing them as *args.
closesodoo/odoo#47585
X-original-commit: b20c5350c4d0e0e140f8824e6f5d2a0009af9810
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
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
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
Before this commit, no recompulation were performed at the end of the
tracking procedure. This is because the main flush() occurred before
the tracking of values. The absence of flushing is problematic in the
case where the tracking is used to create/update records.
closesodoo/odoo#44851
X-original-commit: c60da49a1d81fa73b60135185d5b706eec771475
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
How to reproduce
================
Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.
This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.
Fix
===
In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.
Task ID 2061760
PR #36845closesodoo/odoo#44765
X-original-commit: e94349ed65e05a40af6e690e366de81fc5aa6725
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
This commit prevents sending a notification within Odoo when a
message is posted from a mailing channel to a user whose notification
management preference is set to "Handle by Emails".
Task-ID 2033302
closesodoo/odoo#36000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
Before this commit, the method _mail_find_partner_from_emails could
return a list mixing partner ids and partner recordset, that could
lead to issue when trying to read the different elements.
With this commit, we ensure that we return a list of records only.
closesodoo/odoo#44608
X-original-commit: 2fbbbd8609fd2e08545ddb1ab8e2d7d22ee4d292
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist
closesodoo/odoo#43830
Taskid: 2176445
X-original-commit: 82d2d581a2590a9c782cbc71b5005a4198b70d77
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Purpose of this commit is to always call followers API with explicit parameters
about existing followers management (check_existing and existing_policy
parameters). It makes code easier to read and maintain.
LINKS
Task 1933771
Task 2078313
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Before this commit, when a user joined, left, or was invited to a
channel with "Send by email", it sent an email notification to every
member.
This commit disables email notification on subscribe/unsubscribe on
a channel, while still showing messages on join/leave.
Task-Id 2003281
closesodoo/odoo#35142
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this commit, when changing subtype subscription from a parent
record (e.g. project of task), then it does not update subtype
subscription of existing records. Changes on parent record should
only affect new record afterwards.
Task-Id 1974055
Closes#34150
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this commit, when the user subscribes to internal subtypes
(i.e. activities and notes) on a parent record (e.g. project of
tasks), then the user follows them by default on every record
creation (e.g. all new tasks of this project).
Task-Id 1974055
Closes#34150
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In this commit we use the is_internal flag to correctly propagate it from
mail gateway and clean some parent check. In this commit some code is cleaned.
No functional change should occur with this commit.
LINKS
Task ID 2071556
PR #38692
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
Website mail defines a website_published field allowing to publish / unpublish
comments on the frontend of some modules. This field has several drawbacks :
* it is used only for front-end people (portal, public) and has no real
effect in chatter / classic discussions;
* it is used only in some advanced front-end module and is not available
in portal by default;
* its naming is not really correct as it is not linked to fields coming
from the website_published mixin and its behavior is not really
the same;
* its use is a bit duplicated with internal flag coming from subtype
allowing to hide messages related to an internal subtype;
* there are overrides of standard mail.message methods just to handle
this flag;
In this commit we change that field by an is_internal flag directly on
mail.message model itself. It tells if share people (customers, share users)
are allowed to read the message. This field can be given through posting
API or set manually using widgets. It is also used in access rights custom
methods and managed like the internal flag of subtypes.
Mailgateway was already using an internal flag for internal note replies. It
is renamed to is_internal and propagated as it is now a standard field. It
also eases code understanding.
Portal is updated to allow managing the flag directly. It means customer portal
now natively allows to moderate customer comments without any need of website
modules.
Rating is updated accordingly. An is_internal field is added, replacing the
related on website published.
LINKS
Task ID 2071556
PR #38692
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
Note that this also add data-oe-model and data-oe-id in XML.
This allow us to avoid to load these links as external URL when
a user receive it in inbox instead of external mail client.
See file addons/mail/static/src/js/thread_widget.js -> _onClickRedirect
Task ID: 1895451
closesodoo/odoo#39958
Related: odoo/enterprise#6414
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Purpose of this commit is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover it
is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed to
be accurate notably when involving super user.
Mail message creation could lead to desynchronized values between author
and email_from. This is improved with this commit by correctly inheriting
from default_get and computing both of them at the same time instead of having
two default values. Indeed they depend on each other.
Same thing is done for mail composer. Mail Thread offers a tool method to
find email_from / author_id based on having one of those values or current
user and it is called whenever necessary.
Some calls to mail template send_mail are also cleaned.
Task ID 1853147
PR #32243
Purpose of this commit is to ease the use of mail.thread tool method
_message_compute_author. Instead of returning a dict with two values and
having to unpack them, directly return a tuple with both author and
email_from values. All calls and return management are the same in mail.
Let us simplify code.
Task ID 1853147
PR #32243
Purpose:
In V13, you can reset to draft a posted move if this move isn't in
a hashed journal. But it's little bit dangerous and we want to
track changes for some fields.
It works for editing in editable list view and form view.
Task ID: 2061399
Raphael Collet