Use case when it can happens (non deterministic):
- Enable product variant
- Have different stock moves with the product variant
- Click on the stock moves in the section reports
- Switch to pivot view
-> Traceback : can't find path of null
This happens in the js in the function find_path_in_tree,
this function try to find path for children object. There is
a condition root.children[i].path[l] === path[l] (2 strings
comparaison).
With product variant this condition can be overpass when it should
have been triggered. The product path string is represented as follow
[Ref]Name(variants) -> Sometime the variants in the string do not have
the same order and thus the condition is never true and the function
return null instead of the correct root.
This commit corrects the name_get function for product product
in order to always return the variants in the same order.
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
A company should have at least a pricelist having the same currency, that's common sense.
This was causing problems in tests on 10.0-nightly, where the main pricelist was created
in EUR, then the localization module was setting the right currency on the company without
any reflection on the pricelist.
To avoid this problem, when we write the currency on a company, we reflect that change on
the main pricelist if it's the only company in the system. Otherwise as we can't decide
which pricelist modify, we just create a new one, which should be ok.
The name_search was not working properly if limit=None is specified (e.g.
searching for the search bar on a many2one field to product.template).
As `any int > None` is true, the condition is always validated as soon as the
search returns at least one result.
The product.product search has no limit parameter and use the default 100.
If the 100 first products have only a few templates (a lot of variants), the
result will be incomplete as stopping after the first iteration.
Closes#15477
- Go to Sales > Product Variants
- In the search field, type a letter (e.g. 'p'), then select a
corresponding pricelist ('Public Pricelist' in demo data)
=> Crash
This is because `name_search` returns a list of tuple, not a browse
record.
Fixes#15443
`set_multi` uses the company of the current user.
As the property is created in sudo, the company of the admin may be different
than the one of the current user.
Before this commit, setting a different pricelist on a partner when logged in a
different company than the admin, the change had no apparent effect (was
creating a property for the admin's company).
Set `force_company` in the context to always set the one on the current user.
set_multi ignores if the same as the global rule to avoid bloating the table.
Closes#14984
_get_partner_pricelist could return both a recordset or an ID.
While the ORM handles both where the method is called, a migration script
relies on an ID being returned.
( migrations/sale_contract/9.saas~13.1.1/pre-models.py", line 24 )
This commit ensures an ID is being returned every time.
- Create a new unit of measure with 'Bigger than the reference Unit of
Measure'
- Save
- Edit and change the ratio ==> the ratio is set back to its value
opw-695507
The decimal precision `Account` no longer exist.
This check is therefore pointless, and prevent
to change the rounding of the currency of the main company
By default, the multi-company record rule on
`product.template` is disabled, meaning the products
are shared between the companies.
https://github.com/odoo/odoo/blob/10.0/addons/product/security/product_security.xml#L48
Nevertheless, the multi-company record rule on
`res.company` is well activated, and therefore
this might happen that you can see a `product.template`
for which you are not allowed to read the company.
If you attempt to read something from this company, you must
therefore do it as sudo :)
opw-693209
`id1`, `id2`, `rel` are deprecated now that we switched to the
new API, and are simply ignored.
Keeping them is confusing because the default names are being
used instead.
@rco-odoo: We should add a warning in the m2m constructor if these
unsupported parameters are still passed.
Move the code to manage the case of 'adding an attribute with only one value
should not recreate product' before to select the existing variants.
Before this commit,
When you create 1 new product.template, it create 1 variant.
When you add an attribute with only one value, it update the existing and
create a duplicate variant.
After this commit,
Only the existing variant is updated, and there are no more duplicated variant.
The fix:
We update the variant if only one value before to select the existing variant.
Thus, the updated variant is compared with the matrix and not duplicated.
This commit closes#13757
rounding field of product_uom now has sql constraint > 0. If set at 0 it rounds
any quantity to 0, which is never a desired result.
Allowing 0 made it so that some users that did not understand the rounding, set
it to 0 and complained that their quantities were messed up.
Also added translations to the error message.
Adding the attributes leave all the old variants available.
While not completely intuitive, this behaviour is not inherently
wrong. However, on the first attribute addition, it leaves a variant
with 0 attributes that can cause problems in the ecommerce. This commit
make it so that this empty variant is archived.
When we create a 'product.product', the 'lst_price' entered is
not saved. This is due to the 'inverse' function of the field
named '_set_product_price' which is shared with 'price' and
'lst_price' and uses 'price' to set the value, even if its called
by 'lst_price' field.
Before the migration in new API, it was possible to have the same
inverse fucntion for different fields because the value was passed as param
to the function. In the new API, we cannot because we have to get the
value from the field.
To fix this error, we had to duplicate function '_set_product_price'
in 'set_product_lst_price' to have on function by field, and use the
value correspondig to the field.
Introducied in rev: https://github.com/odoo/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b
Now the porperty product pricelist is computed automatically.
Based on the res_country of the res_partner, and the pricelist available
for this country.
It is always possible to force another value (property) that the computed.
Now that property is computed automatically.
In some case, the compute will take the first on available.
So, the order (sequence) allow to specify the priority.
Test from point of sale are base on currency $,
So we force for the test to use a pricelist in dollard (My company, Chicago)
Barcode, default_code (Internal Reference), standard_price,
volume, weight fields are not saved when we create a new product.
This is due to the fact that these fields need the product_variant_ids
field to be set, in order to compute their values.
Due to migration in rev https://github.com/odoo-dev/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b
The product_manager field is existing since v6.0 and never displayed in any views. It is used in sale_timesheet module. A task created from a procurement_order (if it is a service and we track the service) is assigned to the product manager. It doesn't make a lot of sense as the value should be set directly in the database. We will remove the field and assign the current user to the task instead, which is the common behavior in Odoo.
A typo probably introduced during the migration to the new api may have
caused duplicates to appear in the name search results since it added
the ids of the wrong recordset.
The previous fix, while effective, also removed a previous optimization
for databases with a lot of products. While the code may seem obscure
on first read, the comments should shed some light on the
implementation choice.
This commit therefore reintroduce the previous code with the exception
of the call to the wrong recordset (self instead of products).
Amends b02a85f
Courtesy of @rco-odoo
A new field `create_variant` has been added on `product.attribute`.
If unchecked, the attribute will not create variant.
These attributes will be added on the sale order description if bought from the shop.
The lines of a product with these attributes will be splitted to keep the description.
* variant prices should be read only on the variant
* added an help to explain how it works
* because variant prices are managed on the template via the Variant
Prices button
Alexis de Lattre