Introduces a hierarchical structure of some menus. Reasons:
1. Allows testing the child-parent relation of specifically those menus
that do not have `parent` or `parent_id` attribute in the source xml
using standard menus. It's likely a rare use case, but that's precisely
what we currently need in https://github.com/odoo/upgrade/pull/5163
2. Provides a unique example usage of menus written in this manner
as opposed to using the `parent` attribute
closesodoo/odoo#136069
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The mail server mostly doesn't use the intrinsic features of
`PyOpenSSLContext`, instead it pretty much just uses the underlying
`OpenSSL.SSL.Context`, just through the wrapper.
The only thing it actually uses from `PyOpenSSLContext` is
`load_cert_chain`, and since we are using a keyfile and are not using
a password this is equivalent to *two* function calls. Just perform
those two calls directly, remove all the indirections, and remove the
unnecessary import.
Bonus content: since 2.0 `load_cert_chain` reraises the inner errors
as `ssl.SSLError` which we don't handle, so we avoid this extra issue.
This was discovered because from 2.0.0 to 2.0.4 the
`contrib.pyopenssl` module was marked as deprecated (it was
undeprecated in 2.0.5) but regardless its use is an unnecessary
complication here.
closesodoo/odoo#137198
X-original-commit: e534bbed78a80d1ba0c8edd22e039e5cfb50e613
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Add a computed m2m field giving allowed models for the action. It allows to
avoid choosing the wrong models when designing server actions.
Remove a test that has no use: it checks a model_id field is available on
server action view while we don't want to display it as it is imposed by
the rule itself.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Fix name compute method:
* correctly call super in batch;
* correctly filter records;
* remove dependency on context key (which was missing in triggers);
In this commit we also consider the name update should always be done even
outside of automated rules context. Having a whole compute method relying
on a context key does not makes sense. As server actions are technical
records, having the name always being correctly updated is better.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Babel's named / implicit formats (short, medium, long, ...) come from
the CLDR, which can get tuned as debates get settled, cultures shift,
etc... as a result using these formats can break tests on any babel or
even CLDR release (technically nothing stops distros from updating
their bundled babel with new CLDR data).
b77eb98bbf6bc937efb7941802c0794ae3622094 previously did some
mitigation of this issue, but even if they're not yet in distros
further Babel updates (e.g. 2.12) already affect some of the patterns
we're using.
Proactively mitigate this issue more by only using explicit datetime
patterns (and time patterns, date is fine because it retrieves the
pattern from the lang rather than default to babel patterns) in the
date/time formatting tests. This means only specific terms still vary,
and those should be a lot more stable / reliable than e.g. futzing
with separators and minor formatting issues.
closesodoo/odoo#137181
X-original-commit: 3547e980428cc1dd11c8e82446e7d7f824b9f6f8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
__Current behavior before commit:__
The page crashes when we try to merge two partners and the
`mail.activity.mixin` model has a field with `ttype = "reference"`.
This is because a `search()` on a `mixin` model will always crash as
they are abstract class that don't represent real records.
__Description of the fix:__
Add a check to skip the iteration if `Model` is an abstract class (like
a mixin).
__To reproduce:__
1. Go to Settings > Technical > Fields
1. Create a new field
1. Set **Model** as `Activity Mixin`
1. Set **Field Type** as `reference`
1. Go to the Contacts app
1. Select two contacts
1. Click on Action > Merge > MERGE CONTACTS
opw-3458640
closesodoo/odoo#136880
X-original-commit: cb7589cb4bb3ede1b4c4d3f8d04c376a95d42247
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Since [1] qweb library is not used anymore, rendering this test useless.
1 : 4b0a951af6closesodoo/odoo#136610
Signed-off-by: Raphael Collet <rco@odoo.com>
The 'like'/'ilike' operators automatically add the wildcard character
(`%`) at the beginning and at the end of the value. This commit fixes
the incorrect usage.
closesodoo/odoo#136007
Related: odoo/enterprise#47886
Signed-off-by: Raphael Collet <rco@odoo.com>
The `=like`/`like` domain operators are accent-insensitive, but still
case-sensitive. This is not really coherent, since `unaccent` is a best
effort to find records from the client, and it is the same idea behind
being case-insensitive. Also, `=like`/`like` cannot be used from the web
client, and we use them in domain to search from the Python side.
Moreover, adding `unaccent` to `=like` can be very inefficient when
searching for a prefix ('prefix%'). In fact, PostgreSQL can use btree
index to find prefix matches, but because we create dy default btree
index without unaccent (when we put
`index=True/'btree'/'btree_not_null'` on the field), PostgreSQL cannot
use this index.
Part-of: odoo/odoo#136007
We introduce a new class of objects to wrap SQL code together with its
parameters. It is designed to be easily composable and to discourage
SQL injections. Its API is similar to the methods of module 'logging':
the code is a format string, and the positional parameters are meant to
be merged into it using the string formatting operator.
# default and increment are parameters of the SQL code in first argument
term = SQL("COALESCE(value, %s) + %s", default, increment)
# term can safely be injected into another SQL, besides regular parameters
query = SQL("SELECT %s FROM mytable WHERE id = %s", term, id_)
The SQL wrapper can return the final SQL code string as query.code, and
the corresponding parameters as query.params (list). The cursor method
execute() can now take an SQL object, and execute it just like
cr.execute(query.code, query.params)
It is quite easy to make SQL objects safe against SQL injections: if the
code is a string literal, then the SQL object is guaranteed safe,
provided the SQL objects within its parameters are themselves safe.
Part-of: odoo/odoo#134677
Purpose
=======
When a user tries to reach a course, an AccessError can occur when we
unslug the URL. Instead of the traditional error page, we want to
redirect the users to /slides, and the error will be displayed there.
Task-3477630
closesodoo/odoo#135926
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
Traceback when trying to create
a new external identifier
Steps to reproduce:
1. Activate the developer mode
2. Go to settings
3. Technical > External Identifiers
4. Click on "New"
5. Traceback
Cause of the issue:
Introduced by https://github.com/odoo/odoo/commit/3c62ca1eb96d571b2b686b5caee370324c589ab4
When computing display_name, the model
can be false, and not be in self.env
opw-3489581
closesodoo/odoo#136279
X-original-commit: 2462df26977acc9e3ccafd57863703aacd2f059e
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Rémy Voet <ryv@odoo.com>
Up until this commit, which view was displayed by default on mobile was
somewhat of a lottery.
Initially, only kanban views were considered as 'more adapted to mobile
devices' and used as a main fallback to display records who had a kanban
view in the window action definition.
The the concept of 'mobile-friendly view' was extended to map and grid
so that these views could take precedence over the kanban view in
specific circumstances (indsutry_fsm and timesheet_grid, both of which
are enterprise edition apps) - basically they were marked as
mobile-friendly not because they *are*, but because it was the only way
to override the kanban override.
But this comes with its lot of problems and limitations, namely that the
mobile friendly view will be found based on the order of view modes for
a window action, so if you have a window action with the view modes
`kanban,map,tree,form`, you will never be able to have e.g. the kanban
view shown on desktop by default and the map view on mobile.
This commit introduces the notion of a 'default mobile view' on window
actions so that one may decide on an *arbitrary* view mode to use on
mobile for an action - without impacting the ordering of views on other
models, etc.
Task-3460374
closesodoo/odoo#133608
Related: odoo/enterprise#46562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
Intent of checking `group_no_one` was always to query the advanced
info / debug mode, however when the semantics of group_no_one got
changed in 31518bc09b this site was
missed, and now always displays "advanced" errors for internal
users. Which was not the intent.
Also since we're printing `display_name` and some of them annoyingly
hook onto context variables to show extended information, reset the
context to the user's default in order to avoid such
extended-formatting `display_name`.
Also fix "debug mode" in `TestIRRuleFeedback`, which has been broken
since time immemorial (likely as long as the group_no_one semantics
changed).
closesodoo/odoo#135940
X-original-commit: 9d3ffa6540c07e97b7160167756edd8e71f2308a
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before es_MX was informally considered as the "reference spanish" as
we have an office in Mexico.
Create a new language that will be used by all the local variations of
Spanish and that we can push without overlapping with es_ES content.
Part-of: odoo/odoo#134785
The fr_CH date format has been broken for years, with unnecessary spaces
after the period. This has been removed.
The de_CH thousands separator prematurely ends after the millions
because it does not loop indefinitely. This has been fixed as well.
closesodoo/odoo#135355
X-original-commit: 287a03224c9144bb547d2cf7cdc046b83b830a16
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
psycopg2.extras.execute_values was introduced in PR #101237
however it pypasses the override logic for cr.execute. As a result
1. --log-sql cannot log these queries
2. assertQueryCount cannot notice these queries
...
This commit create a new api cr.execute_values to support the same SQL feature
without losing the override logic for cr.execute
closesodoo/odoo#131190
Related: odoo/enterprise#47374
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Create a vendor bill with a specific attachment (on ticket)
Go to vendor bill list view
Select the created bill and another one
Print > Original Bills
Traceback due to unhandled ValueError on pdf read
opw-3498898
closesodoo/odoo#135320
X-original-commit: adf4c91f3f696ee849577e345d40e24d59d452f4
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This commit adds `target=download`, as `target=self` adds some unwanted
visual effect. In other words, the "block UI" is never unblocked when
some actions are triggered. This is specific for "Download" actions as
the download is correctly executed, but the page is never `unload`.
e.g.:
```python
action = {
'type': 'ir.actions.act_url',
'url': '/web_enterprise/partner/%d/vcard' % record.id,
'target': 'self',
}
```
Note:
We can't use "'target': 'new'" as it creates a bug in Mobile Apps.
When The Mobile Apps create a new "Tab/Page", they do it in a new
sandboxed browsing environment, so the user isn't logged in and the
resource isn't accessible anymore.
Task ID: 3435131
closesodoo/odoo#134436
X-original-commit: 08db3deb3336f0c1ff9fe2703ebeb8ea5b5aeb3d
Related: odoo/documentation#5822
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit:
translations updated by `update_field_translation` api cannot be detected by
t-cache and some cached data whose model overrides `write` with an extra
'clear_caches()'
Step to reproduce:
- Create a mega menu, select any template, `Odoo Menu` for the example
- Install another language on the website
- Go to the translated version of your website and enter translate mode
- Change "Camera" in the mega menu to something else
- Save
The change won't be replicated, looking like it did nothing.
From there, removing or adding `edit_translations=1` in the URL will
use different cache version of the page's views and you will see the
outdated value on one and the correct on the other one.
after this commit:
`update_field_translation` will call `write`
it does the following 4 important things
1. mark field as modified
2. execute logics in the override `write` method
3. update write_date if needed to support t-cache
opw-3305117
X-original-commit: 2beb466668e4eb80d7c3ca3947445fb1cb141cff
Part-of: odoo/odoo#135277
When creating a new company, SUPERUSER_ID is not added in `user_ids`.
Therefore, when installing a new module, the newly created company
is not in `self.env.companies`, which leads to an issue when
computing `company_id`.
Steps:
- Install Accounting module
- Create a new company with any localisation
- Delete the tax closing entry
- Try to install `stock_account` module
-> Error: `_check_company` failed
With this commit we add the company newly created to
the superuser's `company_ids`
opw-3488788
closesodoo/odoo#135276
X-original-commit: 771fdaf25eefdc30443e96b03b029346bebb50be
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This commit reworks a little bit the backend assets to remove a
bundle and thus save a call at webclient startup. The bundle
"assets_backend_prod_only" existed only to allow to add files in
production, but not in the tests (typically, the file that spawns
the webclient).
This commit introduces a new bundle "web.assets_web" that contains
"assets_backend" and the few files that we only want in production.
In the /web page, we now load "assets_web" instead of
"assets_backend" and "assets_backend_prod_only". In the /web/tests
page, we keep loading "assets_backend", which is now directly
included into "web.tests_assets".
For the sake of consistency, this commit also renames the dark
mode bundle "dark_mode_assets_backend" into "assets_web_dark".
closesodoo/odoo#135204
Related: odoo/enterprise#47316
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
before this commit, the uninstall and upgrade option is not
shown in the kanban.
introduced in: https://github.com/odoo/odoo/commit/5b68871097df5e7a13966dee4c650d1f34f9e7c1
* open apps kanban
* click on kanban menu(3 dots) of installed app
* upgrade and uninstall button is not shown
after this commit, the upgrade and uninstall button will be
shown in the apps kanban menu depending on the state of
the app
closesodoo/odoo#135132
X-original-commit: 90184ff280b4225522797528af51a32591eb5347
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
For model_terms translated fields if a translation for a lang(fr_FR) has never
been defined
before this commit
when update translations for both en_US and fr_FR, the new translation for fr_FR
cannot be saved.
after this commit
new translations can be correctly saved when en_US and fr_FR are updated at the
same time.
closesodoo/odoo#135103
X-original-commit: ef4b195eeac178a14eb47f4e6cc61ddc97f78866
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
before this commit, in the import translation
wizard, if user try to import a file
currently it will show any file types to
upload even though supported formats are
csv and po
after this commit, if user try to import a
file only csv and po files will be shown
closesodoo/odoo#128807
Signed-off-by: Raphael Collet <rco@odoo.com>
Description of the issue/feature this PR addresses:
Prior to this, when multiple currencies with the same symbol where to appear
in a same document or be sent from a country to another with the same currency
symbol, the only information the recipient had was
the currency symbol leading to lack of clarity.
Desired behavior after PR is merged:
This set of two PR has for objective to give the user the possibility to edit
the symbol curency that is displayed everywhere so that if he feels like the
documents and views are lacking clarity, he can improve it.
This was already an option before but only when the debug mode was active.
This commit has the purpose of moving the currency symbol option out of the debug mode section and put it in the right column of the currency form view.
Adding this, the "Symbol" option is moved out of the debug mode.
task-3484335
closesodoo/odoo#133554
Related: odoo/enterprise#46527
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
With input 'name email@domain.com' (missing chevrons allowing to clearly spot
the email part) 'getaddresses' returns ('', 'name email@domain.com) i.e. the
whole input is considered as being the email.
To improve the heuristic we can add a fallback by recalling 'getadresses'
on the input with spaces replaced by commas when it found only an email and
no name. The new email will be split into sub pairs allowing to find the real
email and various name parts, allowing to make a new name / email pair.
Emails should not contain spaces thus this is coherent with email formation.
This fallback actually comes from a specific code done in '_parse_partner_name'
of Partner model. Supporting it directly at tools level make the behavior
coherent for all models.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@18c71edf59
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
As of rfc5322 section 3.4.1 local-part is case-sensitive. However most main
providers do consider the local-part as case insensitive. With the introduction
of smtp-utf8 within odoo, this assumption is certain to fall short for
international emails. We now consider that
* if local part is ascii: normalize still 'lower' ;
* else: use as it, SMTP-UF8 is made for non-ascii local parts;
Concerning domain part of the address, as of v14 international domain (IDNA)
are handled fine. The domain is always lowercase, lowering it is fine as it
is probably an error. With the introduction of IDNA, there is an encoding
that allow non-ascii characters to be encoded to ascii ones, using 'idna.encode'.
Also remove usage of 'email_re' in mailing email check. It is too restrictive
compared to real formatting we support (or try to). Valid outgoing emails
were directly canceled, notably when containing unicode.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@3ce5fb3072
Part-of: odoo/odoo#134934
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
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When having multi-emails input in an email field, 'email_normalized' field is
currently 'False', as they expect the field to contain a single email. This
has several drawbacks
* searching partners or fetching information based on emails does not work as
most tool methods use 'email_normalized' which is False (see e.g.
'_message_partner_info_from_emails', '_mail_find_partner_from_emails'
or 'find_or_create');
* blacklist is not available as it is based on 'email_normalized';
* mass_mailing wrongly considers those emails as invalid and cancel their
mail and related trace, as it tries to skip sending emails to invalid
emails;
Be more defensive and use first found email in case of multi-emails field.
Other emails are ignored. It is already an improvement that does not break
flows in stable and allow more emails to be sent.
before
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: False
after
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: raoul1@raoul.fr
A side effect is that it helps finding back some partners, as indicated in
tests where less phantom partners are created. It also helps suggested
partners / emails flow in discuss.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@90218186c5
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
Move tests currently in mail about helpers defined in 'tools/mail.py' directly
into base. No need to test it in mail, there is no specific override or
behavior change compared to base.
Regroup partner related tests in base into 'test_res_partner'. This breaks
part of test history but it helps knowing which features are tested.
Task-2612945 (Mail: Defensive email formatting)
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
RATIONALE
Add tests related to not standard usage of email field. Two main use cases
are tested here
* formatted emails: `"Full Name" <email@domain.com>` stored into the 'email'
field;
* multi emails: `email1@domain.com, email2@domain.com` stored into a single
'email' field;
Additional tests: tests with unicode / ascii / case / wrong formatting are also
added to check the support in normalize and format methods.
IMPLICATION
Email field is generally managed as "containing a valid email". This means
it is sometimes used as it in 'formataddr' as well as to perform searches or
identification checks. Example of issue: partner 'Raoul' has a formatted email
like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to
from: "Raoul" <"Raoul" <raoul@raoul.fr>>
-> which is incorrect (but often dynamically corrected by email servers);
Email field holding multi-emails are not normalized, as current normalize
is done only if the field holds a single email. It means
* no easy finding based on 'email_normalized', e.g. various tools like
'_mail_find_partner_from_emails' or 'find_or_create' do not find partners
based on this email;
* no exclusion list management;
* issue with formatting, like
to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr>
-> which is incorrect (but often dynamically corrected by email servers);
USAGE: OUTGOING EMAILS
Those use cases currently generate faulty outgoing emails. This is valid for
recipients ('email_cc', 'email_to') as well as author ('email_from').
For formatted emails: `email_to` is formatted again based on name and email
which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`.
Note that multi emails without formatting may work as it leads to email_to
`"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email
servers correctly send multiple emails. It depends on their fault
tolerance.
USAGE: FIND BASED ON EMAIL (NORMALIZED)
When searching for partners (e.g. using '_mail_find_partner_from_emails' or
'find_or_create') normalized version of input is used.
In case of multi emails sanitize is 'False', as normalization expects a single
email in the field. Therefore no partner is found. In processes that do a
"search or create" (e.g. using a template on a record) this leads to creating
a new partner (or several partners in case of multi emails) each time.
USAGE: OTHER FLOWS
Other flows are build on top of '_mail_find_partner_from_emails' / 'create'
of outgoing emails and are impacted by formatted email / multi email usage.
Those include notably
* mass_mailing: '_message_get_default_recipients' should be defensive to
give correct values when creating mailing emails;
* mass_mailing: faulty emails is based on normalize and multi-emails are
considered as faulty and ignored;
* after post hook: '_message_post_after_hook' tries to link messages without
author (but email_from) with newly-created partners, when partners are
created from chatter. It is therefore impacted by those corner cases;
* marketing_automation: built on top of mass_mailing and suffers from the
same issues;
USAGE: UNICODE
Unicode in emails should be supported. 'formataddr' and IrMailServer notably
received fixes to support unicode. Some check performed on email addresses
fail when unicode is involved, which leads to some emails not being sent
while they could.
SPECIFICATIONS
Add tests related to those corner cases. Also add tests for computation of
`email_formatted` field of Partner model. It currently generates wrong email
values for the same corner cases (multi emails, formatted emails).
Tests are also added for the computation of `email_normalized` field used
notably for blacklists. It is not computed currently when being in multi
email mode which prevents from any blacklist mechanism as well as make
email finding harder. `_mail_find_partner_from_emails` tool method is also
tested with multi email as it uses the same heuristic as normalized email
field.
Tests are also added for mass mailing, when having to mail documents that
have a partner with formatted emails / multi-emails, or that have an email
field with formatted emails / multi-emails.
Also restore a test removed at odoo/odoo@afcb734908 while it should have been
updated to state that email addresses containing non-ascii characters are
supported.
Add some tests for tools methods used in various email processing flows.
Unicode tests are also added.
In future commits we will try to make email usage a bit more defensive to
try to lessen issues with that kind of use cases.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@fc8442f133
Part-of: odoo/odoo#134934
Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.
In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1e6d50a141
Part-of: odoo/odoo#134934
The breakpoint() builtin was added in [Python 3.7] ([PEP 553]). It is
conveniently everything-agnostic, can be configured (including
disabled) via an envvar (`PYTHONBREAKPOINT`) and
code (`sys.breakpointhook`), and defaults to pdb (`pdb.set_trace`).
This is more flexible as it allows using arbitrary callables without
special casing, which mostly allows using less common
debuggers (e.g. IDE debug servers / hooks).
As using an empty string for the debugger name was not allowed
previously, co-opt that to invoke `breakpoint`. And deprecate the old
style.
[Python 3.7]: https://docs.python.org/3/whatsnew/3.7.html#pep-553-built-in-breakpoint
[PEP 553]: https://peps.python.org/pep-0553/closesodoo/odoo#134842
Related: odoo/documentation#5800
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Rationale:
- allow mass changing languages (in case you want to remove one lang)
- allow quick company re-assign
Other fields are marked as readonly to avoid messes.
Task-3494874
closesodoo/odoo#134786
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Server actions that 'update the record' have a mechanism to allow users
to easily select a selection value if the field they want to update is a
selection field (instead of having to type the technical value
directly).
Before this commit, this mechanism incorrectly stored the selection's
name instead of the value (e.g. 'Done' instead of '01_done'), making the
write crash when the action was run.
closesodoo/odoo#134625
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In this commit, the loadXML function has been removed. We use registry with
xml_templates to load XML templates for OWL Apps.
The goal of task is to remove loadXML and getBundle from assets to simplify
the understanding of assets api.
task-3266441
closesodoo/odoo#134520
Related: odoo/enterprise#47001
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Carmen Bianca BAKKER