Some clients use the same barcode for products in different companies,
with different configuration. It is inconvenient for those users to have
to ensure the uniqueness of barcodes across all companies.
This commit will allow products to have duplicated barcodes, as long as
they are assigned to different companies. Products without a company are
treated as belonging to all companies. Product variants require unique barcodes.
The validation needs to be triggered both on barcode and company_id, so
product template (where company_id is stored) was also adjusted.
NOTE: when a barcode is duplicated in 2 companies, an attempt to remove
both the company and the barcode from a product will result in an
error, despite the fact that a product without a company and a barcode
would have a correct configuration. This happens because the barcode
uniqueness check is performed before changing the barcode, but after
changing the company. A workaround for this problem is to remove the
barcode first, save the product, and remove the company.
Task: 3290154
Related task: 3270732
Related: odoo/enterprise#42541
Part-of: odoo/odoo#122511
Steps to reproduce the bug:
- Enable “Product packing” in the inventory settings
- Create a storable product “P1”
- Add a package with barcode “123”
- save the changes
- Delete the package
- Try to set the same barcode “123” for the product
Problem:
A validation error is triggered: "A packaging already uses the barcode"
Solution:
When we delete the package from the product, we have to delete
completely the “product.packaging" record.
opw-3378288
closesodoo/odoo#131825
X-original-commit: d01d8a9cedec2d1c17469538103340fc934470f1
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behaviour:
After archiving the public pricelist (14.0 to 16.1,
as 16.2 does no longer have a public pricelist),
when creating a new pricelist, it replaces the previous
pricelist with all partners.
1 Second pricelist
2 First pricelist
Expected behaviour:
New pricelists should go after the previous one
1 First pricelist
2 Second pricelist
Steps to reproduce:
1. Go to settings, activate Pricelists
2. Head over to Sales->Products->Pricelists
3. If applicable, archive the public pricelist
4. Create a new pricelist (named 'First')
5. Create another pricelist (named 'Second')
6. Go to Contacts, select any contact
7. In Sales & Purchase see Pricelist
8. Second pricelist is set, should be First
Cause of the issue:
_order is set to "sequence asc, id desc"
Since new pricelists have a sequence of 16 by default,
new pricelists (with a higher id) get placed first.
Fix:
New pricelists without a sequence number get sequenced based on the
highest sequence number in existing pricelists
opw-3282880
closesodoo/odoo#121441
Related: odoo/enterprise#43591
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
In specific situation, unlink can lead to raise a `RecursionError`:
- The model `A` has a many2one `b_id` field toward a model `B`.
This field is set with `ondelete='cascade'`.
- The model `A` has one **store** related field **no-sudo** named
`a_related` (`related='b_id.b_other_field`).
- With `ir.rule` on model `A` with a domain containing `a_related`
You have one record B `b_1` with 20 records A linked to it
(`a_1, ..., a_20`). When you try to unlink `b_1`:
Stack:
File "...", line 543, in ...
b_1.unlink()
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3594, in unlink
self.env.flush_all()
=> At this point, `a_1, ..., a_20` have already been deleted from the
database because of the 'cascade' deletion. But the ORM doesn't have
any information about this, and `a_related` (for `a_1, ..., a_20`) are
flagged to be recomputed (because it depends on `b_id.b_other_field`)
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
self._recompute_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
=> `self.compute_value(recs)` raised a `MissingError` before recalling
`compute_value` with only the first `record` (but others are still in
the prefetch)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
=> `a_related` of `record` is removed from to_compute, but only the
first record, not the rest of the records present in the prefetch set.
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
=> `_read` tries to read the first record + others from the prefetch set
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
self.with_context(active_test=False)._flush_search([], order='id')
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
self.env[model_name].flush_model(field_names)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
self._recompute_model(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
self._recompute_field(field)
=> This is where the recursion starts, record compute will move forward
one by one. But sadly, the stack grows very fast, and with only a few
(already deleted) records to recompute, the issue will be generated.
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
self.with_context(active_test=False)._flush_search([], order='id')
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
self.env[model_name].flush_model(field_names)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
self._recompute_model(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
self._recompute_field(field)
How to fix it:
Move the logic of the MissingError of `_recompute_field` inside the
`recompute` directly.
X-original-commit: c2aac02ac4f8c5cc4a9324134535393bd97338ce
Part-of: odoo/odoo#122147
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
It is currently not possible to write the barcode of an archived
product template. The inverse method does not consider case where
the variant of the template is archived
OPW-3109967
closesodoo/odoo#110697
X-original-commit: 968d0dff823f8e5d0871feaf8b09233fbb91b4de
Signed-off-by: Adrien Widart <awt@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Since https://github.com/odoo/odoo/commit/3752b3166ec6bbb5c6ea55f96bb521381bf2b2d9,
the currency of the test architecture is not fixed anymore to USD (but is by default).
Therefore, the nightly runbot tests of the localization (l10n_* modules) all fail
when verifying the company currency is USD (because the localization sets the company
currency to the country one).
This commit adapts those checks to stop enforcing the USD currency as base,
only enforcing that the currency used is the company one.
closesodoo/odoo#109807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
STEPS: Create a Pricelist with price rule discount-based on parent product
category. Result: the price rule discount is not applied if the product is not
directly attached to a parent category.
Fix it by correcting domain in `_get_applicable_rules_domain`.
Also, update tests: use parent category in the pricelist.
https://github.com/odoo/odoo/commit/dc8db07ba718a2de845455efc6e265213537eedf
opw-3080836
closesodoo/odoo#107769
X-original-commit: ce44c045f6b75fa64962625baad322632a9c2979
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
Jigar Vaghela