We set the default rate to be 1.0 instead of 0.0, since a rate of 0.0
doesn't make sense.
Partial backport of 298491597c
opw-1949866
closesodoo/odoo#31866
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).
This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.
The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.
closesodoo/odoo#31804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.
The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().
See tests for a clearer view of the use cases.
Fixes#30113, #26540closesodoo/odoo#31202
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
Some views have the primary mode while having an inherit_id view
In such views, if the user wants to change the inherit_id,
the mode must remain primary.
The use case behind this is a user who want to change
the inherit_id view of the view
product.product.form (product.product_normal_form_view)
to another view.
This view is in primary mode while having an inherit_id
(product.product_template_form_view).
In such a case, the primary mode must remain,
otherwise the view will no longer be opened by default
when opening a product.
Indeed, when searching the default form view of a model,
it only searches for primary mode views for this model.
The `all` is there because this is an `api.multi` method.
We could consider adding a `self.ensure_one`,
but it breaks the API if someones calls this method with multiple records.
This is likely to happen, as this method is used
in `write` which is likely to be called with multiple records.
In my opinion, in master, this should be replaced by an
onchange so the user can see the change of mode
when he adds or remove an inherit_id for a view.
opw-1916324
closesodoo/odoo#30241
Previous to this commit, if one were to create an ir.model.field with a
poorly constructed domain (read: SyntaxError), the server would properly
send an error message stating that an Error occurred, however this would
be too late as the registry with the bad code would have already been
reloaded, this meant that the registry would be left in an unstable
state (read: crashed).
With this commit, a constraint on the domain is added so that we confirm
that the code in the domain field is properly constructed, thus no need
to reload the registry and therefore no crash.
closesodoo/odoo#30157
The method `read()` may be very slow when reading relational fields and
computed fields, because the computed fields can be computed on a recordset
that is larger than expected.
The issue occurs on model 'res.partner' when reading fields 'child_ids' and
'purchase_order_count', for instance. Suppose we read those two fields on a
partner with 1000 contacts. First, the one2many field is read from the
database and stored to the cache; the latter adds the value ids to the
prefetching of 'res.partner'. Then, the fields are fetched from the cache.
When 'purchase_order_count' is accessed on the partner, the field is computed
on all its children as well...
closesodoo/odoo#29867
Currently name_search on res_partner holds code to be done by a customized SQL
query allowing to speedup the search [1]. However when dealing with given args
there may be a crash if there is a domain based on user_ids fields.
Indeed this field is defined as auto_join [2]. It means the result of get_sql
returns where parameters based on joined tables. Those tables are not available
in the from clause in the original query.
This commit fixes that issue by correctly taking the from_clause from get_sql.
That way joined tables are available. Small update of the query is necessary
as fields are now res_partner.{id/email/vat/reference} as there may be several
tables linked in the query.
A test has been added to avoid regression.
[1] See https://github.com/odoo/odoo/commit/05ec12692f99b69924765fd0ce384632547f03f9 for a recent modification
and implementation of this query, even if it exists since a looooong time
[2] See https://github.com/odoo/odoo/commit/db8203c27a21acdbcad2cf1c394b6fea3cf13688 for the auto_join addition
closesodoo/odoo#29827
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
Christophe Simonis