There has been a change in the code for the state_id for Mexico City. Since the beginning of 2022, the new code is CMX instead of DIF.
opw-2801208
closesodoo/odoo#87419
X-original-commit: fd72db46667e4e612a0f1d70a9e3e3ccf163de43
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
This flat structure makes caching easier if odoo adds shared caches for
example. In addition, the use of idempotent names makes it possible to
compare methods during development.
closesodoo/odoo#85110
Related: odoo/design-themes#554
Related: odoo/enterprise#24622
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
This fixes a problem that occurs with conditions on one2many fields,
where most conditions are translated with a subquery like
"model".id IN (
SELECT "comodel"."model_id" FROM "comodel" WHERE ...
)
The issue occurs when the subquery return NULL values, i.e., when the
field "model_id" in the subquery above can be NULL. The fix simply
consists in adding the condition "model_id IS NOT NULL" in the WHERE
clause of the subquery.
The problem with NULL values returned by subqueries is the fact that
they make the SQL condition undetermined instead of false, and this
discards some of the results returned by a query. Simply consider:
id NOT IN (1, 2, 3)
The value id=3 makes the condition false, while i=4 makes it true. Now
consider that the set also includes a NULL value, like:
id NOT IN (1, 2, 3, NULL)
The value id=3 makes the condition false, but the value id=4 makes it
undetermined. Therefore this condition is actually undetermined for all
possible values of id, and a query containing that condition simply
returns nothing!
closesodoo/odoo#87285
X-original-commit: 6d680bac0333c6c7ce9f056cba0e1f7e9fa22f9c
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
This fixes two problems that occur with conditions on many2many fields:
the subtle bug caused by NULL values that are returned by subqueries,
and the performance of those subqueries.
The problem with NULL values returned by subqueries is the fact that
they make the SQL condition undetermined instead of false, and this
discards some of the results returned by a query. Simply consider:
id NOT IN (1, 2, 3)
The value id=3 makes the condition false, while i=4 makes it true. Now
consider that the set also includes a NULL value, like:
id NOT IN (1, 2, 3, NULL)
The value id=3 makes the condition false, but the value id=4 makes it
undetermined. Therefore this condition is actually undetermined for all
possible values of id, and a query containing that condition simply
returns nothing!
Regarding performance, consider a domain like [('tag_ids', '=', False)].
It is currently translated in SQL as
"model".id NOT IN (
SELECT "model_id"
FROM "model_tag_rel"
WHERE "model_id" IS NOT NULL
)
PostgreSQL does not handle well this "NOT IN" expression when the
relation table is large, and uses some very inefficient query plan in
that case. The inefficient query plan is possibly related to the
special handling of NULL values, by the way. This commit changes the
above expression to a "NOT EXISTS" expression (as below), which is
executed with a much more efficient query plan, even with large tables.
NOT EXISTS (
SELECT 1
FROM "model_tag_rel"
WHERE "model_tag_rel"."model_id" = "model".id
)
This change was motivated by a use-case with 2.7M account moves, 11M
account move lines and a many2many relation table with 2.3M lines
(`account_move_line_account_tax_rel`). The query was timing out (15
minutes), and it now takes 15 seconds.
We have replaced all the conditions on many2many fields to use the
relational operators EXISTS and NOT EXISTS.
A test has been added to reflect a case where the many2many table
contains NULL values, like the one for channel_partner in regards to
partner_id and guest_id.
task-2753782
X-original-commit: 334b2aa2aa437d2ed86130f2ed426025f8fe4b86
Part-of: odoo/odoo#87285
Co-authored-by: Didier Debondt <did@odoo.com>
Until now using a groupby on a view containing a reified field added
with studio was not possible.
Because `read_group` uses these pseudofields as simple fields when they
are not actually columns in the table.
With `read`, `write`, `create` and `fields_get` it was already
supported.
This commit solves this problem by ignoring reified fields in an
override of `read_group`
opw-2793148
closesodoo/odoo#87186
X-original-commit: a25e25aeab3ed6aa1af57fac13312346b723dbf8
Signed-off-by: Raphael Collet <rco@odoo.com>
mail_* = mail, test_mail, test_mail_full, test_mass_mailing
PURPOSE
Improve tooling of mail tests. Use SMTP mockup class available in base tests
in mail tests to have a better and simplified mock tool when dealing with
mail tests. Remove old fashioned code.
SPECIFICATIONS
Include ``MockSmtplibCase`` directly into ``MockEmail`` so that we re-use
existing components for mocking outgoing emails. Also make parameters for
gateway coherent between those two classes (use same test values).
Remove 'sim_error' weird parameter of Mail ``mock_mail_gateway`` and use
standard mock 'side_effect' instead in some specific tests, notably on
SMTP.connect() mock.
Add some assert / tools method and improve existing tools, used for creating
or improving test data. This will be used in future commits when adding new
tests.
Add outgoing mail servers data in mail tests, allowing to make tests closer
to real life use cases.
Remove unnecessary calls to ``_init_mail_gateway`` as it is automatically
done in ``MailCommon.setUpClass()``.
Try to consolidate starting test data, notably with countries, phone numbers
or email in mind to be sure test mail are deterministic.
Task-2673913 (TestMail: Cleanup and improve test coverage)
Part-of: odoo/odoo#86393
We should also use the tzinfo to display only the time of a
datetime.
task-2458013
closesodoo/odoo#86967
X-original-commit: 49604185d04a3f9d7772d2a60771f0e777720eef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add the possibility for portal users to manage API keys
in the frontend portal interface.
- Allow for portal users to manage their API keys if the system parameter
`portal.allow_api_keys` is set.
A settting in `res.config.settings` is added in order
to enable or disable the feature (to add/remove the system parameter)
through a compute field,
to avoid adding a new database column in standard
(as this revision targets stable 15.0).
The setting appear only in debug mode.
- Display the API keys in the portal in debug mode only
(as in the back-end for regular users, in their profile)
- The flow in the frontend is a mimic of the flow from the backend,
the wording and the look and feel is from the back-end.
closesodoo/odoo#86915
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Models can be defined by an SQL table, an SQL view or an SQL query (with
attribute _table_query). Counting records makes little sense when the
model does not correspond to a table, and actually fails when it is
defined by an SQL query.
We fix the compute method by counting records only for models where
_auto=True.
closesodoo/odoo#86913
X-original-commit: 956a0a1cc22f3f35fc128e32cb267e2baa793fb9
Signed-off-by: Raphael Collet <rco@odoo.com>
Deleting an orphan translation is mostly impossible, since it requires
'write' access on the corresponding records, and checking access rights
fails because the records no longer exist!
Simply enable operations on orphan translations by ignoring the
corresponding records that do not exist. And make sure that the patch
does not allow to create orphan translations.
closesodoo/odoo#86869
X-original-commit: 454aa2587dcda2582ae58650019669ff0e8baa2c
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
Context
-------
Web design specific require a lot of work and need maintenance.
So far the style files were not taken into account despite the
amount of maintenance they require.
With this commit they are going to be counted,
knowing they still can be excluded in the manifest.
Imported module allow to deploy frontend assets: stylesheet,
javascript, xml template and Qweb view that require
as well some maintenance. They are going to be counted
Implementation
--------------
- Add method to parse css and scss file
- Include .scss and .css file in the count
- Add external_id to attachment that store
frontend asset of imported module
- Find all attachment with .js, .css, .scss, .xml
from imported module
- Find qweb view from imported module
- cound the content of the attachment and the qweb view
closesodoo/odoo#86816
X-original-commit: d2e0b48271dbd8cd7bbdbc5c2c1649c55c51417b
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
The duplication was used to have a cleaner html page source code by
aligning the <script t-foreach/> for example. However, this behavior
seems difficult to understand and use. Additionally the behavior can be
done with a <t> tag and placing the script inside.
From now on, the space "trick" is only done for <t> tags, so the
template fragment
<article t-foreach="[0, 1, 2]" t-as="value" t-esc="value"/>
<t t-foreach="[0, 1, 2]" t-as="value">
<article t-esc="value"/>
</t>
renders as
<article>0</article><article>1</article><article>2</article>
<article>0</article>
<article>1</article>
<article>2</article>
closesodoo/odoo#86695
X-original-commit: 8f817790d3f36455c66647e79df40b7173ac498a
Signed-off-by: Raphael Collet <rco@odoo.com>
Because of 4347491670, the method
name_get() can now return records with False as label, and this makes
code crash when it expects a string. Make sure that name_get() always
return strings as labels, while keeping False as empty value for the
field 'display_name'.
closesodoo/odoo#86688
X-original-commit: ff37a2fef89df292b52b1501c28fcf841e1628f5
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, any field requested to `_binary_record_content()`
when the model was `ir.attachment` would be considered as `raw`.
This assumption works at the moment but could lead to unexpected
behavior down the line.
see https://github.com/odoo/odoo/pull/86005#discussion_r824420219closesodoo/odoo#86524
X-original-commit: eeb93287f9a9027d0ce22f9fd3305a7ab081d69f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit: printing a product's label which has currency with
zero decimal places (like CFA franc) raised a traceback error.
To fix this issue, I added a condition that checks whether there is
a separator in the value to ensure that the currency has a decimal point.
opw-2711074
closesodoo/odoo#83358
X-original-commit: bc2ad6ac2312d8446e6d2a9909e957d5e18c3c0e
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The l10n_sa_invoices changes do not need to be in a separate module as
they are always required for l10n_sa.
This merges the two modules into l10n_sa
closesodoo/odoo#85215
Task: task-2723443
Related: odoo/upgrade#3303
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
During the merge of qweb/ir.qweb at commit 9ce5bc8881,
the behavior of qweb was preserved instead of the one from ir.qweb.
Rendering inline templates should not be allowed as it is not needed and
include security risks.
Also, minimizing the number of possible types for template arguments
simplifies the API. An error message allows the developer to know how to
adapt his code.
closesodoo/odoo#86404
X-original-commit: 31f3152a1328ec8e2dd28f15433a2cc3ccc80f81
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, since the refactor of some base64 decoding flows and
the addition of the raw field*, reading the content of a field that was
related to the `raw` field of `ir.attachment` was treated as reading a
base64 encoded content. This commit fixes this issue.
*https://github.com/odoo/enterprise/commit/680db8197731dae175027f81a705c38b0abf94da
task-2785146
closesodoo/odoo#86403
X-original-commit: 6aa984f072dde5667d07516888c6a4bf19aead8e
Related: odoo/enterprise#25272
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
- Render negative duration with the duration widget
Example V15:
- Create timesheet entry with negative duration (e.g. -00:30)
- Print the timesheet entry
Current Behaviour:
- Time is rendered as Time-1h (in e.g. -01:30)
Behaviour after PR:
- Time is correctly rendered (in e.g. -00:30)
opw-2731186
closesodoo/odoo#86360
X-original-commit: a45e2c03e26034f683a692d9c93e26925f7c2a21
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2753905
closesodoo/odoo#84058
Related: odoo/upgrade#3228
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Add globe button next to language for leads and opportunities if the
database is in multi language mode and user has enough access rights.
User is also unable to edit language from view
PR: odoo/odoo/pull/78287
Task-2662548
Part-of: odoo/odoo#78287
The issue is simply creating a related stored many2many field, which is
pretty easy to do with Studio. When creating the field, Odoo crashes
with a traceback caused by ondelete being None on the field.
The source of the bug is the fact that the attribute field.ondelete is
set to a sensible default ('cascade') on non-related fields only. The
fix consists in setting the default value on the attribute itself, so
that the setup of the field never falls on a case where field.ondelete
is unset.
closesodoo/odoo#86303
X-original-commit: d0e0d80806a1b63ac986e9bcbaf88f9fc5243319
Signed-off-by: Raphael Collet <rco@odoo.com>
Persian language native name misspelled as "فارس" instead of "فارسی"
closesodoo/odoo#86225
X-original-commit: 073affad1595ca011f8af95be759bfc656cffe7e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Assets bundle are wrongly regenerated on the following circumstance.
The use of multiples tag `t-call-assets` in some xml template(s) with:
- at least one `t-call-assets` with `t-js` or `t-css` to false
- at least one `t-call-assets` without `t-js` nor `t-css`
In mass_mailing, the buggy regeneration of assets happens at a critical moment
and break the url of a previously generated asset. That url was however saved
in a javascript cache and therefore the bundle is inaccessible. No css style is
therefore applied to the page.
Note 1: the bug for the previous specific case in mass_mailing only
appears if within all the files defined for the bundle
`web_editor.wysiwyg_assets`, the last modified file (mtime) was of
type javascript. No visible bug would appear if the last modified file
was of type stylesheet (css, scss, ...). However, the asset would be
regenerated at a time where the cache should be used (invisible for the user).
Note 2: in order to reproduce the bug systematically without this commit,
it is necessary to disable the browser cache. Otherwise, if the
browser has the broken url in cache, no http request will be made and the bug
will not appears.
The bundles are wrongly regenerated because of how the url is
generated. Part of the url is generated using the "version" of the
bundle. The version is defined using a checksum. The checksum uses
information about the *last modified* file of the bundle. And this is
where bug arises.
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be B
If the bundle was called without `t-js` nor `t-css` the list includes
all js and css files.
- The version for the `js` bundle **and** the `css` bundle will be A
if the last modified file type is javascript or B if it is a stylesheet.
This commit change the behavior to always consider all the files last
modification within bundles in order to derive the version.
Thus:
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be A
If the bundle was called without `t-js` nor `t-css` the list of file
includes.
- The version for the `js` bundle **and** the `css` bundle will be A.
Example:
assetsA has two files:
```
file1.css
file2.js
```
file1.css was last modified at time A
file2.js was last modified at time B
bundle A
```xml
<template name="template_a">
<t t-call-assets="assetsA" t-js="false"/>
</template>
<template name="template_b">
<t t-call-assets="assetsA" t-css="false"/>
</template>
<template name="template_c">
<t t-call-assets="assetsA"/>
</template>
```
In a javascript file:
```js
const ajax = require('web.ajax');
await ajax.loadAsset({assetLibs: ['template_a']});
await ajax.loadAsset({assetLibs: ['template_b']});
await ajax.loadAsset({assetLibs: ['template_c']});
await ajax.loadAsset({assetLibs: ['template_a']});
```
Whenever loading a assets of a template, the urls for the css and javascript
files are saved into a cache until the next browser reload.
In this example, without this commit:
- the first `ajax.loadAsset` `template_a` generate a css asset with version X
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the javascript
cache for `template_a`
- the `ajax.loadAsset` `template_b` generate a js asset with version Y
-> a js file is generated and the url of the js file is
`/web/assets/version_Y...js`
- the `ajax.loadAsset` `template_c` generate a css **and** js asset
with version Y if time A (a css file) is bigger than time B (a js
file):
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the js file is
`/web/assets/version_X...js`
if time B (a js file) is bigger than time a (a css file)
-> a css file is generated and the url of the css file
is`/web/assets/version_Y...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the css file is
`/web/assets/version_Y...js`
--> because the css file is re-generated (the version changed from
X to Y), the url in the javascript cache is no longer valid.
- the last `ajax.loadAsset` `template_a` use the url in its cache and
either the css url or the js url would no longer will be available
and a http error will trigger if the code tries to access it.
Task-2778413
closesodoo/odoo#86155
X-original-commit: 2267cfc947eff9fc4f00468610a82c8fbbca36ad
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Coming from odoo/odoo@a4597fe34f . This code is not necessary anymore since we better
handle From, SMTP-From, as well as allowing mail server filtering. We can
now use standard aliases and servers instead of relying on hardcoded value
"postmaster-odoo".
Task-2784996
closesodoo/odoo#85837
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* Studio generate computed field "count" when the user add a button
in the button box. Since those lines are written by studio with drag and drop
it should not be counted for the maintenance subscription.
We can detect them because field created by the user in studio start with x_studio
and fields created outside studio does not have studio_customization
xml_id
* Add test to make no standard module introduce customization in the
database during the install the will be counted by cloc
see https://github.com/odoo/enterprise/pull/22664closesodoo/odoo#85763
X-original-commit: 47ae24081fe5c0c86ce8507229dfb550ec585633
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
The signature of the _load_module_terms was changed at ac63556e23 to
pass explicit parameters instead of values hidden in the context
The previous code used working on a copy of the context when modifing
the 'overwrite' key. This was no longer the case after ac63556e23.
In case multiple languages are updated at the same time (as when a
module is updated), the 'overwrite' value is set to True after the
first loop.
To reproduce:
1. Create empty db with language English and without demo data
2. Activate languages fr_FR, fr_BE and fr_CH
3. Install module "note"
4. Now change in the fr.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante FR"
and in the fr_BE.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante BE"
5. Now update the module note without overwriting translations
(--i18n-overwrite option not set)
Observed behaviour:
The translations are overriden
opw-2760359
closesodoo/odoo#85768
X-original-commit: 37b98d413debabcd966718b2834d34f349e3cfbc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When users have same groups, implied_ids can be done in batches,
reducing write operations considerably.
Testing done:
800 users groups_id (all have same groups_id in the end) updated using
old code: took ~10s to complete.
With this improvement, it takes ~1.5s
closesodoo/odoo#85712
X-original-commit: 81994ea628cb492fef4e62c496d4ea1ab55d9a7e
Signed-off-by: Raphael Collet <rco@odoo.com>
If an installed module is only present in the dependency graph through a new,
uninstalled dependency, it was not be selected for upgrade when updating the
`base` module (c.q. `--update all`)
closesodoo/odoo#85704
X-original-commit: 6c80e7cfeafaaa4fb7c0d93cbe94c66068fc3170
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
closesodoo/odoo#85220
Signed-off-by: Rémy Voet <ryv@odoo.com>
The public read_group method is used by back-end code as well as RPC calls to receive grouped data.
Most of the time, if the data isn't shown to the user, it doesn't need to be sorted on the names of
the many2one, and can just be sorted on their ID instead, avoiding extra joins in the resulting queries
This is a first commit that will reduce the features of _read_group to the strict minimum necessary
to obtain correct grouped data that is never shown to a user
Task-id: 2479334
Part-of: odoo/odoo#84908
Adds a test that verifies that the grouping with a date aggregate
specifier (the only group specifier supported until now) is working correctly
Part-of: odoo/odoo#84908
reshape a bit the read_group tests by ensuring that:
- creation of user is made in batch
- assertions are always assert(actual, expected)
Part-of: odoo/odoo#84908
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Just before deleting records, we mark fields on dependent records as "to
compute", and their actual computation should happen after the records
have been deleted. The problem is that checking security rules may
trigger the computations that have been prepared. So we should check
security rules before marking dependent records.
closesodoo/odoo#85574
X-original-commit: 79908bc757a239c97bd2b4cda505b7b8df769325
Signed-off-by: Raphael Collet <rco@odoo.com>
mode
Purpose:
Include the name of the partners so that:
- it can easily be updated
- it is easier for users to recognize who is who
To generalize this modification, a new attribute has been added to the model
field descriptor (odoo/fields.py): default_export_compatible.
Setting this value to True on a field of a model will force that field to be
included by default in the exportation when "import-compatible export" is
selected.
Specification:
If the user goes:
Contacts > List view > Select Records > Action Export
> I want to update data
The field name is selected by default
The fields selected by default for export are the columns of the list so that
what is exported by default is what the user sees on the screen.
The display name is one of the column but is not importable.
When the option "I want to update data" is selected, only field that are
compatible for importation are selected and then display name is no longer
selected.
With this modification, the name is selected instead.
Technical:
- a new attribute "default_export_compatible" has been added in odoo/fields
- the controller /web/export/get_fields that lists the fields available
for exportation has been modified to add a default_export attribute on each
returned field. This new attribute is set to True when import_compat is True
and default_export_compatible is True on a given field.
The client uses that information to force by default the field for exportation.
Task 2734222
closesodoo/odoo#83697
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Laurent Desausoi (lade)