When a record is created with a field property of type integer or float equal to 0, there is
no record created in ir_property for this field. Then for a search of a record with this type of
field equal to 0, it must match all the records that have no corresponding property in the table
"ir.property" for this field.
ps: in 7.0, the function search_multi doesn't exist and the bug linked to cost price
doesn't happen because it's a float field.
opw:639746
When receiving goods with average price set as costing method,
for a move from another company than the SUPERUSER_id company,
the average price updated was the one from the SUPERUSER company
instead of the one of the move.
opw-634167
In commit 04ba0e99, we introduced an optimization for reading inherited fields
in a single query. There is an issue when you have more than one level of
`_inherits`. The query looks like:
SELECT ...
FROM table0, table1 AS alias1, table2 AS alias2
WHERE table0.link0 = alias1.id AND table1.link1 = alias2.id AND ...
^^^^^^
should be alias1
This fixes the issue, and adds a test to reproduce it. The fix is based on
@emiprotechnologies's own proposal, but is cleaner and does not break APIs.
This fixes an issue in property `field.digits` that cannot find a valid cursor
to the database. Forcing the instantiation of an environment makes the cursor
retrievable.
When importing a CSV file with an "id" column containing
external IDs (XML IDs), the system automatically creates
or updates the corresponding ir.model.data entries.
This would fail for regular users who do not have
create/write access on this internal model.
The server parameter `log-db` gives the possibility
to store the logs of a server in a specific database,
in the ir.logging model.
Unfortunately, it wasn't possible to store these logs within
the database from which the logs came from in a multi databases
environment (e.g. the SAAS).
This revision gives the possibility to store the logs
within the database where the logs come from,
using --log-db=%d (inspired from the --db-filter arg)
We also added the possibility to change the level of logs to store in
the database, with the --log-db-level argument, which is set
by default to `warning`.
The `set` method of the one2many class returns a list
of the fields that require recomputation,
the computing of the function fields being delayed
for performances reasons.
Nevertheless, if the `set` method was called
through another `set` method, in other words,
nested `set` calls, the fields to recompute returned
by the second, nested, call to set were never recomputed,
the result list were simply lost.
e.g.:
```
create/write
│set
└─── create/write with recs.env.recompute set to False
│set
└─── create
with recs.env.recompute set to False
```
To overcome this problem, the list of old api style
compute fields to recompute is stored
within the environment, and this list is cleared
each time the store_set_value has done its job of
recomputing all old api style compute fields.
opw-629650
opw-632624
closes#6053
Consider a new field that uses the same compute method as another existing
field. When the field is introduced in database, its value must be computed on
existing records. In such a case, the existing field should not be written, as
its value is not supposed to have changed. Not writing on the existing field
can avoid useless recomputations in cascade, which is the reason we introduce
this patch.
The lazy property `pure_function_fields` was not invalidated upon every setup
of models, and hence could contain old instances of fields. As every model
setup re-creates instances of fields, the property has to be recomputed.
Accessing `field.digits` can crash if no environment is available at that
point. This happens in function `get_pg_type()`, which is called from method
`_auto_init()`. An environment is simply created in the method's scope to be
available for `field.digits`.
The computation of property `digits` was creating a new cursor to call the
function that determines digits. This technique is fragile because the current
cursor may have pending updates that the new cursor will not see.
The issue was discovered by Cécile Tonglet (cto). She observed an infinite
loop during a database migration, and a traceback inside the loop showed the
presence of the `digits` property. This change fixes the infinite loop issue.
As done in write and already in next version (see 0fd773a), accessing a deleted
record (through read or check access rights) should always return a MissingError
instead of the generic except_orm.
This will allow code ignoring deleted record (e.g. 'recompute' method) to safely
process the other records.
Fixes#6105
When searching if a many2one property field is not set, there may be less
results since only the ones with a reference set to NULL are returned.
We should also get those not in the table.
This commit change this case so instead of returning ['id', 'in', {matching non-set ids}],
the ['id', 'not in', {matching set ids}] is returned.
e.g: if (1, 3, 8) are set, (5, 9) are not set. ['id', 'not in', (1, 3, 8)] would
be returned instead of ['id', 'in', (5, 9)] which might not select all non-set
property fields.
closes#6044
opw-631057
The ir.ui.view.graph_get() method depended on the natural
semi-random order of Python dict keys in the _columns dict.
When the number and/or names of the _columns happened to
yield the o2m field of the "incoming transitions" *before*
the "outgoing transitions" of the "Node model"
(e.g. workflow activity), it would swap the incoming and
outgoing transitions fields around, causing a crash later
in the `tools.graph.process` method (currently an infinite
loop in the `tree_order()` method of tools.graph.py).
Closes#3614
Fixes https://bugs.launchpad.net/openobject-server/+bug/1316948
opw-633765
The defaults of ir.values depends on the user company, but there is no
cache invalidation when the company of a user change.
This fix adds the clearing of the default's cache in this case.
Closes#6339
opw-629979
When reading over IN_MAX (currently 1000) records, the select is slip into
subsets of IN_MAX records. However the list of ids was split using set() method
which removes order that may have been pass. The subsets are ordered using
_order attribute but the subsets were not ordered between themself.
This is an issue in case of browsing a o2m field with more than 1000 lines as it
will return sorted blocked but the order of the blocks is the order of the
contained ids (e.g. split(2, [5, 4, 3, 2, 1]) -> [[2,1], [4,3], [5]]).
Removes the set() to make sure the order of the given ids is preserved.
opw 616070, linked to #439
When starting the Odoo server with the parameters --syslog,
the logs are supposed to be pushed in the syslog.
This was no longer the case since e9d047e611.
Indeed, if no address is specified ('localhost', 514) is used,
which not always work. We therefore have no choice to define an address
which is '/var/run/log' for MacOSx,
and '/dev/log' for any other linux system.
opw-633074
`function` fields are fully copied via `copy.copy()`.
`copy.copy()` *do not* call `__init__` after object creation; then
restore the state via `__setstate__()` or by updating `__dict__` or via
`setattr()` when the object uses `__slots__`.
As `__init__` is not called, the newly created object does not have any
`_args` attribute. This lead to a recursive call of `__getattr__ when
`copy.copy` check the existance of `__setstate__` attribute.
When break this loop by forbidding explicitly by checking the attribute
name accessed (We cannot check the presence of `_args` in `__dict__`
because we uses `__slots__`).
See http://bugs.python.org/issue5370Fixes#6037
opw:633109
context_timestamp should always return a timezone aware timestamp, even when
no timezone is set on the user.
7f88681 fixed the bug in old api fields (openerp/osv/fields.py) but it was not
applied to new api fields (openerp/fields.py). opw 616612
`setLang` alters the "browse" context of the documents
being printed, but it must also discard any values
already cached, as they could be using a different language.
This is the case when the report uses translatable fields
on `res.partner`, because `setLang` is usually called
with the target partner language, hence prefetching
the translatable fields with the user's language instead
of the partner's language.
E.g. `setLang(o.partner_id.lang)` will cache any
translatable field on `o.partner_id` in the language of
the *user*, not the *partner*.