This variable has been unused since commit f3d6a54e36.
opw 2368733
closesodoo/odoo#61143
X-original-commit: 563253a8303723e3eb4217005bf518fdf6b3f9e3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The pricelist item model (product.pricelist.item) has a compute_price field,
and the necessary fields to be able to compute the price of a product.
However, these fields are never used into the model itself;
the parent model (product.pricelist) actually makes the computation,
embedded into _compute_price_rule.
Because of this, it's not possible to inherit pricelist items.
It's also a better design, on object principles.
Last, it lighten a method that is still 130+ lines long.
opw 2368733
X-original-commit: 9cd0bf740706a64e49599111304a6fb5ec6d7287
Behavior prior to this fix:
When archiving the last variant on a template, the product template
stays active (contrary to the comment indicating that `toggle_active`
will archive the related product.template if there is only one active
`product.product`).
Behavior after the fix:
When archiving the last variant on a template, the product template is
archived. When un-archiving that variant, the product template is
unarchived as well, without un-archiving the other variants.
Note: this is a remake of a fix implemented in 77e5472c041e, as that fix
did not correctly count the inactive variants.
opw-2349862
closesodoo/odoo#60641
X-original-commit: 01160ee5e7f726f3035c566a13e26825236dedfd
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
Issue
- Install Sales with Product Configurator
- Create a product with 2 dynamic variants:
- Color: blue, red
- Size: S, M
- Create a quotation with that product (any variant)
- Sales > Products > Products Variants
Your product variant is there
- Modify your product template and add "green"
to colors
- Sales > Products > Products Variants
Your product variant is archived
Cause
The logic which determines which variant
should not be archived is only applied
on products that don't have dynamic variants
See https://github.com/odoo/odoo/blob/820fe9a025e34e81368a189ee295b4abcf9fcbda/addons/product/models/product_template.py#L576
Solution
Do a separate logic for dynamic variants that doesn't compute
all possible combinations.
But being sure that it:
- doesn't archive when adding/removing a value
to an existing attribute line
- archive when adding/removing a new attribute line
OPW-2293346
closesodoo/odoo#55016
X-original-commit: 8517fdfa2605e8d15f5e38f2074ece7ba543d56b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this fix, the search on the supplierinfo had
an undeterministic result.
When testing odoo/addons/purchase_stock/tests/test_reordering_rule.py:66
`def test_procure_not_default_partner`, it may fail at line 120.
It sets 2 suppliers:
- Firstly, the `default_vendor` (let's assume id=120)
- Then, the `secondary_vendor` (let's assume id=121)
It then runs a procurement without setting the supplier and assert
that the partner of the resulting PO line should be `default_vendor`.
The return of
odoo/addons/product/models/product.py:574
`def _prepare_sellers` depends on Postgres when the supplierinfo
sequence, min_qty and price are the same for multiple records.
By adding the `id` to the `.sorted`, the result will order correctly in that
case.
opws-2272627
-2282081
-2287079
And PS-BE via CSC reported more cases without opw.
closesodoo/odoo#53951
X-original-commit: a733feb8e022084148685599840fe542ee9dafd1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Missing super call for product category deletion.
closesodoo/odoo#53699
X-original-commit: ebc75df2b3d3f80aebc2fc1d8500fa57c1755bbd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Updating the uom_id on a product_product will eventually change also the
uom_po_id to have them belonging to the same category. Saving the update
call write() on product with a dict of two values (uom_id and uom_po_id)
As product.product is inherited from product.template, the write() on
the corresponding product_template is called but in this case 2 times
for each values. The first time, only uom_id is updated. The _check_uom
constraint is triggered and obviously failed. The uom_po_id on the
template is not yet updated.
This commit makes the sync in the beginning of write() of product.template.
Which means before calling the constraint.
This commit also makes the onchanges on uom_id acts the same between
product.product and product.template.
Task : 2197818
closesodoo/odoo#48714
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
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.
When importing a file to populate a pricelist applying to a product
category, it is necessary to add a leading space to ` Product Category`
name to match with `2_product_category`.
We can simply remove it.
opw-2271033
closesodoo/odoo#52722
X-original-commit: 11809ee1a12df6b967f03591adb6d11579e3e947
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a new company with it's currency
A default price list has been created for this company in this currency
Install the "customizable Chart of Account" under the settings tab, Accounting
By installing this CoA, Odoo creates a new pricelist, in Dollars,
that overwrites the one in the currency of the country.
Avoid creating the new pricelist if there is already a
pricelist for the current company in the company currency
opw-2221854
closesodoo/odoo#52429
X-original-commit: dc0d6af54f56bf6e576013d67cf44b5cd3608351
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Add sudo in base to allow a unpriviledged user to interact with
ir.property in a safe way usingsetters and getters.
By making them callable without sudo, we encourage to use these
methods instead of making CRUD requests on ir.property directly
For other specific search where no native method exists, add sudo
The business case is the following:
1) The Child company can order the product to the Parent company;
2) The Parent company order the product to a 3rd party supplier.
Settings:
- Enable ‘Inter-Company Transactions’ transactions with the option
‘Synchronize sales/purchase orders’ checked;
- Enable 'dropshipping'.
Set 2 companies:
- Parent company;
- Child company: which belongs to the Parent company.
Set a product 'my purchased product':
- Can be Purchased;
- Product Type: Storable Product.
- ‘Purchase’ tab:
- Set a Vendor price list line 1: which is your Parent company + set
your Child company who can buy the product;
- Set a Vendor price list line 2: which is your 3rd party Supplier +
set your Parent company who can buy the product.
- Log in as the Child company (disable the login in the Parent company,
select only the Child one);
- Place a Purchase Order for ‘my purchased product’ to vendor 'Parent
company';
- Confirm the PO.
Before this commit, an error message appears. The issue arises because
seller_ids is retrieved from the cache and not re-read as superuser.
Therefore, records are missing from the list and the correct seller is
not found.
Now, the correct vendor for the purchase order of the parent company is
selected.
opw-2261971
closesodoo/odoo#51887
X-original-commit: 0a9f0c5d2c85e80dd5dceaeacf3f04bfc8aa0be1
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, pricelist boundaries were dates. It was not possible to get a modified price at a precise time: e.g. modify the formula at 12h00.
closesodoo/odoo#49030
Taskid: 2221094
Related: odoo/upgrade#1055
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When no pricelist property is defined for a customer, we use a search as
fallback, without considering the current companies.
This means you can see the pricelist of company B as pricelist for a
partner, even with company A as main current company (if both company
are enabled in the multi-company widget).
Forward-Port of #46429
X-original-commit: 68040c92c8e09218641d823d690e0ce36dcdef30
Since https://github.com/odoo/odoo/commit/7d8df4bec192e5a2ff3341dcf43d59e06a57f9a9, the groups
managing pricelists features have been updated.
But the onchange feature enabling pricelist on multi-currency activation was wrongly
adapted, it was only activating advanced pricelists, iff basic pricelists were enabled.
The wanted feature is to activate pricelist (basic pricelist features: group_product_pricelist)
when multi-currency is enabled.
Also add an implied_group on multi_currency group to enforce this behavior.
closesodoo/odoo#49633
X-original-commit: f862f9650395b02f6a43c57cdf232a309fa6948e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When the value is the same for all records, the write can be done in
batch, this can lead to a "slight" performance improvement, depending on
write overrides, and how the value was computed for each line.
Steps to reproduce the bug:
- Let's consider an attribute A with two values V1 and V2
- Let's consider a product P with V1 and V2 as attributes
- Duplicate A
Bug:
P was associated with 4 attributes V1, V1, V2 and V2
opw:2219540
closesodoo/odoo#48342
X-original-commit: 1c44aeb7d1734cd7a6dbdb80971f98553c67003b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install purchase_product_matrix, Inventory
- Create a (storable) Product P with default_code e.g. VOB2A
with a vendor V who uses a product_code e.g. VOB2a
- Create a PO/RFQ for vendor V
- Add a product, search "vob2" (copy/paste)
Infinite loop
Cause
purchase_product_matrix replace purchase.order_line.product.product
by product.template so the name_search is different and the
product.template's name_search loop doesn't support the case where
you have default_code == product_code
Solution
Check if the product's name_search returned a product containing
product_template_ids that we did not wanted (as mentionned in the
domain). If yes, it means that we will have an infinite loop so
we should break.
Additional note: the issue could be in versions < 13 but
purchase_product_matrix is only in 13.0 and this is not a
very common case.
OPW-2193005
closesodoo/odoo#47576
X-original-commit: 9d5d80f77bc04be83d5b2ca0569a6ea50e26a07e
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Steps to reproduce:
* Create a template with 2 variants
* Archive one variant
* Unarchive this same variant
--> the template is archived
This is due to commit 6a13b565cbbad89ff1c4177b171b01f30c83edf9. If the
variant is the only one, toggle_active on the variant should be
reflected on the template. The issue is that toggle active do not count
archived variant. One active variant and one archived variant are
counted as 1.
This commit make toggle_active count all variants
closesodoo/odoo#34769
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit when a user archives the product, the barcode
field in its template used to get disappeared.
Since barcode field in template is a related field to product,
the field gets invisible in product template when the user archives
the related product.
After this commit, even when a product is archived,
its barcode will still be visible in template.
Here the barcode field is changed from related to computed.
task-1978559
purpose of this commit is to change the field type
of min_quantity from int to float on product pricelist
object
task:2165208
closesodoo/odoo#45792
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Product templates standard_price (cost) is company_dependent,
because the product_product standard_price is company dependent.
closesodoo/odoo#47041
Forward-port-of: odoo/odoo#46841
X-original-commit: 30ee9f1ac411aca9c2bf2158fca9be7db743616d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue: on main product's kanban, if you group by categories, all
categories (even the empty ones) appear. This is not desired.
We only wanted this group_expand logic when using the products stat
button on the product category form view.
closesodoo/odoo#46966
X-original-commit: e3f1254e5b28aa801f137835d871427786fb3428
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The default product category and uom should be fixed on generic
undeletable records (in data files).
And by caching those default values, we can gain up to 20% time when
creating products without providing uom and categories.
Also remove the unnecessary defaults on the compute fields, which do the
same as the compute (and have no use because it is a non stored field).
closesodoo/odoo#45791
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Delete the uom 'kg'(kilos, kilograms), open a product form view
Traceback will popup because the hardcoded xmlid cannot find the value
in the database since has been deleted. Adding a fallback fix the issue
opw-2194659
closesodoo/odoo#45265
X-original-commit: 62baf8ba12cdf4521c6d0d0fea61ff1aa2e3f4d8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate variants and pricelists
- Go to Product > Products Variants
- Search for anything on the 'Pricelist' filter
A traceback is raised: 'Can only create cache keys from hashable
values...'.
This comes from the following change:
https://github.com/odoo/odoo/blob/4b06fe19fa68255b7982d15e5847da2f6d6209fd/addons/web/static/src/js/views/control_panel/control_panel_model.js#L962
It returns a list instead of a string. Since a list is not hashable, it
causes the issue.
There are not much solutions since the context key `pricelist` can be a
`list` or an `int` (an ID). We force the cache key conversion to a tuple
to avoid the `TypeError` and handle the `list` use case (which was
broken on top of crashing).
opw-2187757
closesodoo/odoo#45064
X-original-commit: ec0a8767143b4c4818418281803c4f52fefa8d2a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Use the 'Volume' decimal precision on all `volume` fields.
Complement of commit c1a5221ba2
opw-2185374
closesodoo/odoo#44473
X-original-commit: dc0111d6cdf4032fa840f9ff95f4fa687d33f77c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this commit is pricelist/pricelist item can not
created/modifided linking records of diffrent companies together
closesodoo/odoo#44391
Task: 2090409
X-original-commit: 9b62813cddb2726003b4b989c32185400059dfa1
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Sometimes when we try to buy a product that doesn't have any variants,
it would result in an error saying there isn't any valid combination
for that product.
This was happening because `_get_variant_id_for_combination` was
considering that the field `combination_indices` would always be
equal to `''` (empty string) in such a case.
This isn't true as `combination_indices` isn't a required field
thus allowing `null` \ `None` to be valid values for that field.
This fix will simply include products with no values set for their
`combination_indices` when searching a corresponding variant from
the `product_template`.
closesodoo/odoo#44056
X-original-commit: 03e7efc3b4592c5f063c665130011a91fcc4d683
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Unfortunately caught in a really wide try/except clause where it was
completely silenced, causing a lot of stuff to be archived instead of
deleted.
closesodoo/odoo#43543
X-original-commit: cfa2993615150416b801ce942f18339065678648
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Since [1] `computer_hdd_attribute_lines` is archived instead of unlinked in
`TestSaleProductAttributeValueConfig` which leads to indeterminism in tests due
to the missing `flush`.
Indeed `flush` is necessary before `invalidate_cache` since [2] if the data
that are pending being written must be saved to the database before the cache
invalidation.
[1] which highlighted the issue was merged after v13.0, but it still makes sense
to merge the current fix in the earliest version possible.
[1] 5361706e5e
[2] 9920f20e4cclosesodoo/odoo#43483
X-original-commit: f721bfe2860293d1456770d57be7805920929ca0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, empty strings and False have different meaning when assigning
a Char or Text field with ORM methods.
So avoid setting empty string on `default_code`.
opw-2151849
closes#41662closesodoo/odoo#41674
X-original-commit: d038cc1a0a6e1d939318763aa9dba48aa1eafcf5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When computing the price of a product through a pricelist item, if the
item was based on anotherp pricelist, the dates and uom weren't given to
the subsequent method call.
As the majority of the calls to those pricelist methods put all their
arguments in the context, it wasn't noticed until now.
Functional example:
Pricelist A:
Rule A1 : 10% discount on Pricelist B, from day 3 to day 6.
Pricelist B:
Rule B1: 5% discount on Sales price, from day 3 to day 6,
Rule B2: 10% discount, from day 7 to day 9.
If today was day 8, the call to pricelist(A)._compute_price_rule(day=5)
would use rules A1 and B2, but should have used rules A1 and B1.
closesodoo/odoo#41295
X-original-commit: df9b113805ed28f274711bb4ba0dd9a2610e5035
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
steps to reproduce:
-change decimal accuracy for "Product Price"
-create a price list with fixed price
-the fixed price field does not takes the decimal accuracy into account
this was working in V11 and V12
fixed_price was a float field like other price fields
previous behavior:
fixed_price is a monetary field
when setting up a fixed price for a pricelist, it takes into account
the precision from the current currency
current behavior:
fixed_price is a float field
when setting up a fixed price for a pricelist, it takes into account
the proper decimal accuracy setting ("Product Price")
opw-2121964
closesodoo/odoo#40807
X-original-commit: 27b90fc7389cfc7fe4a9f4f17dea74283a45af44
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.
Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.
So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.
The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`. We added a method `set_default` to set generic properties,
and its implementation does the right thing. It also simplifies the
code to set such properties, by the way.
closesodoo/odoo#40473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
nans