render, render_template, load, activity_schedule_with_view, get_website_pages should all be private: It should not be possible to render an aribtrary template only with its name or id Still need to render some qweb views from js so the method render_template is kept public. This explains why the website editor still need read access on ir.ui.view as we want to allow any snippet to be rendered.
preparation for cleaning of v13 task-2065018 closes odoo/odoo#39051 X-original-commit: 8a0fc6476c70a4126043de3b3efbd1096e41f968 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = sale, website_sale, website_sale_comparison Purpose ======= This allows to handle use cases such as grape varieties for wine products where multiple values need to be set for the same attribute, but they are all informative and should not generate a choice or variants. The general logic that existed previously is kept: - multiple attribute lines on a product behave as an AND between them - multiple values on a line behave as an OR between them Example ======= To generate 2 variants, with one possible value for each: Line A: val 1, val 2 To generate 1 variant, with both informative values on it: Line A: val 1 Line A: val 2 Technically =========== - remove the constraints that prevented this use case from working since the refactoring done in the previous commit removed the ambiguity when two different lines have the same value - update the product and comparison views accordingly Extra ===== - make the attribute category translatable and improve its list view Final part of task-1912579 PR: #32946 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> Co-authored-by: Juhil Somaiya <jso@odoo.com> Co-authored-by: Sébastien Theys <seb@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
Use category sequence to order them instead of their order of appearance in the list of sequence ordered attributes closes odoo/odoo#35610 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When comparing product, there was already an exceptions that would not list the attributes if they were only "create_variant=False" type. But if we mix attribute create_variant False or not on a product, we could get an error. With this changeset, create_variant=False attribute are ignored also when mixed with create_variant=True attributes. opw-1946361 closes #31680 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
closes odoo/odoo#30221
closes odoo/odoo#30238