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
The product.template displays the list of pricelist items with the name of the pricelist
The product.product displays the same information except the pricelist name.
This commit harmonize both views to display the same information.
Fixes#15009Closes#15010
`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
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
_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.
The order of variants(product.product) is (re)defined each time the attributes
of a product.template are modified. The order of these variants is computed according
to the order defined on "product.product" which is ordered by 'default_code,name_template'
and also the sequence of the product.attribute.value.
But when a new product.attribute is created, the default sequence is the order of creation of your new values.
So if the sequence of the attributes is changed after modifying the product.template, the new sequence will not
have any impact on the order of the variants. The sequence of the attributes must be defined first
before modifying the attributes on a product.template to have an impact on it.
opw:693135
Due to the following revision:
295b96c0b3
The company on the version and items was not assigned
when creating a new pricelist version on an existing
pricelist.
They were if you changed the company of the pricelist,
thanks to the triggers added in the above revision,
but not when they have just been created in the pricelist.
These new triggers repairs this regression. It also handle
changing the `pricelist_id` of a version (this is doable through
the "Sales > Configuration > Pricelists > Pricelist Versions" menu).
Fixes#14631
Odoo Translation Bot