Steps to reproduce the issue:
- Install eCommerce module
- Go to Settings
- Ensure `Product Prices` is set to 'Tax included'
- Create a new Product as storable
- Set `Sales Price` to $1.0 and `Customer Taxes` to 10.00 %
- Under `Variants` tab add an Attribute with 2 values
- Set "Price Extra" to $2.0 to one of the variants
- Go to the Shop and select the product
Issue:
The extra price badge does not include the taxes
($2.0 instead of $2.2), however the final price does.
Cause:
The price_extra field from ptav (used in the badge) does not include
the taxes.
However, when calculating the final price, we do first the sum of all
prices (including the extra prices) and then apply the taxes.
Solution:
In the template, for each 'variants', we call `_get_combination_info`
to get the variant.price_extra with taxes included/excluded
depending the `Product Prices` setting.
opw-2669871
closesodoo/odoo#81949
X-original-commit: 6f04935d14d595faa3bb8dd6ba9e0dcf1d694886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@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
Steps to reproduce:
- Install website_sale module
- Enable discount and advanced pricelist in settings
- Create product with sale price 0$ and set a website in
- eCommerce + publish the product
- Create pricelist PPP with Discount Policy as
- "Show public price & discount to the customer" and selectable in the website
- Go to the product and set an extra price of 10$ for the new pricelist
- Go to the product in the eshop and select the pricelist PPP
- Add the product to the shop cart
Issue:
The price displayed is 0$ instead of 10$.
Cause:
Since price_unit equal 0$, not possible to calculate the discount and
therefore using the 0$ value.
Solution:
Use price of pricelist in case 'discount_policy' is 'without_discount'
and price_unit equal 0$.
opw-2652192
Forward-Port-Of: #78570
Cherry pick of 32d34ffb04b3c6a8397c8ff7eb4e8a3dd9fb8a95
closesodoo/odoo#78778
X-original-commit: f34e441578bd2ba93dff1feffe6cafee633b9d32
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
*: website_sale, website_sale_delivery
The old analytics snippet (isogram) is replaced by the newer gtags
snippet. Virtual page views and ecommerce transactions are now tracked
using gtags. The e-commerce data format is updated to correspond with
the new GA4 format.
task-2500769
closesodoo/odoo#72233
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
When combining two pricelists, the unit price might be incorrect
To reproduce the error:
1. In Settings, enable:
- Pricelists (Advanced)
- Discounts
2. Create a product P:
- Sales Price: $100
- Available on website
3. Edit the Public Pricelist:
- Add a price rule:
- Apply On product P
- Min. Quantity: SuperProduct
- Compute Price: Percentage
- Percentage Price: 63%
- Discount Policy: Included in the price
4. Create a second pricelist:
- Add a price rule:
- Apply on product P
- Compute Price: Formula
- Based on: Other Pricelist
- Other Pricelist: Public Pricelist
- Price Discount: 25%
- E-commerce Promotional Code: PROMO
- Discount Policy: Show public price & discount
5. On the website, add P to the cart
6. Edit the cart:
- P's quantity: 500
- Apply PROMO code
Error: The new price is $75 instead of $27.75
`_website_product_id_change` already returns the correct price value, so
the latter shouldn't be computed again (moreover,
`_fix_tax_included_price_company` should use the price with the pricelists
applied instead of the default product price)
OPW-2605804
closesodoo/odoo#75843
X-original-commit: 030e92a3150bbb7d749f1a6f10e261791da6eca6
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Let's consider a company in $
- Let's consider two sales taxes T1 (10% included) and T2 (0%)
- Define a fiscal position FP that maps T1 to T2
- Define a product P with T1, price = 11$ and available in the shop
- Define a pricelist PL in € such as 1€ = 2$, show discount to customer and discount P with 50%
- Define a portal user PU with FP and PL
- Log with PU
- Add P in the cart
Bug:
The unit price of P was 2,75€ instead of 2,5€ and the discounted price was 10€ instead of 5€
PS: Before adding P in the cart, the correct unit price and discounted price were displayed.
opw:2472528
closesodoo/odoo#69745
X-original-commit: 5e414d80dd5faf0b90d62dbccc1e6237099ac8db
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the issue:
- Let's consider a product P (11€) with a 10% included tax T1
- Let's consider a fiscal position FP that mappes T1 to a tax T2 (0%)
- Let's consider a website that displays prices with tax included
- Let's consider a portal user PU with FP as fiscal postion
- Log with PU
- Go to the shop and filter products to see P
Bug:
The price of P was 11€ instead of 10€
PS: When adding P in the cart, the correct price is displayed.
opw:2472528
closesodoo/odoo#68081
X-original-commit: e7bfadea847012ee956b7bb425688b5f9ccda9cf
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit if a product template has no image, no image was
displayed in the website shop for the product
After this commit if a product template has no image, the image of the
first variant is displayed in the website shop
https://github.com/odoo/odoo/issues/52463closesodoo/odoo#62440
X-original-commit: 643c8a9dce9455fe614f73ed97a793856e3608e7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit the search for abandoned carts was always using a delay of
one hour if no ebsite in the context.
After this commit the search for abandoned carts uses the specific cart
abandoned delay configured for each website and the related public partner_id.
This commit closes#59709, #54932closesodoo/odoo#61671
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit,
* the website_sale tests used the field optional_product_ids on product_template even if it is defined on sale_product_configurator.
* the website_sale_product_configurator test added some steps to the website_sale tour.
This commit removes the faulty fields in the website_sale test and fix the website_sale_product_configurator tests.
After this commit, sale_product_configurator and website_sale_product_configurator have a test classes to setup all the parameters needed during the flow.
This prevent duplicated code for similar workflow.
closesodoo/odoo#60081
Taskid: 2340918
X-original-commit: f7ca48e9d1ff56ae53ab156114f9dc29534ac3f6
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Prepare Event Online support by providing fixes and preparatory cleaning
commits.
SPECIFICATIONS
Make visitor tests in website_sale independent from existing visitors and
specially about demo data. Adding demo data makes tests crash which is not
the expected assert of visitor tests.
LINKS
Task ID-2300907 (Event Bugprovements 2)
PR #54621
X-original-commit: 971f26a14d5cbafd65f4370eac14f4cd762b5b44
A product can't be archived if it's used in a pos loyalty program.
opw-2276745
closesodoo/odoo#53948
X-original-commit: 3af9b65638a9725fbeb6597b77328d8f6be5b2ec
Related: odoo/enterprise#11590
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It very rarely happens that the test is failing due to the following error:
`Tour shop_list_view_b2c failed at step
.oe_product_cart .oe_currency_value:contains("825.00")`
The value found in that case is 750 instead of 825, which indicates that the b2c
setting was not correctly activated.
To exclude the RPC themselves from the equation, it is decided here to move the
setting change directly in the Python.
closesodoo/odoo#44599
X-original-commit: 735807cefb7ccf3232f7492b825ce8c42bacbed4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
In Project, the configuration has to be done twice: in the settings of the
app and on each project.
During the onboarding, the user won't understand that a feature has to be
enabled at both places and will think that the system just doesn't work.
If the user enabled a feature, he most likely intends on using it for most
of his projects. Therefore, having to do a double configuration for each
new project is annoying.
By the way, sub-tasks is the only global feature (it can't be enabled or
disabled by project), so we are breaking it down by project to remain
consistent with the rest.
Specification
=============
1/ Enable subtasks per project
Before this commit, sub-tasks were a global feature (i.e. once enabled
they were enabled for all projects). This commit gives the ability to
enable/disable sub-tasks per project.
2/ Make project_id on planning required
3/ Change default rating status on new projects
4/ Default value for allow_subtasks
5/ Enable timesheets on existing projects
6/ Hide Total Hours if subtasks are disabled
7/ Create project in the company context.
Otherwise some records generation could use a default company which is not
the company for which we want to create a project.
8/ Default value for allow_forecast, is_fsm
9/ Change reference to timesheet product
10/ Fix tracback on industry_fsm_report.
Before this commit, there was a traceback when enabling "Worksheets"
(industry_fsm_report) after "Time and Material" (industry_fsm_sale).
11/ Convert some onchange method into computed editable stored fields
closesodoo/odoo#41218
Taskid: 2146474
Related: odoo/enterprise#6998
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Instead of polluting an existing environment, use the method that was
intended for changing the company `with_company` which returns a brand
new environment and leaves the existing one unchanged.
On the e-commerce app, you can add product variants.
Those variants can have extra-image.
Before this commit:
- The variants extra image are displayed on every product of the
same type and they are duplicated on the product variant.
After this commit:
- They are displayed only on the concerned product variant,
without duplication.
OPW-2088261
closesodoo/odoo#39502
X-original-commit: 8efaa086db271cde792da77bca7a95a0d593df4d
Signed-off-by: Sébastien Theys (seb) <seb@odoo.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>
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>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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
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>
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>
The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.
This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
`is_published` which would just go through the related for no reason.
Plus, using `is_published` will make the field tooltip more accurate as we
are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
related field, which is just a readonly when we are not in a frontend
context.
- Some create and write function would have security check on
`website_published` value but that was wrong as the user could bypass that by
simply writting on `is_published`. For the write method, check `is_published`
is more accurate as it will cover both case since `website_published` will
then call the write method on `is_published`
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
In saas-14, 36fdb2ff49 was recently added to fix the flow where an empty
pricelist code being submitted in the cart input should reset the pricelist.
But we waited 12.0 to add an easy test, as we have `MockRequest` to easily
mock and simulate frontend context to test controller in python tests, see
6ebcb1db80.
Following #34711closesodoo/odoo#35253
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Nasreddin Boulif (bon)