Reproduction:
1. Create a dynamic attribute "dyn_att" with a couple of values
2. Create a product template "dyn_prod" with those attribute values
3. Create an order for "dyn_prod", this will trigger creating a variant
4. Make sure to check Variant Grid Entry in Sales Settings
5. Open variant form view of dyn_prod and edit it to allow duplication
6. Duplicating it leads to an error
Reason: copying the variant is not possible and disabled here:
https://github.com/odoo/odoo/pull/38303 For future convenience, maybe
it’s better to give a temporal working solution. The function
_create_first_product_variant is used in the product module but only
defined in its child module website_sale
Fix: copy the product template, create and return its first possible
variant. Added test for dynamic variant copy. change the definition
place of _create_first_product_variant to module product
opw-2790543
closesodoo/odoo#98809
X-original-commit: 34a2948d3d6e0f597c1b5d65f9f118e891c07cc4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
Since #96791 the currency is reset to USD when starting a test to be
less dependant of demo data when starting tests.
Unfortunatelly, some l10n_modules will add account.move.line demo data
leading to an error:
You cannot change the currency of the company since some journal
items already exist
An initial solution would be to delete the existing account.move.line
cls.env['account.move.line'].search([('company_id', '=', company.id)]).unlink()
This is only possible passing some context flags in order to disable some checks
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
Actually, unlinking account.move.line also creates other ones.
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
Finally, it looks easier to bypass all business logic leading to the proposed solution.
closesodoo/odoo#98736
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* commons & setup refactoring:
* convert setUp to setUpClass
* move setups where needed (stock/mrp commons or specific test
classes)
* create test data in batch (faster, less sql queries & batched
operations)
* move most tests post-install to allow runbot splits
* by default, run tests without mail logic
* by default, run tests in a consistent environment (fixed currency
imposed in the BaseCommon)
* refactor existing tests to use new commons data (while trying to keep
diff reduced)
* add dedicated test file to test the common data
* use mute_logger to reduce useless test logs (less spam to scroll in
logs, less data on runbot builds, ...)
Part-of: odoo/odoo#96791
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The test 'test_inactive_related_product_update' raises a ValueError
"Wrong value for product.template.detailed_type: 'product'".
(which causes the L10n nightly build many fails)
See https://github.com/odoo/odoo/pull/89468closesodoo/odoo#90339
X-original-commit: d0ff5fe311cd69a3068593142aff66b09f13c43d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
When filtering on product templates with a negative operator, the
result
is incorrect
To reproduce the issue:
(Need mrp)
1. Create two products P_compo, P_finished:
- Internal Reference:
- P_compo: 123
- P_finished: 456
2. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
3. Manufacturing > Master Data > Bills Of Materials
4. Remove search filters and apply this custom one:
- "Product doesn't contain 456"
Error: P_finished's BoM is still in the list, but '456' is the internal
reference of P_finished, so this BoM should not be displayed
The filter is applied on the field `product_tmpl_id` of the BoM, which
leads to the override of `_name_search` in `product.template`. In this
method, a call to the `_name_search` of `product.product` is executed:
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L456
which is a good thing because the version of `product.product` handles
the case of the Internal Reference (`default_code`)
https://github.com/odoo/odoo/blob/1e8982e4cf6b604e4da2773f10bdf6cf94c7e683/addons/product/models/product.py#L532-L538
So, the call to this `_name_search` will not return P_finished. However,
later on in the `_name_search` of `product.template`, we call the
`_name_search` of `super` with the same domain (i.e., 'not 456 in name')
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L474-L485
This is the issue: it leads to the `_name_search` of `BaseModel`, which
is the classic version: it does only consider the record's name. So,
this call will return P_finished.
In the `_name_search` of `product.template`, there are actually two
calls to `super`. Considering the commits [1] and [2], it seems that the
goal is the same in both cases: find the `product.template` that do have
any variant yet. However, in the first commit, the domain given to
`super` excludes the templates that have at least one variant, which is
not the case with the second commit (the "problematic" one).
Since both codes have the same goal, we should merge them by keeping the
best idea of each one. From [1], we keep the idea of restricting the
domain: we only look for templates that do not have any variant.
However, this domain needs to be improved: we need to include the
templates whose all variants are archived. From [2], we keep the idea of
looking for the templates outside the `while True` loop. This allows us
to do the search only if required.
[1] 21ae503
[2] 99bae2c
OPW-2791255
closesodoo/odoo#90248
X-original-commit: 942814844e982cbaec2329709c6ba9dd810d0c3f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create a product attribute “PA”:
- Variants Creation Mode: Never
- Value: “PA1”
- Create a storable product “test”:
- Add the attribute “PA“ and the variant “PA1”
- Save
- Archive the product and then remove the attribute from the product
- Unarchive the product
So the product has no longer the attribute line but if we check the
attribute itself, it is still having the product as a related one.
Problem:
When we remove the line attribute, the `_compute_products` is called,
but as the product “test” is archived, when we try to access the
related products of the product attribute, it returns an empty recordset
because the ORM only returns active records.
Since the attribute `product_tmpl_ids` seems empty and we try to update
it with an empty value, the ORM considers there is no change and so, it
does not update the field value in the DB.
Solution:
We must use `active_test=False` when accessing the related products, so
the ORM returns all records, active or archived.
And since there is indeed a linked product and we are trying to
overwrite it with an empty recordset, the change will be effective.
opw-2806316
closesodoo/odoo#90166
X-original-commit: 7d304078b4ed97d23ec84609e6aea137e8500a18
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, Barcode was not displayed on template
when related product variant is archived.
Here we are making sure that even when a product is
archived, its barcode is still visible in template.
closesodoo/odoo#89363
X-original-commit: f0c7cde3938c01df5fc10bb8dcd72fd3bb18afdb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When using a pricelist with a currency different than the one
of the product, the surcharges, max_margin and min_margin must use
the currency defined in the pricelist.
These tests intends to ensure that this behavior is respected.
This behavior was in fact not present (and a fix was created in stable releases)
in previous releases (before the refactoring 57ced812f0).
To reproduce the issue:
1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity.
2. Create a formula pricelist with the newly activated currency using either surcharge or the margin.
3. Create a SO with a standard product. By switching between pricelist, you will see an invalid price.
E.G.:
EUR_rates = 2 compared to USD PRICELIST = surcharge of 10€ on any product
PRODUCT_price = 300$ PRODUCT_price_euros = 150€
CURRENT_SO_price = (300 + 10)/rate_EUR = (300 + 10)/2 = 155€
EXPECTED_SO_price = (300 + 10*rate_EUR)/rate_EUR = (300 + 10*2)/2 = 160€
Solution:
Convert the pricelist item margin & surcharges to the base price currency.
To do so, the needed currency conversion date is given through the context.
opw-2760720
closesodoo/odoo#88243
X-original-commit: 20140e8f53633cfdf7a7147bad6055dcd707a778
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Previously, product barcodes uniqueness was enforced
by a SQL constraint, resulting in a generic error message.
The SQL constraint has been replaced by a Python check,
which allows the listing of conflicting barcodes in the
error message, including those resulting from batch edits.
Task: 2654703-7
Part-of: odoo/odoo#84056
Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.
Solution:
When an exclusion is created, archive all the not-possible-combination.
OPW-2729329
closesodoo/odoo#84883
X-original-commit: 91642f4e29beb89d110084a20443fb300ee26530
Related: odoo/enterprise#24512
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some aggressive cache invalidation in the middle of method write() where
the model has children models (in the _inherits sense) causes very nasty
errors that are hard to fix.
Consider two models A and B, where B inherits from A. Also consider two
fields a1 and a2 on A, which are thus both inherited by B. Now take a
record from model B, and update both fields as:
record.write({'a1': ..., 'a2': ...})
As both fields appear as related fields on model B, the method write()
puts all values in cache, then it proceeds to call the inverse method of
both fields. The inverse method of a1 is called, and this writes on the
parent record. Now imagine that some override on A invalidates the
whole cache. When the inverse method of a2 is called, the field's value
on B has been invalidated, and this therefore writes the value False on
the record's parent.
This patch removes and adapt such cache invalidations:
- Since 4b1cb41cf7, the cache invalidation
in method write() of product.product is no longer necessary.
- The cache invalidation in method write() of product.pricelist.item
has been removed as well, since field that needs to be recomputed no
longer exists.
Fixes#76946, #77042closesodoo/odoo#82958
Opw: 2657461
X-original-commit: 5a73a8a3697c0f2685471efa252e5eb1af738e83
Signed-off-by: Raphael Collet <rco@odoo.com>
Since [1] whenever the image of a `product.template` is updated, the
write date of all its related `product.product` is updated. This was
done to force a change of the unique parameter on image fields, which is
based on the last update field.
After this commit the `product.product`'s last update is instead
computed by also taking the `product.template`'s last update into
account. This avoids the need for updating the write date when the
image is changed, but on the other hand it also forces product images to
be reloaded whenever any other field of the `product.template` is
changed.
[1] https://github.com/odoo/odoo/pull/71139
Related to https://github.com/odoo/odoo/pull/76309
task-2477438
closesodoo/odoo#78356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
- Create a report to show price on each template
--> Issue: The price is the same
closesodoo/odoo#78870
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, products relying on values of template fields (i.e.
image) were not considered updated when their fallback template field
was updated.
After this commit, upon update of a template image, all products that
would fallback on that template are "touched".
This avoids side-effects such as displaying an outdated template image
in the e-commerce for a given product.
task-2477438
closesodoo/odoo#71139
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'
But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.
tl;dr: `display_name` was ignoring the context once cached.
One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.
task-2517830
closesodoo/odoo#70739
X-original-commit: b5b4d38adf1f3960cda21b795a26e67b978b2901
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The function `_get_possible_combinations` generates possibles combinations
for the product template attribute values (ptav) of each product template
attribute line (ptal) of a given product template. It used to iterate over
them using a cartesian product. A combination can be invalid if it
contains two incompatibles ptav. The problem is that it used to filter out
invalid combinations after generating them. It's a problem because there
can be a lot of invalid combinations to filter out before finding a valid
combination. Even before the first valid combination if the first ptav of
the two first ptal are incompatible.
The solution brought by this commit is to reject the invalid combinations
while building them rather than after. It does so by using a cartesian
product implementation with early rejection. The algorithm tests each
ptav when incorporating it in a partial combination and if it's
incompatible, it goes to the next partial combination and thus skips all
combinations starting with the invalid partial combination.
The client that reported the issue has a product template with about 25
ptal with an average of 9 ptav. The ptav of the first ptal was
incompatible with the first ptav of second ptal. It had to build and
filter out 5.76*10^15 ptav before finding the first valid ptav. If we
generate 10^6 ptav by second (it's much less) user would get first ptav
after 182 years. Now it's instantaneous.
opw-2335936
closesodoo/odoo#65809
X-original-commit: 98616c4676aa6ef5507110c0e407a640082abbaf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
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>
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>
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>
Since the wizard to set a logo and chose a layout has been removed, we
don't need anymore to throw an error if they are not set because the
report can be generated.
closesodoo/odoo#48831
X-original-commit: b7c7039667d9ec816e647a0dd30570a4a690cca2
Signed-off-by: pimodoo <pimodoo@users.noreply.github.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>
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>
Replace an assertRaises(StopIteration) by a next() with a default
value.
Following PEP 479, *any* StopIteration reaching the toplevel of a
generator triggers a DeprecationWarning. And while the assertRaises
looks innocuous, both _assertRaises and the underlying
clear_upon_failure are implemented with functools.contextmanager,
which wraps a generator.
As a result, exceptions raised in the assertRaises "body" get
reinjected inside the wrapped context manager[0] and if the exception
is a StopIteration it triggers the warning.
By not using assertRaises we side-step the issue.
[0] https://github.com/python/cpython/blob/b6999e5690c7006b0ba4049cfd638513c982a90c/Lib/contextlib.py#L131
Variants are generated depending on the configuration of attributes
and values on the template, so copying them does not make sense.
For convenience the template is copied instead and its first variant is
returned.
closes#38151
X-original-commit: 259f3b7fcdb88d1f458ee7ea3667964412b88ea1
In an onboarding situation, the company doesn't have a logo
make an invoice, send and print, print
The document layout editor's layout opens, because nothing is set up
on the company
Click Save
Before this commit, it was impossible to make the invoice print
because each time the document layout was displayed
After this commit, the invoice prints when clicking on Save
There is no default external layout for main_company
Also, the heuristic used to evaluate whether a company
has been set up, onboardingly speaking, has changed.
Before we used the existence of the logo, after we check if
a layout has been setup. When saving the document layout
modal, a report layout is written on the company
So, practically, the document layout modal only appears once
when trying to print invoices (or other documents)
closesodoo/odoo#37137
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a product template, assign a dynamic attribute to
(the corresponding variant will be created when used in a SO)
Try to name_search for it
e.g.: in the product configurator modal, type some letters to catch it in theory
Before this commit, the product template was not found by the name search
this is because the template doesn't have any variant yet
After this commit, it is found by the name search
OPW 2060603closesodoo/odoo#36215
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
* account, hr_expense, mrp, sale, sale_product_configurator, stock_account,
website_sale, website_sale_comparison
Before this commit, the `product.attribute.value` were stored on the variants.
This required filtering of attribute lines to find the appropriate matching
`product.template.attribute.value` that were used in most of the business code,
such as when computing the `price_extra`.
This also prevented to have multiple attribute lines for the same attribute,
which is needed to handle use cases such as grape varieties for wine products.
This will be done in the following commit.
After this commit, the combination of `product.template.attribute.value` will be
directly stored on the product variant.
Other changes
=============
Add `combination_indices` on product, which allows to quickly find a variant
matching a combination (1 simple indexed equality query as opposed to 1 query
with as many joins as there are attribute lines), and to add an easy
SQL constraint to ensure active combination uniqueness.
Add active field on `product.template.attribute.line` and
`product.template.attribute.value`, with the same behavior as variants:
They become archived if they can't be unlinked. This allows to keep the database
consistent, such as archived variants correctly keeping all their values, sales
order lines keeping their custom and no_variant. This is done with the help of
`ondelete=restrict` on the corresponding m2m fields, and the `unlink` methods
falling back to archiving when `unlink` is restricted.
Part of task-1912579
PR: #32946
Manage pricelists through a common configuration between sale and point_of_sale
Remove lots of technical fields
Improved Pricelist Flow
-----------------------
if pricelists enabled (product.group_product_pricelist), two modes are proposed:
* basic(default): pricelists enabled, but only with basic rules
* advanced: pricelists enabled, but with advanced rules (product.group_sale_pricelist)
When pricelists are enabled, we can always access them through the menu OR access their product-targeted rules from the products/templates views.
Follow up of 58a2ffa26f
Variant specific field `image_raw_original` was meant to be renamed to
`image_variant_1920` instead of `image_variant_max` to follow the same naming
convention as the other fields (having the pixel number in the name).
closesodoo/odoo#35493
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Usability improvements:
- Prevent the user from doing actions that will lead to exceptions.
- Improve error messages when exceptions do happen.
Also add more constraints to keep the database in a consistent state.
task-2035609
closesodoo/odoo#34833
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Create a product template Pt with attibutes A1, A2,
respectively with values Va1_1, Va1_2, and Va2.
This should make 2 variants, V1 and V2.
Sell some of these variants.
Then they can't be deleted since they are linked to orders/invoices/...
Now delete attribute A2. We know that:
Warning: adding or deleting attributes will delete and recreate existing
variants and lead to the loss of their possible customizations.
In fact, old variants are only archived instead of deleted:
for variant in variants_to_unlink: ... variant.write({'active': False})
as a fallback.
Now add again the attribute A2 to Pt.
It creates a new variant with the correct attributes.
Since the product is not active and has valid attributes and attribute values,
it is reactivated.
As a result we get the same variant twice.
Here we can simply add a check: if there is already an existing variant with
the same values, we can skip this activation.
We add a tiny little test to make sure that we have correct number of variants.
It's basically unreadable but somewhat commented.
fix coauthored with @rco-odoo
opw 2029985
closesodoo/odoo#35013
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Jinjiu Liu