Since the commit allowing all list views to be editable, there are some
views in which we need to ensure that certain fields are always readonly.
Affected modules:
- account
- crm
- product
- purchase
- sale
Task 1967602
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>
Before this commit, when printing the Price List report of a Product
Variant, the price is printed directly from the float result of the
calculation of the price, even if this price is rounded, the
representation of the float can have, sometimes, float precision errors
(a lot of 0 after the decimal point, and a 1 or 2 at the end).
Now, the function returns a string formatted to the correct number of
fractional digits.
opw-2069305
closesodoo/odoo#36705closesodoo/odoo#36770
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@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
Victor Feyens