In case where no argument is given to _compute_price_rule, it would default to
context_today().
This gives "today" in function of the context, depending on the user timezone.
In contrast, an explicitly given date would always be UTC.
Furthermore, on the webshop an unlogged user would get the Public User timezone,
and once logged would get its portal user's timezone.
To make everything coherent, we always use UTC.
opw 2054881
closesodoo/odoo#37154
X-original-commit: 35d4a8ccce8f3a34701d231e17a324cbbf5abfab
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Go to Sales app and open the form view of a product P
- With studio add the field display_name in the view
- Try to create a new product
Bug:
A access error was raised because a read was made on a record in cache
opw:2070074
closesodoo/odoo#37133
X-original-commit: 90143c18f50ff31ded5aba7d7ba3beb66423ff06
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
* = point_of_sale, sale_management, sale_product_configurator, stock,
website_sale, website_sale_comparison, website_sale_wishlist
- Remove Attribute Values menu to ease onboarding because everything can be done
more cleanly through Attributes menu.
- Remove unwanted new lines from help texts.
- Hide color fields when attribute type is not color.
- Move Attribute "Related Products" into a tab because it is less important than
the rest of fields.
The opportunity is also taken to rename the `type` field of `product.attribute`
to `display_type` to better convey its meaning.
task-2058142
closesodoo/odoo#36313
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Let's consider the storable product P and the vendor V
- Set V as a supplier of P
- Archive V
- Go to product P and click on button "Replenish"
Bug:
A RFQ was created with the vendor V
Now when archiving a vendor V, all the product.supplierinfo records linked to V
will be archived.
opw:2066616
closesodoo/odoo#36672
X-original-commit: 5040c17e873b8476c754f1f3e1686c2a02b36e48
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
To avoid slowing down search like "{relational_field}" contains "{value}"
we always need to return the lazy name_get() for each [_]name_search method
closesodoo/odoo#36735
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Validation and user errors do not support
html tags anymore.
This commit removes the last strong tags present in
such errors.
Task ID: 2061442
closesodoo/odoo#36231
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Same reasons as in c3adeb8420
You can not have a field that is:
- computed
- stored
- translatable
One of the three had to be removed
closesodoo/odoo#36717
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With the new ORM, x2m records are not ordered by default.
The _select_sellers implementation requires to loop on the supplier info
records ordered by their _order. We fix that by sorting with a lambda
with the same order set on the model. Simply using .sorted() isn't
enough since it does a sort in sql, so newId records are completely
removed from the resulting recordset.
This is related to task 1947351 and PR 34049.
We move the tests into purchase_stock and actually implement the tests
proposed in the task.
Create a pricelist with a temporary discount on some product only for today.
Go to the shop. The discount is applied on the product.
Add the product to the cart.
Go to the cart page (review order): the price does not use the discount.
Because the query getting the pricelist item is some handwritten SQL,
it only works for dates, and not e.g. in the case of datetimes.
So the pricelist item encoding the discount is not retrieved, and thus not used.
It turns out e.g. in _website_product_id_change it gives a datetime in context,
explaining why sometimes the discount is applied, and sometimes not.
We use fields.Date.to_date as it should work on all date formats we shall pass.
Co-written with @sbbaro
opw 2054881
closesodoo/odoo#36453
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
One of the little advantages of sharing pricelists
(putting company False) is that we can use it also
to create an invoice in another currency in any of
the companies.
Before, when you adapted a company to use another currency,
it sometimes created a pricelist with and sometimes without company.
Now, we always share it.
We also need to create the associated properties in sudo
as you want someone with access to changing the "Companies"
to be able to add these properties even if the company is
not in the allowed companies at that moment.
closesodoo/odoo#36602
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Have a pricelist Pl set as property_product_pricelist on some partner Pa.
Archive Pl, so that the public user Pu use another pricelist Pl'.
Go to the shop, create some order.
The prices are obtained from Pl'.
Log in as Pa; prices are updated using Pl.
However since Pl is archived, it is not visible on the pricelist views,
so the end user cannot explain why the prices changed.
When the pricelist is archived, nothing is done regarding the ir.property
storing the partner/pricelist mapping, so the pricelist is retrieved as default
nonetheless.
We filter out the active pricelists when getting the property.
opw 1946476
co-authored with JKE-be
closesodoo/odoo#36389
Signed-off-by: Nans Lefebvre (len) <len@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>
* = 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
`product.template.attribute.value` now retain to which
`product.template.attribute.line` they belong to. This allows the inverse
relation (o2m) to work out of the box instead of relying on a compute.
This is easier to maintain, faster, better for data integrity, and a necessary
step towards allowing multiple lines with the same attribute.
Part of task-1912579
closesodoo/odoo#35866
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Each model of the relation can define `ondelete` for its `column2` foreign key.
This way the behavior is similar to m2o where the target of the `ondelete` is
the `comodel` foreign key.
Some models were already defining `ondelete` 'restrict' on m2m fields and after
review it appears the behavior introduced in this commit is the expected
behavior for them.
The 'restrict' from product.product has to be removed however because the rest
of the code needs adaptation now that it is properly restricted. These changes
will be done on a separate PR.
closesodoo/odoo#35654
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
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>
part of product_configurator logic moved to product to be accessible in purchase even if p_configurator isn't installed.
And adapt configurator to be extended by matrix
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
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
Christophe Simonis