When we group by date with DST change within a range, we could get a
reocrd inside two date range grouping, or inside no grouping.
This is because we computed range just with [+ 1 month], so we possibly
had these ranges (in UTC):
- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
('datetime', '<', '2019-11-01 02:00:00')]
- November 2019 : [('datetime', '>=', '2019-11-01 01:00:00')
('datetime', '<', '2019-12-01 01:00:00')]
So a record on 2019-11-01 01:30:00 would be both inside October and
November.
This happen because the DST is removed on happen on 27 October 2019 and
this was not taken into account when computing the end of the range.
With this changeset, for the given example aboth, we will have:
- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
('datetime', '<', '2019-11-01 01:00:00')]
Added test without the change fails with "AssertionError: Lists differ"
because:
- "Q1 2019" finished on 17:00:00 instead of 16:00:00
- "Q3 2019" finished on 16:00:00 instead of 17:00:00
opw-2278829
closes#54056closesodoo/odoo#54345
Note: maxDiff added for test to work in 13.0
X-original-commit: af5d03de28fa300ebbaa37a3d226b41051ebdf0f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Use case:
- `./odoo-bin -d mydb -i website`
- `./odoo-bin -d mydb -i base_automation`
- `./odoo-bin -d mydb -u website,base_automation`
```
odoo.addons.base.models.ir_model: Deleting 2652@ir.model.fields (base_automation.field_base_automation__website_published)
odoo.addons.base.models.ir_model: Deleting 2651@ir.model.fields (base_automation.field_base_automation__website_url)
odoo.addons.base.models.ir_model: Deleting 2650@ir.model.fields (base_automation.field_base_automation__website_path)
```
The issue comes from the fact:
- `website` adds multiple website related fields on `ir.actions.server`
https://github.com/odoo/odoo/blob/30e94d305f9cffa816ddc213e0b9329c0263c145/addons/website/models/ir_actions.py#L16-L18
- `base.automation` inherits by delegation of the `ir.actions.server` fields
thanks to `delegate=True` on its field `action_server_id`
https://github.com/odoo/odoo/blob/30e94d305f9cffa816ddc213e0b9329c0263c145/addons/base_automation/models/base_automation.py#L37
- when `base_automation` is installed after `website`
when `_reflect_model` is called,
the website related fields on `ir.actions.server` are well in the `_fields` of the `base.automation` model,
and there an xmlid for these fields is created
e.g. `field_base_automation__website_published`
https://github.com/odoo/odoo/blob/30e94d305f9cffa816ddc213e0b9329c0263c145/odoo/addons/base/models/ir_model.py#L881-L882
- during the `-u website,base_automation`, `_reflect_model` on `base.automation` is called before
the website related fields coming from its inherits on `ir.actions.server` are added in its `_fields`,
and is not recalled after they are added, when the `website` module is loaded and these website related fields
are added on `ir.actions.server`.
Because of this, at the end of the upgrade, in the `ir.model.data` `_process_end`,
as the xmlids of these fields have not been loaded,
they are being deleted, because the ORM considers these fields were dropped
from the source code because their xmlids have not been loaded during the upgrade.
Adding the model `base.automation` in the `inherits_children` of `ir.actions.server`
when the delegate field `action_server_id` is added make sure
`_reflect_model` is called on `base.automation`
after the website related field are loaded on the model `ir.actions.server`,
and therefore ensure the xmlids are properly loaded,
therefore preventing the fields deletion.
Additionaly, `delegate` and `inherits` are supposed to be equivalent,
it's just two ways to do the same thing.
Before this revision,
when using `delegate`, `base.automation` is not in the `inherits_children` of `ir.actions.server`:
```
In [1]: env['ir.actions.server']._inherits_children
Out[1]: set()
```
while, by converting the `delegate` to an `inherits`:
```diff
diff --git a/addons/base_automation/models/base_automation.py b/addons/base_automation/models/base_automation.py
index 196ebe9965f..c073150386a 100644
--- a/addons/base_automation/models/base_automation.py
+++ b/addons/base_automation/models/base_automation.py
@@ -30,11 +30,12 @@ class BaseAutomation(models.Model):
_name = 'base.automation'
_description = 'Automated Action'
_order = 'sequence'
+ _inherits = {'ir.actions.server': 'action_server_id'}
action_server_id = fields.Many2one(
'ir.actions.server', 'Server Actions',
domain="[('model_id', '=', model_id)]",
- delegate=True, required=True, ondelete='restrict')
+ required=True, ondelete='restrict')
active = fields.Boolean(default=True, help="When unchecked, the rule is hidden and will not be executed.")
trigger = fields.Selection([
('on_create', 'On Creation'),
```
it is:
```
In [1]: env['ir.actions.server']._inherits_children
Out[1]: {'base.automation'}
```
closesodoo/odoo#54171
X-original-commit: 3fd162db3ab51cc473d99bd90fce6c135f3b4ff3
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This ensures that flushing a one2many field automatically flushes its
inverse many2one/integer field. Without that, a search like:
model.search([('o2m_ids', 'in', ids)])
can return incorrect results.
closesodoo/odoo#53514
X-original-commit: b91b485a5d9a62acfe44b12c64a46dcca23981ce
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
We want to create a XMLID for every first exhibition of a field in a
model. That is, we just want one XMLID by field by model and not one
XMLID by field by class. Previous implementation was determining the
"first field exhibition" by making sure the field was created and used
as part of the same module.
This assumption is invalid when we consider mixins. A mixin is an
abstract model that define fields and methods to be included in other
models. As it is abstract, it does not exhibits the field by itself. The
field will only be exhibited when included in a concrete model via
inheritance. When it is included in another module, the XMLID creation
is discarded.
Take a module M1 that defines a model A, take another module M2 that
defines a mixin X with a field X1. In a third module M3, extend A to
inherit from X. While M3.A is the first model module to exhibit the
field X1, the XMLID creation was discarded because `"M2" != "M3"`.
See https://github.com/odoo/odoo/issues/49354#issuecomment-614093767
Task: 2235368
Closes#49354closesodoo/odoo#53435
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`state` was special cased in `copy_data` such that it would always be
reset to its default value if it had one.
While this special case can be useful (maybe) and is certainly
ingrained in odoo, having it not be overridable can be
problematic. Move the special case to the fields, so it's possible to
explicitly mark state fields as copy.
closesodoo/odoo#53113
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
The following situation can occur: a computed field depends on one2many
lines, and during an onchange, a line is modified. Both the main record
and the line are new records. If the many2one field is not in cache on
the line, its value is fetched from the line's origin, and the field
will be triggered for recomputation on the main record's origin instead
of the record itself.
The fix enforces the following property: if new records are modified,
only new records can be triggered for recomputation.
X-original-commit: f038b6c40b7045b6fe569c009d29ea092b614ed6
By default importing is batched (or at least attempted to), however
because the import is functionally sequential it's possible for a
record to refer to a previously imported record of the same batch.
When records are referenced by xid this is easy, we can just keep
track of all the xids we *should* have created so far and when trying
to look up a xid if it's one of those flush all pending
creations (otherwise assume it's some other unrelated xid which
already exists in the system).
For "name_search" lookups however this is more complicated, so we'd
just flush the entire thing.
This, then, is an issue when importing records with an m2o which
is *generally* looked up by "name" rather than xid e.g. when importing
partners it's more likely the "state" will be specified by
name (e.g. AZ or Arizona) than xid (base.state_us_3 lol), because it
means more or less every line will be flushed, defeating all batching
and slowing down the import.
To fix this, allow passing *model names* to flush (not just xids), and
try to collate all the models we could be creating (or updating)
records for in the process of importing. If we see a name_search on
one of these models flush, otherwise don't because we couldn't have
impacted the search.
Task 1951307
While at it, f2a1618758 removed all
usage of model_load_save, but left the creation of the savepoint
itself.
The InternalError check should be left in place to catch things like
conversion issues which put the tnx in an invalid state (only invalid
states should trigger an InternalError according to psycopg's errors
documentation).
closesodoo/odoo#49289
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Replaces the auto_join scheme which is pretty fast but doesn't quite
work (it's *completely* broken for read_group) by a subquery which is
slower but has the same semantics as the ORM version.
Ideally we'd use `EXISTS (select 1 from ...)` but that has no support
inside the SQL compiler right now, so use `id in (select inverse_field
from ...)`.
Here are some measures of a `read_group` on a simple object with lines
filtered on line values, similar to
read_group([('order_line.product_uom', '=', xxx)],
fields=['total_amount'], groupby=['user_id'])
+-------+-------+-------+--------+
| | ORM | join |subquery|
+-------+-------+-------+--------+
| large | 160 | 10 | 20 |
+-------+-------+-------+--------+
| many | 36000 | 50 | 180 |
+-------+-------+-------+--------+
* values of data fields (filtering, grouping and aggregating) randomly
picked between 10 different values
* "large" is 1000 objects with 1000~15000 lines each
* "many" is 1000000 objects with 1~40 lines each
closesodoo/odoo#48494
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Instead of merging Query objects (main domain and access rules domains),
which requires renaming aliases in query strings, make `expression` push
its result in an existing Query object. This removes tricky code.
This also avoids using `IrRule.domain_get()`, which has become unsafe,
since it returns a list of tables (for the FROM clause) which does not
include the joins from the generated Query object.
closesodoo/odoo#49999
Related: odoo/enterprise#10126
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The management of the join contexts now relies on the `Query` object,
that has all the necessary logic to do so. The refactoring also removes
the class `ExtendedLeaf`, which is no longer necessary: the join
contexts are all managed by a single `Query` object, and the parsing
stack now only contains triples like (leaf, model, table_alias).
Also inline directly the SQL translation made in `_to_sql`, which
overall simplifies the management of SQL parameters in the domain
compilation. The algorithm is illustrated in the code itself.
Before this commit, a `search_count` was preparing the ORDER BY clause
even when not using it. The ORDER BY clause generation can introduce
some JOINs in the query, which are useless when the ORDER BY clause is
not used, like in the case of `search_count`.
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Historically, it was possible to import addons via a naked import. It is
no more possible since 9e1f13bac, since that commit, the only possible
way to import odoo addons is via the `import odoo.addons' prefix.
closesodoo/odoo#46995
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
* Cmdline interface: how to trigger database population
* Testing: how to implement database population on a given model.
* autodocumentation of the population methods
+ improve population methods docstrings.
closesodoo/odoo#50596
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Access rights were added on transient models at odoo/odoo#43306
The _filter_access_rules method was still using the old logic of
transient, bypassing access rules
closesodoo/odoo#50828
X-original-commit: 7e0d6f7e0d725a2addb2821c16fce77aed54ca03
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
Create the table with all the columns from scratch, with the NOT NULL
constraint when required. Also do not call `_check_removed_columns()`
on a new table.
This saves 0.5% of the total installation time.
X-original-commit: 0727cacf5194a143b15ab4cb9893f3035a67be1f
This optimization is no longer necessary. Thanks to Python 3.6's new
implementation of dicts, the memory footprint difference between slots
and dicts is now around 5%, which is no longer worth the complexity and
performance cost.
This saves 2% of the total installation time.
X-original-commit: c7f17770803744cbbb741fc11265ee914641aed7
Simplify the code to retrieve fields on a class.
Simplify the class attribute that lists the class' proper fields.
Optimize `model._add_inherited_fields()`.
Optimize `resolve_mro` by using classes instead of recordsets.
This saves 3.5% of the total installation time.
X-original-commit: 89ab71905cb6c5d3beda5eac357f8592e31aaef8
The goal is to avoid a class from being added in the dictionary
`MetaModel.module_to_models`.
We use this feature in tests to prevent classes extending models from
triggering bugs when reloading the registry (for whatever reason).
X-original-commit: 12db61b787b2035bf0c1f2a68a24449d484744c8
Add a new group allowing administrators to remove the ability for
users to bulk-export data from the database. It's pretty minor as
technically the user can still access the underlying object through
the basic methods but it's still a bit of a roadblock.
Users can export by default.
Task 2170900
closesodoo/odoo#45400
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Some use case like testing performance or upgrade scripts required a database
with prefilled data, covering basic corner cases. A solution can be to
create data a procedural way.
This commit proposes an API to easily populate a model, usually by giving a
list of possible values for each field or by giving a compute method that will
be based on raw values of other fields.
The basic way to define how to populate a new field is to override `_populate_factories`,
a method that returns a sequence of pairs `(field_name, factory)`.
The definition of a field is a "factory", a function that returns a neverending iterator
combining its value(s) with the values of the iterator given in parameter.
Some factory helpers are given in `tools.populate.py`:
- `iterate(vals, weighs)` ensures that one record is created for each value
by iterating on them, then resumes as `random.choice` on those vals following weights
once the first iteration is finished.
- `cartesian(vals, weights)` makes a cartesian product of its own values with the values
of its input iterator, then resumes as a randomized generator.
- `compute(function)` calls the given function with the current values dict and a random object,
and assigns the current field to the returned value.
- ...
Each iterator yields dictionaries of field values, and the factory should add a
value for the current field(s). The yielded dictionaries also contain a pseudo_field
`"__complete"`, that indicates whether this step is some randomized data
to reach the expected count of records. A falsy value indicates that the iterator
is still covering mandatory cases. This indicates whether a cartesian product is
finished, or an `iterate` has consumed all its values.
The order of the factories is quite important, since some computed fields may need
other fields to be defined, and `cartesian` factories should always be at the beginning
to avoid having too many combination. That is why the factories are given as a list of
pairs instead of a dictionary; this makes it easier to insert elements at any place.
Example:
field A: cartesian([T, F])
field B: cartesian([0, 1])
field C: iterate([a, b, c, d, e])
field D: compute(1-B)
_c is shortcut for __complete
_ is a random value, or result of a random value
```
iter | root | field A | field B | field C | field D | result
0 {_c:F} {... A:T} {... B:0} {...C:a} {...D:1} T,0,a,1 complete:False
{... B:1} {...C:b} {...D:0} T,1,b,0 complete:False
{... A:F} {... B:0} {...C:c} {...D:1} F,0,c,1 complete:False
{... B:1} {...C:d} {...D:0} F,1,d,0 complete:False
1 {_c:T} {... A:_} {... B:_} {...C:e,_c:F} {...D:_} _,_,e,_ complete:False
2 {_c:T} {... A:_} {... B:_} {...C:_} {...D:_} _,_,_,_ complete:True
```
X-original-commit: 4c0182dafa584853ed83a166096f45c33c06a245
With the introduction of `new`, the use of `resolve_2many_commands` is
redundant, as it accomplishes the same function with the added benefit
of returning a record-like object whose API is more familiar than
`resolve_2many_commands` API.
closesodoo/odoo#37290
Related: odoo/enterprise#9409
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Because CacheMiss calls str() on the record it's given, it's not
possible to override __str__ and get field values: on the first cache
miss (= the first field access) we're going to blow the stack:
* any random field is accessed
* and faults
* which creates a CacheMiss
* which stringifies the record
* which accesses a field
* which faults
* which creates a CacheMiss
* etc...
Fix:
* move the basic Model's stringification to repr(), which is
implicitly called on str() if no __str__ is specified, for historical
reasons we were doing the opposite
* use repr() when initialising CacheMiss
closesodoo/odoo#42966
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The use case is a cache miss of a stored field with compute on a new
record with origin. The field should be computed only when explicitly
triggered, i.e., when a dependency has been modified. Otherwise it
should be fetched from the origin record.
closesodoo/odoo#47353
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Importing 100 records and getting 100 errors (often the same every
time because a required field was not mapped) is not super useful and
spams the logs a lot.
Cutting off at one point seems useful.
Note: integrates warnings-related fix from #47972 reported by Grzegorz
Marczyński in #47936.
closesodoo/odoo#48095
X-original-commit: 6b05f1d13c862dd66e89f35607d072315be80995
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* from collections import <ABC> is deprecated, unclear why the
deprecation warning didn't appear before (possibly only appears in
3.7/3.8?) either way `collections.abc` should be 3.3+ so switch
everything to it.
* add some more ignores on third-party packages deprecation
warnings (meh)
* while at it, mitigate generation of non-breaking space on some
versions of Babel (in the french locale used by our tests anyway)
closesodoo/odoo#47581
Related: odoo/enterprise#9214
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The method `recompute()` should not recompute fields on new records.
This is both a speedup (those recomputations are not necessary), and
fixes an error following an `onchange()` (a field recomputed in an
environment with the wrong context.)
OPW 2184998
closesodoo/odoo#47545
X-original-commit: fa852ba1c5707b71469c410063f338eef261ab2b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When testing odoo, errors can occur an undeterministic way, wich can
lead to strange and unreproductible behaviour. This also means that the
performance can change from one execution to another, making it quite
difficult to track performance variation on a global scope.
This commit makes the result of `exists()` deterministic in terms of
order. The side effect is to keep record ids in the same order as the
original recordset, which may be useful.
closesodoo/odoo#47282
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
- In some cases One2many fields defined as computed without
inverse field defined could cause crashes if it is used
in a search.
This should not be done, but shouldn't crash either.
With this fix, trying to search on one of this fields
would just print a warning.
closesodoo/odoo#46742
X-original-commit: 4b4f1623590f2e872c565e8e56002bc3f5bf9efe
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This allows detailed reporting in write overrides.
Expl:
When (un)archiving multiple records together (from a view list, or in batch call),
you will only see one record at a time in `write` overrides. This means you
won't be able to return meaningful and complete messages to the end user.
Before:
1) Archive A & B
2) "You cannot archive A"
3) Archive B
4) "You cannot archive B"
After:
1) Archive A & B
2) "You cannot archive A & B"
closesodoo/odoo#46358
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Remove a leftover special case of the ORM from a former version.
This fixes a performance issue, where an onchange recomputes a field on
one2many lines one by one.
X-original-commit: 16a75d85741db8a1f87c1d26503a9bb75197cf83
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>
When performing an import-compatible export, m2m values would be
exported as a record per cell unless the `id` subfield was the first
to be exported. Which is not the case when using the export UI (as it
always adds the field itself before any subfield). This would make the
m2m not actually export-compatible in most cases.
* export m2m "display name" in an import compatible format as well
* re-prioritise exporting xids when there are multiple m2m exports in
import-compatible mode
* never fall back on the o2m / non-import-compatible m2m path for m2ms
in import-compatible mode
Note: if multiple m2m fields are specified only one of them gets filled.
Task 2065428
closesodoo/odoo#37407
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Ravi Singh <ras@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
This is a followup of 1d553eea7b.
Systematically logging import tracebacks can fill up log files, and
waste disk space. We therefore log those tracebacks in DEBUG mode, so
that they can be activated only when needed.
closesodoo/odoo#45075
X-original-commit: 017e3d798c55b1bdac221aea76d3d944f045ee65
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When you have su == True in your env and you call _name_search
the _name_search was switching back to su = False
when you call with_user with the same user or with None
To reproduce the issue, take a model where a user has
no access.control.list allowing to read the model
call name_search with sudo.
X-original-commit: 8755269f9877e039663adaec8500b530b6d67c68
Nicolas Lempereur