The changes concern the following modules:
- sale
- sale_product_configurator
- website_sale
- website_sale_product_configurator
When optional products are enabled and a user adds an item to the cart, the
modal popup does not allow further modifications to the main product based
on its template. If the user wants to change the color or the material, they
have to close the popup, modify the product and open it back up.
The same is applied when Add to Cart is active, and the user cannot configure
the product at all after clicking the add to cart button.
This change will make it possible to change the product variants without having
to close the modal, and configure the product when using the "Add to cart"
button when it's enabled.
The added configuration step is needed for some cases like the following:
1. When adding a product that had variants directly from the /shop page before,
the first variant was added by default and configuring it was impossible without
explicitly going on the product's page and configuring it from there. This
behaviour made no sense, and it's the reason the "optional products modal"
(which should no longer be called that) is opened when the product is not
configured even if there are no optional products.
2. When going through the product's page, and there are optional products enabled
for the product getting configured, then it's nice but not necessary to be able to
configure the product further while choosing and configuring the optional products.
This doesn't add an extra step in any case, it just makes it possible to still configure
your product in the modal.
3. If there are no optional products, the configuration made on the product's
page is taken into account and the product is directly added to the cart without
opening the modal, which is the same behaviour as previously.
Only one modal is shown, depending on the situation:
- For the website flow, if the product is not configured and has variants or has
optional products (or both), a popup shows that allows for configuration +
choosing and configuring optional products.
- For the sales flow, there was already a configuration popup, so the optional
products modal is only shown when there are optional products and replaces
the first instead.
Some tests were adapted to function with the new product configuration modal:
- The steps checking for the text mentioned above are removed
- Triggers were adapted to the modal for products that were previously added to cart
with their default variant
- Various other small adjustments
task-2541663
closesodoo/odoo#73086
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Using `sale_product_matrix`'s tour as `product_matrix` doesn't
actually have any test for this.
Remove t-raw from the product_matrix(.extra_price) template, by moving
the formatting to the client side (unclear why it was done by the
server in the first place).
Also fixes a bug where a negative price_extra would have *two* `-`
signs: one before the currency, and one after the currency: the price
being formatted should be abs'd to avoid a negation being generated by
the monetary formatting. Also uses non-breaking spaces everywhere
where the server-side formatting mixed breaking and non-breaking
spaces. Keeps from the original the peculiarity that the extra price
should always have a sign positioned before prefix currency signs.
Also changes the calling conventions of `product_matrix.extra_price`:
instead of being called with a formatted `price` it's now called with
the entire cell object.
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closesodoo/odoo#64683
X-original-commit: 69cadbe1be6320d96fe9bc5bf8dd808f87d735c0
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create a price list with a foreign currency;
- Create a product with some variants;
- Configure the variants and make at least one of the variants with
extra price;
- Set the 'Sales Variant Selection' with 'Order Grid Entry';
- Create a new quotation with the foreign currency price list;
- Add the product just created to the quotation.
Before this commit, an error is raised, because the currency convert
need a valid company id.
Now, the order grid entry is shown.
opw-2329658
closesodoo/odoo#58415
X-original-commit: bf325b60d24b7045e8bfb3f16be2476889368926
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Probably since recent js framework changes, when trying
to modify the matrix of a product on a new SO (not saved),
a js error was raised (wrong qweb template rendering).
This is due to a wrong check when loading the matrix data,
in the case of a new record, the data wasn't correctly updated
on all widgets, resulting in an opening of the matrix with the results
of the last matrix changes (since the information is transferred in the same field).
This commit:
* Ensures that the correct data is taken to open the matrix (solving the main
problem of matrix update on new records)
* Improves test coverage to cover untested buggy situation
* Fixes another error found while improving test coverage:
The edition of existing quantities was wrongly creating new lines, instead of updating
existing ones. Simplify lines comparison to ensure the matrix won't generate two lines
for the same variant combination.
closesodoo/odoo#54917
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the product 'My Company Tshirt' had too much PTAL and PTAV which lead to an overloaded matrix.
This commit removes the 'Sleeves' attribute, reorder the other attributes and remove the Size attributes '2XL' and '3XL'.
task-2052537
closesodoo/odoo#37543
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, it wasn't easy to find a demo product template that opens either with the product configurator or with the matrix from a list view.
To fix that, this commit appends '(CONFIG)' to the name of all demo product templates that open with the product configurator and '(GRID)' to all demo product templates that open with the matrix.
task-2052537
* 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
Don't show "Not Available" as Line header when there is only one
attribute line on the product.template.
closesodoo/odoo#35586
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Martin Trigaux