before this commit, code in files for Odoo core which are outside of
root_path/addons/
e.g. odoo/models.py, odoo/service/model.py
cannot be translated. Because the translation tool thinks they don't
belong to any module
after this commit, by reusing the same logic while exporting these code
translations,
they will be translated by using po files of the 'base' module
closesodoo/odoo#116602
X-original-commit: e29aca207e95725d4072fe2a6dfc928128c1e47b
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
in the commit 763fbb1c of #101115
an assert is added for translated sized char fields
It is too strict for some legacy customized fields, we decide to remove it
closesodoo/odoo#116538
X-original-commit: 44f09e927d0f9338a42a3f121377db00cc70f714
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Main Flow Tour Mobile shouldn't require a specific `user_agent` as it
targets a small screen and not a mobile platform (iOS, Android...).
Actually, during refactoring of the tours (odoo/odoo@3a798039d6),
a confusion was made between the legacy `isMobile`, which represents a
small screen (cf. `env.isSmall`) and `isMobileOS`, which targets
"mobile" platforms (ie. iOS, Android...) independently of the screen size.
This commit applies the proper condition (isSmall) for the tours
management and removes the useless `user_agent` property. It also
removes the logic added to support custom user_agent in the Chrome
automation for testing.
closesodoo/odoo#116186
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
is_transpiled is only needed when generating a asset bundle while
JavascriptAsset can be generated to compute the version hash.
is_transpiled needs to read the content to be defined which is quite
slow. Transforming is_transpiled into a lazy property will speedup the
cold loading of generate_assets_node, especially when attachment already
exists.
Locally:
- /web with all modules in debug=assets goes from ~350 to ~150 ms
- generate_assets_nodes part goes from ~230 to ~55 ms
closesodoo/odoo#116123
X-original-commit: 47b44e1ae61583a881bb2ede06cc02f4b9423cbc
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)
1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.
Bug:
The VAT of C = VAT of A, however VAT of D did not change.
When syncing the commercial fields of a partner, we also sync his childs.
PS: Due to function _compute_commercial_partner, the commercial partner is always updated for
all the childs.
So the condition child.commercial_partner_id != self.commercial_partner_id
is never satisfied in function _children_sync and the commercial fields were
never updated.
opw:3111493
closesodoo/odoo#115932
X-original-commit: df87448f2a39eead079cffea566cd760a8918542
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: kmagusiak <>
Bug
===
When the from_filter of an outgoing mail server contains a domain
(e.g. company.com), and when the system parameter "mail.default.from"
is a full email address, with a different domain name
(e.g. notification@example.com) we concatenate both value which produce
an invalid email (e.g. notification@example.com@company.com).
Instead, we always give the priority to the from_filter, and fallback
on "noreply" for the local part when needed.
Task-3230917
closesodoo/odoo#115890
X-original-commit: bf02481de9932de2e0246ac36fcf59f37a89b511
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.
How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice
Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.
closesodoo/odoo#115444
Task: 2852452
X-original-commit: 09cb57446d99a48651cbfeeb5405029bc2d77226
Related: odoo/enterprise#38255
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a company is created during the odoo installation, depending on the installation parameters, importing "res_company_data.xml" before "res_currency_data.xml" can prevent the activation of the company currency.
E.g. a fresh odoo install with account_accountant and no demo data will have 0 active currencies.
X-original-commit: f9247a276b71e9d09bb03c85dc93b36c53703e60
Part-of: odoo/odoo#115444
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
When upgrading a database with `l10n_multilang` installed, the
translations kept were not the right ones.
Here is the process that was executed during the upgrade:
* `base` is loaded: registry is loaded with `translate=True`, which
calls `convert_column_translatable`. This has the effect of setting
the value of the field to `{'en_US': name}`, with only that language
installed.
* `l10n_multilang` is loaded: the function `lang_install` is extended to
copy the translations of the templates on the instanciated records.
* `l10n_*` is loaded: the translation values are loaded from the `.po`
files. `lang_install` is called after the loading on the templates,
copying the value on the records. The value on the records is now
something like `{'en_US': name, 'fr_BE': nom, 'nl_BE': naam}`.
* `base/end-migrate` is executed: it copies the values coming from
`ir_translation`, without overriding the values that are already on
the record because of the order of the `||` operator.
This means that any value inputed by the user[^1] will be overriden by
the value in the `.po` files.
opw-3175383
closesodoo/odoo#115254
X-original-commit: 5d46cdee878d752b9a61a74762a8710be0890e9d
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: HydrionBurst <cwg@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With the special support for postmortem debugging removed, the
likelihood of needing / wanting the werkzeug remote debugger seems
even more remote (as it works in strictly less situations, only for
frontend non-json requests).
So remove that as well.
closesodoo/odoo#115176
X-original-commit: a2022783b652299155c460294c00dbced9b619ac
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It's done nothing since #78857 and it doesn't seem like anyone has
cared (found no issues or tickets).
Rather than restore the feature, just remove the leftover bits.
X-original-commit: 4a7cfc8844eb9b754f16f9d013452d5bde8770b5
Part-of: odoo/odoo#115176
Chrome 111 enabled checking of websocket origin: if the WS connection
sends an Origin head which is not whitelisted with the new
`--remote-allow-origins` switch it is rejected.
Turns out websocket-client (amongst others) *does* send an `Origin`,
which trips the check, and means tours immediately break when trying
to run them as Odoo's test harness is unable to connect to (and
control) the devtools.
Suppress sending `Origin` to fix the issue.
To make the watch mode work, set `--remote-allow-origins`: since we
specifically only bind the devtools to the loopback
address (127.0.0.1) whatever issues this plugs are unlikely to affect
us. We might eventually want to change the behaviour of the watch
feature for UX reasons and remove this in the future though, either by
working through the non-ws remote inspection (`chrome://inspect`) or
by having the `watch` mode run in a normal browser directly instead of
having a browser connect to a headless browser.
Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39
Chrome tracker issue: https://crbug.com/1422444closesodoo/odoo#115067
X-original-commit: 47a02b3924c3e4d1690e336fdd764383393ee378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This could prevent the user deletion if linked to a record of this
type, like a auth_totp.device which inherits from this model.
Part-of: odoo/odoo#114656
Purpose
=======
Improve the portal user deletion by preventing timeouts and
avoiding several rollbacks causes.
Specifications
==============
- Move the portal users deletions from autovacuum to its own cron.
On big databases such as odoo.com, deleting a res.users takes
more than 1 minute. Move the whole process into its own scheduled
tasks.
- Commit the deletion at each user. As said previously the deletion
can be expensive, so commit what has been done to avoid having to
delete the same user again in case of rollbacks or timeout.
- Delete the user and the partner separately. If the partner is used
in a sales order for instance, the unlink is possible for the user
and not the parner. It allows to unlink the user and keep the
partner in case it cannot be deleted.
- Re-call the cron into another transaction in case there are too many
users to delete, instead of waiting next call, that is supposed
to occur the day after.
Taskid: 3222941
Part-of: odoo/odoo#114656
When computing flag_image_url field on res.lang model an invalid url is generated due to the peculiar format for serbian lang code sr@latin which has "@" sign instead of expected "_" sign and thus the unexisting url is computed, so we are forced to populate binary field flag_image instead.
X-original-commit: 85db3773ba475a143a99126c6c24b404bdd39d0b
Part-of: odoo/odoo#114565
During revision 415525cecc
the code comparing the connections without password has been
dropped, for an unknown reason.
Because of the above, and the fact psycopg2 alter the password
with 'xxx' for security reasons, the connections recycling was
no longer working as expected, and was recycling less connections.
closesodoo/odoo#37005
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue: when use t-if to display text and use mutli line, the white-space
are removed.
```
<div>
<t t-out="nb"/>
<t t-if="nb == 0 or nb == 1">product</t>
<t t-else="">products</t>
</div>
```
is rendered:
```
<div>
3products
</div>
```
closesodoo/odoo#114986
X-original-commit: 3150a3769ff4d762c0e52dab31a70b59292c1bcc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
When we create a new record X and its values contains an one2many field
with either a recordset Y or a Command.set(ids), the ORM generates extra
SQL queries to search and remove the existing lines of the new record.
The call chain is as follows:
Model._create
-> _RelationalMulti.create
-> _RelationalMulti.write_batch
-> One2many.write_real
But because record X is brand new, it has no lines to begin with. The
fix consists in skipping the search and removal in that case.
Also remove any nondeterministic behavior of method write_real() using
an OrderedSet instead of a builtin set.
closesodoo/odoo#114726
X-original-commit: 428827e5213ee002a5b50d864f8ce1f24d1842b3
Signed-off-by: Raphael Collet <rco@odoo.com>
Before commit:
There was no mobile field in the optional fields of tree view in res.partner.
After commit:
Added the mobile field as optional field.
Task-3184771
closesodoo/odoo#113243
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The TriggerTree class does not have a specific __repr__(). It thus
falls back on dict's __repr__(), which does not show the root of the
tree. This makes debugging hard and confusing.
closesodoo/odoo#113521
Signed-off-by: Raphael Collet <rco@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Because Werkzeug supports ipv6 natively (and has since ~2010
pallets/werkzeug@13a76262a4), running
Odoo in threaded mode allows binding to an ipv6 address.
However the prefork server is part of Odoo, and only creates
AF_INET (ipv4) sockets. Thus switching from threaded to worker mode
breaks the bind.
Add a family switch on the `http-interface`, so binding to ipv6
addresses also works in ipv6. Gevent already does that switching
internally, so the evented worker works out of the box, it was only
the prefork / workers which did not.
Looking at both the Werkzeug and Gevent implementations:
- https://github.com/pallets/werkzeug/blob/f9906fa6d83dd668f9214acef458419756bbc062/src/werkzeug/serving.py#L607-L614
- https://github.com/gevent/gevent/blob/1e412d35526183b26c1abf2eb658cbef661f5f70/src/gevent/baseserver.py#L415-L433
Both primarily check whether the host contains `:`. Werkzeug also
checks if `socket.AF_INET6` exists, however gevent doesn't bother with
that. Looking at the
source (https://github.com/python/cpython/blob/7d801f245e2021d19daff105ce722f22aa844391/Modules/socketmodule.c#L7419-L7421),
it is indeed possible for `AF_INET6` to be missing, however that
requires specifically compiling Python in an environment which doesn't
support IPv6.
Meanwhile it's also possible to disable ipv6 at runtime, in which case
I'd assume the `socket.AF_INET6` constant is present, and creating the
socket fails, which nobody guards against. Therefore just ignore the
entire thing, it doesn't seem worth the hassle (or the questioning) to
check whether the constant is present, especially since this is only a
concern when the user specifically requires an IPv6 address.
Fixes#35782closesodoo/odoo#114666
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Consider a form view with a one2many field, which has no form subview.
Also the form view of the comodel (the one2many field's lines) contains
the inverse many2one field of the one2many field. When adding a new
line on some existing record, the form view shows the many2one field as
empty, instead of being the main record.
Explanation: the form view of the line invokes onchange() with the main
record's values (dict) as the value of the many2one field. Inside
onchange(), the field is actually set to a new record corresponding to
the main record. Alas, when that value is sent back to the form, the
new record is serialized as False.
Solution: let onchange() serialize the new record as its origin record
instead.
closesodoo/odoo#114648
X-original-commit: d137ea4915da8d46909fcb082b5a88fd347874a4
Signed-off-by: Raphael Collet <rco@odoo.com>
In order to ease the process of setting vats for some users, it was
decided to allow to use a vat number of a single character ('/' for
example) without checking it. This allows to differentiate between
partners for which we did not set VAT yet, and partners exempted from
VAT/without a number.
The VAT check was recently adapted to handle this use case, but the
"same vat" warning was forgotten in the process.
This additional change will disable the "same vat" warning that appears
when two partners share the same VAT number if that vat number is
only a single character, aligning the behavior of the warning to the
changes done in the vat check itself.
closesodoo/odoo#114640
X-original-commit: 4d80d30d0db6993a2fbbab59b935abe07080074b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").
closesodoo/odoo#114609
X-original-commit: 5fc49f8bb24a328e7b735847795bd8e78229cbfb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
document_ftp, website_instantclick, pad, pad_project, note_pad, pos_cache is not currently existing in the addons, removing the non existing modules from the BLACKLIST dictionary.
closesodoo/odoo#107213
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Install `Contacts` module
- Create 3 contacts with the same name
- Archive one of the contacts
- Go to list view
- Edit search filter to display archived and non archived contacts
- Select the 3 created contacts
- Open `Action` menu and click on `Merge`
Issues:
- Archived partner is set by default as destination partner.
- Archived partner is not displayed in the list of partners to merge.
Cause:
- The default destination partner set is the last record of the record
set returned by `_get_ordered_partner` (where `Archived` partners
are the last ones in the record set).
- The field `partner_ids` does not allow archived records.
Solution:
- Sort the partners to have the archived ones on top (since we took
the last one).
- Set `active_test` to False in the context of the partner_ids field.
opw-3205577
closesodoo/odoo#114508
X-original-commit: 8d0cec6844b248d3787bd7d6b8868d930d25e38c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Odoo does not have much in terms of payment protection; you can create
payments to any account you want without many checks.
This changes it by requiring users with the right groups to trust an
account before allowing it to be used for payment methods requiring.
Also adds some warnings on the bank account view, and checks at the time
of creating a payment.
Task id # 3210415
closesodoo/odoo#114278
Related: odoo/enterprise#37789
Related: odoo/documentation#3737
Related: odoo/upgrade#4397
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This field has been introduced in
https://github.com/odoo/odoo/commit/c68600cc5397700df4f40095c27723a2b1f90a22
The reason why is not really clear, given the commit message.
But, it looks completely unused nowadays.
We can therefore safely remove it.
In addition, this will save a lot of transferred data to the web client,
as currently all the fields of an action are read when the web client
loads an action,
including this one, which contains a long xml content.
For instance, with just base and the contacts modules installed,
to load the action of the Contacts menu,
it goes from 5.51kB to 1.05kB.
closesodoo/odoo#114041
Related: odoo/upgrade#4390
Signed-off-by: Rémy Voet <ryv@odoo.com>
Purpose
=======
Add the properties fields in the search bar and allow to search
properties fields values.
Technical
=========
If the "active_id" is in the context, show only the properties
of the given definition record. Otherwise, show all properties
of all definition records.
Because fetching the properties definitions cost a SQL query and a RPC
call, the properties definition are fetched only if we unfold the
properties field (so it has no performance impact until we ask
explicitly to search a property).
Task-2980121
Part-of: odoo/odoo#101901
Co-authored-by: Polymorphe57 <dam@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the frontend
top bar filter on views in a later commit, and so everything as been
kept as simple as possible for that particular use case.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or
using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
Part-of: odoo/odoo#101901
Purpose
=======
Do not modify the cache in order to improve the performance when we
read in batch. Instead we create a new batched method "convert_to_read"
that check existence in batch, and generate a dict with the result.
Now, all the properties field checks (many2one existence, selection option
still exists, tag value stiff exist, etc) and done in "convert_to_read".
It means that doing `record.properties` won't do all those checks.
Having the batched field fetch at the convert_to_record required too
many changes for the scope of this task, so "record.properties" having
the cache values unchecked is an acceptable tradeoff currently, hence
we batch convert_to_read.
Task-2980121
Part-of: odoo/odoo#101901
Make ir.attachment._search() consistent with method check() for access
checks. Also make it generate less queries by combining the extra query
with the main query of _search().
Part-of: odoo/odoo#112126
Roy Le