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.
Only system users should be able to access directly ir.ui.view records
Other users should use helper methods like fields_view_get or render
to interact with view records (or use sudo)
Give read access to views to publisher
He needs to call read_template on some views like
'web_editor.colorpicker' in edition mode
Restrict ACL on website.page
Apply the same ACL than on ir.ui.view as the model inherits from it.
Give access to designer to modify views
The following loop crashes on the second iteration:
for record in records:
record.display_name # access non-stored computed field
record.unlink() # delete record
The cache has been invalidated by `unlink` on the first iteration, so
the field is computed. The computation is done on the whole recordset,
which fails with a `MissingError` because of the first record. The fix
is to retry the recomputation on the single record in this case.
closesodoo/odoo#50910
X-original-commit: 7f33ebf528b1415452ce549e3329c3fe89be0ad8
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Cache should be invalidated when updating `arch_db` via `arch`.
closesodoo/odoo#50512
X-original-commit: 1a14ca163ee256eb26661c900227db49426ec3af
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When creating new translations, do not prepopulate the translation
with src.
Take the following scenario:
- set a value in a translatable field in English
- open the translation popup -> creates all ir.translation
- notice an error in English, close the popup
- correct the error in English
- reopen the popup -> existing translations not modified
Add test about reseting
closesodoo/odoo#50147
X-original-commit: 619eccc7a533eedfb3aec0c3740ead1006e0f2f7
Related: odoo/enterprise#10194
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A plaintext email is displayed in a `<pre/>` tag to conserve spacing.
But since there is no escaping, if in this text there was XML tags or
HTML entities, they would appear as HTML in browser which is not wanted.
Do note that this was not a security issue since the content will still
be subjected to the checks and foundling of HTML emails.
Without the change, the added test would fail because character &,<,>
were not escaped.
opw-2242323
closes#50003closesodoo/odoo#50123
X-original-commit: 932532b5b59e0b71c8e16dadfb2ff36c38764208
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* add a `raw` computed field, though only update some of base to use
it (addons for which that makes sense can be migrated progressively)
* avoid working with base64 data when it's possible to work with the
actual data
* improve datas (base64 encoded content): should depend on bin_size
closesodoo/odoo#47212
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Toggle method defined on ir.ui.view does the same job of toggle_active that
is the generic one available on all models.
Task ID 2170708
Community PR odoo/odoo#46563
Rewrite code parsing name (_parse_partner_name) to make it easier to
understand. Tweak find_or_create to return directly a recordset with the
found partner / new partner instead of a name_get result.
Also inherit Partner.find_or_create() in mail in order to benefits from
email_normalized field, allowing to improve the search on matching emails
and avoid duplicates.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
As find_or_create API and code will be slightly improved soon let us add some
tests to ensure behavior and avoid (too much) regressions. Notably about the
fallback on faulty emails support aka "name email@domain)" which in parsing
is considered as valid. This may happen when people copy-paste emails.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
This code adapts all business code instances of calls to
`resolve_2many_commands` and replaces them by calls to `new` which
returns a record-like object whose api is more familiar than the
`resolve_2many_commands` api.
before this commit:
actions are not showing as per the sequence, like:
1) Other actions (delete, duplicate)
2) Windows actions
3) Server actions (without sorting by sequence)
After this commit:
Server actions are sorted by the sequence, like:
1) Other actions (delete, duplicate)
2) Windows actions
3) Server actions (with sorting by sequence)
task-2005419
closesodoo/odoo#39872
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, when a user try to import data with a XLSX file, the
file was mistaken by an SVG file. This issue arises because a XLSX file
from import isn't encoded in base64, and for testing if the file is an
SVG file it will be decoded. base64.b64decode by default (when validate
is False), will remove all characters that are in the base-64 alphabet
from the input prior to decode. So in our case, when the non encoded
XSLX file is force decoded the results starts, unluckily, with '<' and
it's mistaken by an XML/SVG file. Note that, the XSLX file is wrongly
tested because a XSLX file is just a ZIP file, and all the ZIP files
start with PK\x03\x04, and P is the first byte of a base64 encoded XML
file.
Now, only files that were previously encoded into base64 are decoded to
be tested. The validate = True parameter in base64.b64decode will raise
a binascii.Error if there are a non-base64-alphabet characters in the
input, this will allow us to know if the input was or wasn't base64
prior encoded. As base64.b64decode with validate = False, removed the
non-base64-alphabet characters this allows to decode input files
compatible with RFC 2045 (MIME). The files compatible with this standard
will have a newline character (b'\n') after every 76 bytes of the
output, and end with a newline. To keep backwards compatibility, we
remove the newlines and the carriage return from the input before the
decoding.
opw-2194468
closes#36081closes#31849closes#33543closesodoo/odoo#47906
X-original-commit: 65d709c9ab386d646f682c494cfb21cb06ec8034
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
When passing a view
from `active` `False`
to `active` `True`,
its xml wasn't being checked, and it could be very well be invalid.
e.g.
Create a view inheriting from `base.view_partner_form`
`active` set to `False`
`arch` set to
```
<field name="foo" position="after">
<field name="bar"/>
</field>
```
On creation, the `_check_xml` constraint is valid because the view is disabled.
Now, write `active` to `True`. Notice no constraint error is raised while the view is invalid.
This is particularly critical now that we automatically disable invalid custom views
during upgrades. When the user tries to re-enable the view which has been disabled to see
what was wrong, he doesn't get any error because of this.
closesodoo/odoo#47897
X-original-commit: fb2aeb29cd62e02ca5485e5b60d6b61ae4acc252
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In odoo empty html is not always completely empty. This tool method allow
to consider html holding void tags as empty html. This happens notably when
using the editor that may store <p><br><p> even if displayed content is void.
Task ID 2126509
PR #41827
When a user is created, its partner_id shall not have any company_id.
A test has been added to check that in 'base/test'.
Update test_mail tests by setting a company to partner_id linked to users
as now, by default the partner linked to a new user has no company_id.
closes odoo/odoo#46515
Task: 2198688
Forward-port-of: #45900
X-original-commit: 187b12fc5715721efdd9af283e086dfc3f856fc2
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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>
This fixes the following issue. Set the field `arch` on a view; this
automatically writes on `arch_db`, which is a translated field. If some
translations are discarded, a call to `unlink()` invalidates the whole
cache. And then things go wrong: when `arch_db` is validated, the field
`arch` is missing from cache, and the ORM sets it to `None` because the
field is still protected by the initial write!
Fix the issue by avoiding the call to `unlink()`, and do it in SQL
instead.
closesodoo/odoo#45740
X-original-commit: e7679152ee480a51ef2b6d208ae7a05b2ef61941
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Not setting a value for paperformat_id on 'Company Document Layout'
will also make paperformat_id False on the company but it is required
in the settings.
Without this commit, you can get in the weird situation of being able
to set a value on the document layout but having an error in the
general settings as a required field is missing.
Apply the same logic as in the other views
closesodoo/odoo#45527
X-original-commit: e518063e48936a3f8f9f921950cdae209e67ab47
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Allow a naive `group_expand` for manual fields where having the
attribute set to True causes the ORM to include all records from the
relation model of the m2o field in the read_group.
This is particularly useful for custom m2o fields which represent
stages - a grouped list view or a kanban view should include all
possible stage, not only the currently used values.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
Up until now, it was impossible to specify the default ordering
on models created manually.
This could somewhat be bypassed by specifying the ordering of records on
views themselves, but this has one main drawback: when using a
relational field that targets a custom model as a group-by key, the
ordering defaulted to the id of the custom record. For example, if I
create a custom field on partners that points to a custom model
'x_grade' on which an 'x_sequence' field exists, I could order my grade
in their own list view according to their sequence, but any read on
partners grouped by this 'x_grade_id' field would order the returned
groups by id while I would prefer to have them ordered according to the
'x_sequence' field.
This commit introduces a new field 'default_order' on the ir.model model
that can store this default ordering clause (as an SQL expression).
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When we name_search a res.user, we have a special hack so we will
firstly perform an exact search on the res.users login, if none is found
we will search over res.users name.
This is intended but in the case of negative search since 660cebb4faaeb,
for example operator='not ilike' and name='test' would probably just
return all user that do not have a login that is exactly test.
This is not the intended behavior, in this instance we should just
return user that do not have "test" in their names.
Without fix, added test would fail on:
- .name_search('vlad', operator='not ilike') => finding everyone but
user with exactly login vlad instead of user not containing vlad in
their name
- .name_search('', operator='not ilike') => find all users instead of
finding no user
- .name_search('lad', operator='not ilike') => find all users instead of
just finding "Nothing similar"
opw-2170517
closes#44040closesodoo/odoo#44152
X-original-commit: 2378fb63c132c0bcf027785d478c0608b59a3409
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).
Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.
That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.
Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.
Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
print that, it's formatted to show the exception type, message &
traceback
* otherwise format the garbage that is an "ExceptionDetails" object
Some library versions are outdated since the release of Debian Buster.
With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).
Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.
As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.
Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.
closesodoo/odoo#43106
X-original-commit: 32e455bf72980e6330871aa9cd99c26c6e1225d7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This is a changement succeeding 13.0 7eb603b26c, in that commit the issue
was solved but only in the case of en_US base language of translation
which can not be the case on a website.
opw-2153422
closes#42269closesodoo/odoo#42467
X-original-commit: 191075454563c7e15b22d20b21afeb8bcc5601c4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When an attachment is linked to a record (res_id and res_model are set)
we check the access rights and access rules of that record.
The access we check on linked record has changed as follow:
- 15905e78 (2013) => we check `write` access right/rule for `create`
- f5ebc509 (2014) => we check `write` access right for all mode
- 66644e85 (2015) => we check write access right for all but create mode
So currently we check on the linked record for each mode:
- create: write access right / write access rule
- read: read access right / read access rule
- write: write access right / write access rule
- unlink: write access right / unlink access rule
The behavior is not expected for `unlink`, we should check if we have
write access through access rules instead of checking unlink access.
Without the change, the added test failed with a `unlink` access rule
AccessError on the linked record.
opw-2154448
closes#41814closesodoo/odoo#42264
X-original-commit: 2b3fc2e3b80f191b4cd126abccf6f94b1302ac11
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
Ensure that expression.OR and expression.AND and some other
expression.py methods do not propagate or rely on TRUE_DOMAIN and
FALSE_DOMAIN that may be muted on some instance.
For example, if we did:
self.search(expression.OR([]))
then in the search method we do something like:
received_domain.append(('res_field', '=', False))
before this commit, FALSE_DOMAIN would be altered for any succeeding code
that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`.
Without the changeset, the added test would fail with:
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
note: another commit referenced in #41968 should make the TRUE_DOMAIN
and FALSE_DOMAIN immutable.
related to work on opw-2154448
closes#42107closesodoo/odoo#42222
X-original-commit: 303ce32e6ccd7432b96ffae545e4a6eced68ae84
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Company used to get defaults was user.company_id and not current company
in the environment.
Fixes#41679closesodoo/odoo#42153
X-original-commit: af50c694445d49f1098de4236b6e8bdd9b1c93f2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
On the website when you modified a string with not much change, we
modify the translation source so they are not dropped.
But we also do it for an en_US translation, so if we have a translation:
lang=en_US/src=helloworld/value=helloworld
if we change `helloworld` by `helloworld!` the translation would become:
lang=en_US/src=helloworld!/value=helloworld
which would make it seem like the change did not work at all.
Without change, modifed test fail on second:
self.assertEqual(view.with_env(env_us).arch_db, archf % terms_en)
with assertion:
AssertionError: '<form string="X">Bread and cheeze</form>'
!= '<form string="X">Bread and cheese</form>'
opw-2153422
closes#41714closesodoo/odoo#41809
X-original-commit: 7eb603b26cc591b85ceb11210f5db8308d2ba27a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If odoo is started with a log-level of "warn" of higher, the logging
record is not emitted at all and thus the handler added by assertLogs
has nothing to process at all. As a result the test will fail.
closesodoo/odoo#40802
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Instead, updating the translations of a module can be done directly
on the ir.module.module record
Remove one call to _update_translation by the actual creation of the
language
load_lang was a kind of hybrid method trying to active or creating a
language if not found. This was error prone.
Instead rely on two methods with clear purpose:
ResLang._create_lang(lang, lang_name=None)
- create a new res.lang entry using the locale of the server
return the res.lang record to match the API of _activate_lang
ResLang._active_lang(code)
- activate the given code lang
Most of the time, _active_lang is what is expected
tools.trans_load_data and IrTranslation._load_module_terms no longer
activate the language if not active.
Loading the translations should be explicit on an activated language,
it is too error prone to silently activate/create a language if not
found.
Remove lang_name from trans_load_data as no longer needed.
Problem description:
Using the chatter, send an email to someone having non-ascii characters
in their name: the body of the received email looks like it contains
a mix of the original body and headers.
Python encodes the name into either base64 or quoted-printable but
leaves some redundant carriage returns at the end of the header. Those
redundant carriage returns are not RFC conformant but are interpreted
as newlines by some email clients, thus are read like a headers/body
separator and the next headers are considered part of the body,
corrupting the email structure.
This problem is internal to Python and has been fixed in 3.8, cfr
bpo-34424 [1], and later backported to 3.7.4. As we also support 3.6
and earlier 3.7 and it is not possible to easily monkey-patch the
function, we fixed it by squashing duplicate carriage returns.
(There is no case where a series of bare CRs can occur in a normal
RFC5322 email message)
Task: 2003936
[1]: https://bugs.python.org/issue34424
Python 2 `email.tools.formataddr` doesn't encode not RFC-2822 compliant
realname to base64 or quoted-printable. This is the wanted behavior to
output formatted email addresses on screen.
Python 3 `email.tools.formataddr` does encode the realname to be
RFC-2822 compliant. This is the wanted behavior when connecting to a
smtp server to send emails.
That method has been deprecated by pep-594 as the new python email API
is capable of automatically formatting email address in a RFC compliant
way. As the method was still in use in a lot of modules as the
preferred way to format email addresses, a refined P3-like
implementation as been included in the tool suite.
This commit changes the default behavior so it mimics P2 implementation
with an easy way to use the P3 behavior.
Task: 2003936
View creation/edition represent a important part of an install and a lot
of possible view errors are not detected, like fields used in domain
filters. Some part of the code a difficult to maintain, and view checks
are splitted in multiple places.
This commit aims at refactoring view validation by regrouping most part
of the logic in ir_ui_view and trying to optimize the overall process.
Since most of the lines were touched, this task was also an opportunity
to modernize the API.
Main changes on method `check_xml`:
- extract node processign and validation to individual postprocessor
- add validation for filter node, buttons, ...
- fix accessibility checks (and improve their performance)
- move xpath check to specific Python node validator
- clarify error messages (wip to continue)
Main changes on method `read_combined`:
- optimize the search for inheriting views in a single query doing the
whole recursive search
Indeed, after removing xpath validations, `get_inheriting_views_arch`
was the most expensive method in `check_xml`, spending most of the time
in `search` because of recursive calls to retrieve children views.
The view Backend Assets is a good example of the latter point, since a
line is added in the view for almost every module. 70 views (community)
are added at first level, `get_inheriting_views_arch` is efficient and
returns all 70 views. Then at the second level, the method
`get_inheriting_views_arch` is called 70 times for nothing. 70 calls to
`search` (squared/2 since each view is checked independently) are almost
useless. The same case applies to the settings view.
As a result, the average module installation time is 25% faster, and the
average time spent in `read_combined` is almost divided by 2.
Martin Trigaux