Apparently a migration error in
0fd773a486, probably never noticed
because nobody ever tries to copy config objects since there's a
bespoke widget, and it's specifically forbidden.
Also fix the signature of the method itself to match the normal one.
closesodoo/odoo#82711
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since auto-retry, real errors will lead to doubled errors on runbot.
This can be noisy and hard to understand.
This commit will help with this by using a lower log level on the first
execution. Log 25 are kepts.
closesodoo/odoo#80378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add some tests about body alternative done
in build_email when none is given. It uses a library we are about to
remove and testing it is therefore necessary.
Task-2702034
X-original-commit: 92b102c87bbdb9073f794a414a41460e4146acd2
Part-of: odoo/odoo#82486
Before when we do `reserved(records)`, it iterates in a reverse
order of `records`. Unfortunately, the `__reserved__` method don't
exist explicitly in BaseModel then Python fallback on
its own implementation using `__getitem__` and `__len__` (coming from Sequence): https://github.com/python/cpython/blob/3.10/Lib/_collections_abc.py#L1047-L1049
Because it uses __getitem__, it breaks the prefetch of the recordset.
Example:
-------------
```
partners = self.env['res.partner'].browse(1, 2, 3, 4, 5)
for partner in reversed(partners):
partner.name
```
will generate 5 SQL requests to fetch data (one by record)
Then create our own `__reversed__` and handle the prefetch correctly
(like `__iter__`). Now in the example it will correctly generate only
1 SQL request because of the prefetch.
task-2687953
closesodoo/odoo#79622
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
A lot of localization are inheriting reports and changing them.
This should be tested in a generic test like /base.test_reports to avoid
possible tracebacks.
closesodoo/odoo#82312
Related: odoo/enterprise#23299
Signed-off-by: William André (wan) <wan@odoo.com>
closesodoo/odoo#82238
X-original-commit: 5164739b835445fa11b2efc53e2ff839a4bad10a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit: a notification asking to reload the current window
appeared as soon as the server detected a change in one of the assets
bundles, even on first load.
To fix this problem and make the feature more meaningful, it has been
decided to only notify the client when the server version (not the
bundle version) is outdated (i.e. on database upgrades, when the changes
in the code are actually relevant).
closesodoo/odoo#82032
X-original-commit: a3b5a9d715be6a93c7f2859074b916f3249f97c3
Signed-off-by: Antony Lesuisse <al@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Automated action with a many2many field and reference evaluation can be created but don't work
Steps to reproduce:
1. Install Automated Action Rules module and Contacts app
2. Create an automated action for model 'Contact' with trigger 'On Creation' and action 'Update the Record'
3. Add a line to the automated action 'Data to Write' for the field 'Tags (res.partner)' with evaluation type 'Reference'
4. Go to Contacts, create and save a new one
5. An error is raised when trying to execute the automated action
Solution:
Raise an error when a many2many field is of evaluation type 'Reference'
OPW-2673939
(This PR is a duplicate of https://github.com/odoo/odoo/pull/82035 which for some reason couldn't do the forward ports)
closesodoo/odoo#82168
X-original-commit: 8d45823f2dda24c03b427ecbe7003a64b63d01b7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When running test tours logging a message to console.error causes the
test tour to fail. Only one such message can cause the tour to fail, if
other message are written on the console they are simply logged in the
odoo logs. The offending message, however, is only shown at the end of
run, as part of the failing test logs. Arguably, it is better to
include it in the browser logs as well.
closesodoo/odoo#75197
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, if a theme record (eg `theme.ir.ui.view`) was deleted,
its copy_ids would not be.
While this is perfectly normal and wanted behavior when this is done in a
website context (to not alter other websites), it shouldn't be the case when
performing a theme update through CLI/Migration (or if the user find a way to
update the module through the UI).
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
closesodoo/odoo#81953
X-original-commit: 3146dd72e6cb07d6e78ca763325f13dd54de0086
Related: odoo/design-themes#548
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Core client remains incompatible with CSP, however it can't hurt to
CSP the sub-resources.
Current scheme is simplistic, however if useful of necessary it could
be made more flexible e.g. there could be a map of mimetypes to CSP
configuration, that sort of things.
All textual content generated by opening the tag must be flushed before
inserting the default content
closesodoo/odoo#81700
X-original-commit: effeba10787388ee0a3d153c984fab5731fc9b1a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
The creation of recordset was done by class method _browse() instead of
a regular call to the model's class. As we removed the old usage of
method __init__(), we can now reuse it with a normal usage. After this
commit, we can create a recordset by simply calling its class:
registry['model_name'](env, ids, prefetch_ids)
closesodoo/odoo#79563
Signed-off-by: Raphael Collet <rco@odoo.com>
- Remove unused imports `AsIs` and `Collector`
- Remove unused logger _schema
- Remove unused function same_name
- Remove unused attribute `_needaction`
- Remove backward compatibility of `__new__` and `__init__`
- Remove backward compatibility of `__export_rows`
Also:
- remove deprecated warning in api.py
- remove the `__init__` from `ir.ui.menu`, it was useless
because the cleaning of cache (`clear_caches`) is global (a call of
`clear_caches` clean all cache method with a ormcache decoration)
Part-of: odoo/odoo#79563
The method BaseModel.update does not batch records for no reason. This
method is used in `_onchange_eval` and in few onchange in Odoo.
In _modified_triggers() avoid a useless record union.
Part-of: odoo/odoo#79563
The method refresh() is a duplicate of method invalidate_cache() and is
deprecated since version 8.0, but without any warning. Add this warning
to be able to completely remove it in the next major version.
Part-of: odoo/odoo#79563
There is an issue when exporting pdf using edi documents created before
the PDF/A commit. With the subtype now included, the system would try
to use the subtype given by the ir.attachment which would not be formated
as expected by the pdf file format.
The attachment may get neutered by the ORM, so we may have to force
the mimetype when embedding it.
This fix in two parts will allow to force a subtype when adding an
attachment into a pdf, as well as parse the subtype of ir.attachment
to give them the right format.
xxx/xxx should become /xxx#2Fxxx
opw-2714040
closesodoo/odoo#81898
X-original-commit: 880d7a1c8474a3bee4fd05474788fbd4a63f4ae7
Signed-off-by: Laurent Smet <las@odoo.com>
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
When the system broadcasts an email response to document followers,
if the config parameters `mail.force.smtp.from` or
`mail.dynamic.smtp.from` are defined, it will rewrite the `From`
address to avoid spoofing the sender's domain.
**NOTE**: As of 15.0, this is based on the `from_filter` setting on the
corresponding ir.mail_server, rather than the abovementioned config
parameters, but the rest of the discussion stands.
For example, if the `mail.catchall.domain` is set to `example.com` and
an email response comes from:
"John D" <john@doe.com>
it will rewrite it to:
"John D (john@doe.com)" <notifications@example.com>
This will make sure the system never sends outgoing email for an external
domain, as it has no authority for doing so, and that could
break mail filtering/authentication rules (SPF, DMARC, etc.)
During this "encapsulation rewrite step", both the original Sender name
and their email are preserved, and put into the quoted "name" field of
the rewritten address. It seems sensible to preserve as much information
as possible about the original sender.
Unfortunately, the inclusion of the Sender email in the final name makes
it appear to some inbox providers as if the message is trying to
deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in
the UI when it happens. It will keep only the rewritten email, which is not
very useful in the case of a notification (even though it's more
technically correct, of course).
This patch removes the original email from the rewritten notification,
keeping only the name, considering that the email is not the most
important part, and it's better to have one of the two than none.
So after the patch, the rewritten address is now:
"John D" <notifications@example.com>
When there is no name in the original address, we keep only the local
part of the email, to avoid the same display issue. The recipient will
have to identify the sender based on the context / past messages.
closesodoo/odoo#81807
X-original-commit: 3c65ec5a8191a392980ceb0a8c584767eae405f1
Signed-off-by: Olivier Dony <odo@odoo.com>
If a form view contains the field 'display_name', when creating a new
record, the initial value of 'display_name' is the string "False", and
that weird value also appears in the breadcrumb instead of "New". In
order to avoid this unexpected behavior, the conversion of a value to a
display name should be False, like any other field would.
closesodoo/odoo#81788
Signed-off-by: Raphael Collet <rco@odoo.com>
Description of the issue/feature this PR addresses:
duplicate mandatory field in popup when save the contact record.
Current behavior before PR:
Its showing same field name twice in popup which asking invalid fields.
Desired behavior after PR is merged:
it should show 'name' field only once.
Fixes#79753closesodoo/odoo#81727
X-original-commit: eb4b49e7078f4aa90f9d652de10386da38ded2dc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
And make configurable via an ICP. Provide a reasonable default value,
and use it as a lower bound so user error can't lead to an insecure /
unsustainable amount of hashing.
Aside from being somewhat overdue on account of age (passlib's current
default were last updated 6 years ago), this is also made much more
feasible by API keys, meaning non-interactive use (RPC) is less
strained by the (interactive) password hashing.
Also modernize passlib usage:
* Remove global `DEFAULT_CRYPT_CONTEXT`, create inline (as overhead
should not be too huge given what we're doing with it), and
`ormcache()` for safety, the caches should be invalidated on any ICP
addition, removal, or update, so user update to the rounds
configuration should get reflected immediately.
* Switch on `deprecated=["auto"]`, feature was added in 1.6 and we now
depend on 1.7.
* Remove mentions of `encrypt`, it is deprecated in 1.7.
closesodoo/odoo#81498
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Access /base/static/img/country_flags/fr.png, 404 file not found but it
exists.
The conditional was wrong. We should load static files when the addon is
installable OR that it contains assets.
Code before 2e29a93:
expr = not manifest or (
not manifest.get('installable', True)
and 'asset' not in manifest
)
if expr:
continue
...
Code after 2e29a93:
expr = manifest and (manifest['installable'] or manifest['assets']
if not expr:
...
Proof:
a is manifest
b is manifest.get('installable', True)
c is 'asset' in manifest
expr = ~a | (~b & ~c)
~expr = ~(~a | (~b & ~c)
= a & ~(~b & ~c)
= a & (b | c)
Fine-tuning of 2e29a93closesodoo/odoo#81509
Signed-off-by: Raphael Collet <rco@odoo.com>
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
It used to be a tuple.
Cf: 1abe965b59
opw-2681777
closesodoo/odoo#81312
X-original-commit: aa74f51db7bf5a8ad1f4e309b6352df3c31037ec
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
When there are multiple databases on a single server, it is necessary
to be able to set the "from_filter" for the implicit SMTP server
on a per-database basis, to allow 'opt-in' to the automatic wrapping
of email notifications.
When set to e.g. `notifications@example.com`, and a default SMTP
server is defined in the server-wide config or CLI, outgoing emails
will be automatically rewritten to come from this email, unless the
From/Return-Path domains match the `mail.catchall.domain` parameter.
Task-2710632
closesodoo/odoo#81277
X-original-commit: 8b468e1f7a3dfeb2bcfa83bff55c4b5adf6b2212
Signed-off-by: Olivier Dony <odo@odoo.com>
This fixes inconsistencies when dealing with fields that are computed
and inversed by the same methods.
Consider two fields F1, F2 with the same compute and inverse methods.
Consider a record where we wrote on a dependency of the common compute
method. At this point, both fields F1 and F2 are marked to be computed.
Now let us write on F1 only. Here is what happens:
- the write discards the computation of F1, but not F2
- the inverse method of F1 is called:
- the method accesses F2
-> this calls the compute method, which assigns both F1 and F2
- the method accesses F1
-> the value of F1 has been replaced by the computation above
The issue comes from a combination of factors:
- the value of F2 must be determined by the computation;
- the computation assigns both F1 and F2;
- the computation is done while inversing F1 (and F2).
The solution is to force the computation before actually writing on the
fields and calling their inverse methods. Note that this is necessary
only when part of the fields computed by a common method are updated.
When all fields computed by a common method are updated, the computation
will automatically be cancelled.
closesodoo/odoo#81172
X-original-commit: fb4d6ee4ba8bcb5cd8030105ac57e9e02850bfc4
Signed-off-by: Raphael Collet <rco@odoo.com>
Without this index, finding the user(s) of a partner makes a seq scan, which
could take up to 100ms on my machine with only few thousand users. By adding the
index, the time is reduced to around 5ms.
Part of task-2702450
closesodoo/odoo#81176
X-original-commit: 372f1c5ebac4b9b542994ea5aaad59abe7290918
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base_address_city, base_address_extended, bus, crm, im_livechat,
l10n_ae_pos, lunch, pos_restaurant_adyen, test_assetsbundle,
test_converter, test_lint.
It is spelled `auto_install`, the `complexity` key is long gone, `qweb`
has been moved to `assets: {'web.assets_qweb': []}`. `js` and `css` are
long gone too, `maintainer` is redundant with `author` which is
"Odoo S.A." by default already, the `certificate` key is long gone.
closesodoo/odoo#80988
Related: odoo/enterprise#22766
Signed-off-by: Julien Castiaux <juc@odoo.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
This is a bunch of fixes (65 corner cases) for the search on
company-dependent fields:
Without a default value:
- `char` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `(..., '!=', '<string>')` doesn't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `date` and `datetime` fields:
- `(..., '!=', <Date/datetime>)` doesn't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `boolean` fields:
- `(..., '=', False)` and `(..., '!=', True)` don't return records with unset and `False` values
- `integer`/`float` fields:
- `(..., '!=', <number>)` doesn't return records with unset value
With a truthy default value:
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` returns the record with the default value (which isn't `False`)
- `boolean` fields:
- `(..., '=', False)` doesn't return records with unset and `False` value
- `(..., '!=', False)` returns records with unset and `False` value
- `integer`/`float` fields:
- all `(..., operator, value)` which include value 0, return all records with unset value, even if the default value does not satisfy the domain
closesodoo/odoo#80994
X-original-commit: 3e3be652ece83420782070bdb13da2c3a4930046
Signed-off-by: Raphael Collet <rco@odoo.com>
After this commit, the js_transpiler will support exported hoisting
function. So it will be possible to define a hoisting function and
exported in an @odoo-module.
Example of exported hoisting function which wasn't supported before
this commit:
```
hoisted();
export function hoisted() {
...
};
```
closesodoo/odoo#80965
X-original-commit: 40ef9f7aeac8048cce8f002c84181abc64bcbe87
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When Chrome is spawned, the `DevToolsActivePort`file is awaited to read
the port. Sometimes the file is read but is still empty, resulting in a
ValueError when trying to cast into integer. This happens when Chrome
did not have time yet to write into file.
With this commit, we expect the file to contain at least 5 bytes which
is enough to contain the max port number.
closesodoo/odoo#80791
X-original-commit: aab53fbb4e02461e0f23cf202d393e30a73fbc92
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Xavier Morel