Purpose
=======
When an email is opened and is from the default notification mechanism,
i.e: coming from something like "notifications@mail.odoo.com", we don't
want to try to match the email address to an existing contact partner.
Instead, we now display a custom message on the mail addon side
mentioning to search the contact manually.
Task-3557545
closesodoo/odoo#148073
X-original-commit: 9ff0815e258160f0eca595e0c3cce4b005e79eea
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Bug
===
When searching for projects from the Outlook / Gmail addins, the names
were not translated into the user's language.
Task-3486324
closesodoo/odoo#136645
X-original-commit: 7ebe04189c84381e133ad3d0d6f8b97832b28a14
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Purpose
=======
Show an error during the login process if a portal
user tries to use the Outlook / Gmail addin.
Task-3344536
closesodoo/odoo#134450
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
When we enrich a partner we don't have access to, it will try to read
it, but because of the ACL if will crash. To fix that issue, we don't
return the partner if we can't access it and we show an error message
in the UI instead of letting it crash.
Task-3344536
closesodoo/odoo#135025
X-original-commit: a3dcae1eebe7920ae788d5ff6d12c45e19a9628d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
Bug
===
Since 69f911d994 , the body needs to be a
Markup object if we don't want to escape it. So, when we log an email
from the mail plugin, because we just log the string, it gets escaped.
Task-3387100
closesodoo/odoo#128984
X-original-commit: ef068b3b0d7df9f2e064889c62623b34f31e156b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a user is not present in the request, he is in no group at all and
can not access any model, including the one available for public
users.
Avoid ambiguity by using sudo or add a user specifically.
Part-of: odoo/odoo#125216
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
This commit fixes a regression introduced in https://github.com/odoo/odoo/pull/104323.
That fix was preventing the default behavior of the 1st `.oe_login_form button[type=submit]` found.
It turns out that, for allowing the mail plugin to work, you actually need to have the default behavior of that element working normally.
Without this patch, the `&do=1` query is never added to the POST parameters. Thus, the user is unable to authorize their mail plugin.
@moduon MT-2552 MT-2553 OPW-3230686
closesodoo/odoo#115733
X-original-commit: d350b084317057d62a018a86f57a0a26b454100f
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Bug
===
Currently, we try to enrich the domains even if they are in the
`_MAIL_DOMAIN_BLACKLIST`. IAP always return a "missing data" error
because it can't enrich "gmail.com", etc except for "odoo.com". In that
case the enrichment is successful, but because the domain is
blacklisted, we use the entire email to find the company (and so it
will create a company for each odoo.com email addresses).
The test that was removed was wrong. It works because we mocked the
enrichment response, but in practice it will always return a missing
data error.
Task-3050230
closesodoo/odoo#107235
X-original-commit: 37503108cd878412474b5486877a861dad2efc1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose
=======
Hide the "Create Partner" button if we do not have the "create" access
right.
Do not offer to create a project if the current user can't.
Do not try to enrich if we can't create a partner.
The write access on the partner is checked on the record itself because
of access rules.
Task-2826471
X-original-commit: b678a9bc1298e9a1973074740a8c8a1d471b6848
Part-of: odoo/odoo#93058
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
When you do not have IAP credit, if the partner and the company
do not exist in the Odoo database, you have an empty section.
Now, a message tell you that you need to save the partner to
generate the company (so the section is not empty anymore).
Add the translation for this text.
Task-2601837
X-original-commit: 2951b41ba639fbe6e1bec9ef53ca300369ad5a74
Part-of: odoo/odoo#89848
Bug
===
When we log in with the addin, it will fetch the route `/mail_plugin/auth/access_token`
to know if the module is installed. Because we give no `auth_code` an
error is displayed in the console.
Task-2601837
X-original-commit: 26944c09de32512a8072e00ac73a90c633eecb6c
Part-of: odoo/odoo#89848
Bug
===
1. Open an email in Outlook, and create the contact
2. Go to Odoo and remove the partner
3. Without refreshing the browser tab, click on the "reload" icon of
the addin. A traceback will be raised on the Odoo side
Task-2601837
X-original-commit: bb2e5ce9cf149a5cfd68cf908184c823f882d97d
Part-of: odoo/odoo#89848
Purpose
=======
Improve the error message when the email
of the contact / company is not valid.
Task-2601837
closesodoo/odoo#86080
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Allow to re-use the method `mock_auth_method` used to mock the Outlook
authentication, to be able to write tests in other sub-modules.
Task-2782150
X-original-commit: 6932f05bfc4b2beabaf7c6390f1d241fff73bd38
Part-of: odoo/odoo#89260
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Purpose
=======
Fix missing translations on the Outlook / Gmail plugin and add them in
the mail plugin module.
Task-2612788
closesodoo/odoo#75599
X-original-commit: 47c9be8970011863e8e7b474665c823e751df085
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Currently the application will display a 404 error message, if the mail
plugin module is not installed or if the user made an error in the URL
of his Odoo database, which is confusing for end users.
So, we show an error message during the authentication process if the
database is not reachable and we should add the translations related to
those changes.
Task-2577531
See odoo/mail-client-extensions/pull/17
closesodoo/odoo#75637
X-original-commit: 3c00fddb99091b96259eed1e45ef9de53c53f795
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Fix missing translations on the Outlook plugin and add them in the
mail plugin module.
Task-2612788
closesodoo/odoo#74399
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Odoo Translation Bot