When the public user is connected, allow him to print the report of
the open cart.
Since 61b4b6777d64 the sudo is not enough but with_user(1) is
required.
closesodoo/odoo#80803
X-original-commit: a4021965f1f049c69186e1f2acbc55ae59ee8730
Signed-off-by: Olivier Dony <odo@odoo.com>
When editing the billing address of an existing portal partner P,
the salesperson of P was changed by the default website salesperson
opw:2649732
closesodoo/odoo#80415
X-original-commit: 52442484897d95bfffa3f8672908bd3d00923363
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce :
- Install E-commerce module
- Go to Website -> Products -> Products
- Edit product `Acoustic Bloc Screens`
- Type "my product" in Internal Notes an save
- Go to the Shop
- In the search bar, type "my product"
Issue :
`Acoustic Bloc Screens` is in the search results list
Cause :
An 'ilike' for 'description' is added to the domain.
Solution :
Replace 'description' by 'website_description' field in the domain.
opw-2649754
closesodoo/odoo#79004
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
It is impossible to define the default order in which to display
products in the shop page. The order can be changed through the
"Sort By" dropdown, but it is reset every time the page is refreshed.
There is now an option in the website editor that allows setting a
default sorting method that is applied when displaying products.
It is overridden by the setting from the "Sort By" dropdown if
there is a different sorting method selected.
task-2616245
closesodoo/odoo#76512
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
(*: website_blog, website_event, website_forum, website_sale,
website_slides)
Before this commit the search bar was specific to products.
After this commit a generic search bar is available as a general feature
of website which can be configured to inspect specific models.
The snippet is used to replace the old search bar in blog, courses,
event, forum, page and shop.
The search results of these pages and the autocomplete of the search bar
run through the same search mechanism.
A new hybrid results page has also been created as a target of a search
on "Everything".
In each involved module, `website._search_get_details()` is implemented
to return search metadata for every model related to the `search_type`
parameter.
Search metadata for a single model is returned by `_search_get_detail()`
on that specific model.
The autocomplete runs through the additional
`website._search_render_results()` pre-rendering step that prepares the
data to fit in the autocomplete template.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
When browsing the eCommerce part of the website, customers
should be able to filter shop products based on base sale price.
Desired behavior after PR is merged:
The filter slider can be enabled through the customize menu and it only
filters using the product's base price (for performance reason) and takes
into account currency conversions, not pricelists and discounts. It uses a
custom-built library for the range input with 2 cursors (min. price and max. price).
The slider is hidden when all products shown on the current page
(category, etc.) have the same price (or there is only one product).
A more advanced version of this implementation would enable the filtering to
take more factors into account.
task-2603014
closesodoo/odoo#74575
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: fja-odoo <fja@odoo.com>
Co-authored-by: Kamen Zhekov <kzh@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
This commit let you choose a Point Relais® as your shipping address.
It instantiates the Widget only.
It will not handle the print label.
Part-of: odoo/odoo#75281
Since e4a317a the extra info form is not posted on this controller
anymore. It posts to /website_form/shop.sale.order instead.
closesodoo/odoo#75590
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This module allows users to be notified by email when a product out of
stock comes back in stock. For that they can add it to their wishlist
and select the appropriate option.
We show out-of-stock warning in all case whatever the show availibility option.
You cannot custom you 'in stock' message ot free message.
Spec of Pde and Fp
Part of https://github.com/odoo/odoo/pull/68221
task-2458165
closesodoo/odoo#68221
Related: odoo/upgrade#2405
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Kersten Jeremy <jke@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
*: crm_iap_lead_website, website_crm, website_form_project,
website_hr_recruitment, website_sale
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
This code can't be reached, the condition can't be true anymore, as
`partner_shipping_id` is a required field.
closesodoo/odoo#72794
X-original-commit: 3857d27d54b3dc839376abf08de535626e3af850
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
If a partner have two delivery address, one full filled, an other with missing
fields.
During the shopping (the first delivery address is auto selected), if the
partner go back in /shop/address to select the second address.
Then go to /shop/confirm_order, there no checks.
closesodoo/odoo#69901
X-original-commit: f8c8418bdd5b9d27b33fea3c63511297a231aa93
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
SPECIFICATIONS
For better understanding, this commit renames ``no_auto_thread`` field of
``mail.message`` model to ``reply_to_force_new``, to indicate that if the
field is checked (☑) replies should check gateway alias rules instead of
updating mailed threads.
It is also more coherent with reply_to namespacing used in various mail models
(notably new composer fields and ``reply_to_mode`` of mass mailing and mail
composer models)
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
* New method _get_vat_validation_fields to set the fields used
in vat validation.
* New method _get_country_related_render_values that returns all
the fields related to the country to be rendered in the address form.
These methods are necessary to allow the different localizations
(see l10n_ar_website_sale) to adapt the ecommerce to their own needs.
closesodoo/odoo#68851
X-original-commit: 3b01c249a8d2b9673992942c2c5ea50ef0488708
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the bug:
- Let's create two partners P1 and P2 where P1 is a company and P2 a child of P1
- P2 is a portal user
- Log with P2 and go to the shop
- Add a product in the cart and process to checkout
- The billing address the details of P2 are auto completed, click on next
- For the shipping address, the details of P1 are auto completed, click on next
Bug:
A 403 page was displayed with: You cannot create recursive Partner hierarchies.
opw:2487590
closesodoo/odoo#68814
X-original-commit: a6077a8cf8cd03b93dcd865c9fe2939bb3b7132b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: rdeodoo <rde@odoo.com>
PURPOSE
Before this commit, the "payment from odoo" flow (direct) required
tokenizing a payment method before processing a payment, rather than
directly processing the payment, and eventually tokenizing the payment
method later. In practice, this often meant that a 'validation'
transaction had to be processed and immediately refunded in order to
generate a temporary token. Then, a second "payment by token" flow had
to be executed to process the intended payment.
This implementation was too rigid for most modern payment providers'
APIs. Indeed, they mostly expect single processing for a given payment
and usually offer the possibility to tokenize the payment method after
the payment, rarely before. Because of this, the implementation of many
providers was either difficult, limited, or even impossible.
Among the various incompatibilities, we find: support for direct
payments but not tokenization, lack of support for authentication during
tokenization, absence of hosted page dedicated to tokenization, etc.
As another cascading consequence of this implementation choice, several
providers could not be migrated to newer APIs after that the ones
implemented in Odoo were deprecated.
The goal here is thus to 'invert' the payment flow implemented in Odoo.
As this means re-writing most of the payment module and of its provider
implementations, the opportunity is taken to deeply clean and document
the code of the impacted modules.
SPECIFICATIONS
- Lift the limitations listed above by inverting the generic direct
payment flow to first create and process a transaction, then tokenize
it if requested.
- Remove the `payment_flow` field on `payment.acquirer` and let the
acquirer choose the appropriate flow according to the use-case.
- Filter acquirers offered to the customer based on the use-case.
- Add overridable hooks at key steps of the payment flow to allow
implementing new providers with minimal effort (both in Python and
JavaScript).
- Move all module-specific logic and fields to where they belong (e.g.
let Subscriptions filter out acquirers based on their support for
tokenization, move `qr_code` in `payment_transfer`, ...).
- Homogenize the inheritance strategy of acquirer modules.
- Standardize the implementation logic in other modules' controllers.
- Improve the traceability of payments through stored fields and logs.
- Remove the public read right on `payment.acquirer` and enforce the
use of access tokens in all modules' flows.
- Fix all bugs that were inherent to the old implementation.
- Replace the previous testing suite (which was mostly commented-out for
years) with a new one that allows testing of both routes and flows
with different test configurations (user, transaction context, ...).
LINKS
Enterprise PR: https://github.com/odoo/enterprise/pull/12528
Upgrade PR: https://github.com/odoo/upgrade/pull/2291
task-2085989
closesodoo/odoo#56187
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Arnaud Joset <arj@odoo.com>
Co-authored-by: Kevin Baptiste <kba@odoo.com>
Co-authored-by: Barad Mahendrasinh <mba@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Co-authored-by: Adrien Horgnies <aho@odoo.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Before this commit some references to the old recently viewed products
snippet were remaining.
After this commit there are no references to the old recently viewed
products snippet anymore.
closesodoo/odoo#68446
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
*: website_sale_product_configurator,website_sale_stock,
website_sale_comparison,test_website_slides_full,
website_sale_delivery,website_sale_coupon
The goal of this commit is to add a new option within the settings
to "keep the same page" when a product is added to cart.
This option is website related and the "Stay on page" behaviour
is the default one.
In this commit, the following changes have been made:
1- Tweak the method 'cart_update_json' in website_sale controller
to make it suitable for adding products to cart in the same page
(as in 'cart_update' method but without redirection).
2- Update 'WebsiteSale' widget to stay on page on addition to cart:
2.1- The '_onClickAdd' method handles click events for:
- "Add to Cart" & "Buy Now" buttons on product page.
- Optional Add to cart button on products grid.
With This change, the "Buy Now" behaviour will stay the same as before.
2.2- "Add to cart" code moved to 'website_sale.utils' to be used on other
widgets (e.g. ProductComparison).
3- The new "add to cart" scenarios should be updated to work with
'website_sale' related tours by adding a new 'goToCart' step.
task-2411759
closesodoo/odoo#63300
Related: odoo/upgrade#2321
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, routes were prevented to be accessed if the route model was
not accessible from the current website, eg you couldn't access blog1 which is
set to website2 from website 1.
That would raise a 404 even from admin/editor.
This commit introduce that behavior at a lowel level in a generic way, instead
of having to write it on every route.
Note that routes without a model converter won't benefit from this.
Closes#63499closesodoo/odoo#64313
Related: odoo/enterprise#15688
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adapts the business code in which
class/module/function/method redefinition took place so that it no
longer happens and the pylint test passes.
1. Login as admin
2. Go to any product page and click Personalize > Enable recently viewed
products
3. Login in another browser session as portal user
4. Open some products until you start seeing the recently viewed
products
5. With the admin account unpublish one of the recently viewed
6. On the portal account browse more to display the recently viewed
Access error will raise because an unpublished product is requested by
the user.
Filtering the product to allow only published products fix the issue.
opw-2336699
closesodoo/odoo#57836
X-original-commit: 668778125c2d4231d9b48456c3397edb8d04acb3
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Problem:
the controller rely on record rules to select the payment.token
to be displayed on the payment page.
This works fine with portal user, but internal user
will face client side performance issue
as they can see all the token of the database
Solution:
Don't rely on record.rule in the controller. Use the domain
from the portal user rule in the search.
To make the search of token working for partners with more than
2 levels of hierachy, use child_of operator
closesodoo/odoo#56326
X-original-commit: 3999e249ea9902e009f0366949886e14e3d7fdf4
Related: odoo/enterprise#12579
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Url for a product become:
/shop/productname-id instead of /shop/product/productname-id
Url for a blog post become:
/blog/blogname-1/blogpost-1 instead of /blog/blogname-1/post/blogpost-1
Url for a question on forum become:
/forum/forumname-1/title-1 instead of /forum/forumname-1/question/title-1
task-2295016
The idea is to avoid useless SQL request as the searching process is heavy (have to look the word in several field and can be in translation tables).
As we at some point fetch all the searched product we do it at the beginning and use its information to gain performance on other queries.
Execution time in e-shop for "test" on client database (160 000 product with 4500 published):
- Before: ~ 7 sec
- After: ~ 2 sec
OPW-2256662
closesodoo/odoo#54202
X-original-commit: ec743deb23f22a823cd0ea56eb4719209a9c4d09
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously, there was only one static "Sale" ribbon. Users might want to
have many types of ribbons, for different levels of sales, or to
indicate that a product is sold out. This commit lets the user create
custom ribbons and use them on prodcuts on the shop page. Additionally,
setting a ribbon on a product used to require a reload, this is no
longer the case. All ribbon modifications are stored in a cache and the
RPCs to put them into effect are only done on save.
task-1981170
Part of odoo/odoo#47574
Related: odoo/upgrade#1079
Related: odoo/design-themes#219
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The /shop/cart/update was accepting both GET and POST request. Therefore,
we couldn't have csrf on the route meaning any website could change your
cart if the route was known.
task-2263776
closesodoo/odoo#51486
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit:
The `display_name` of the product was showing the code in the "Recently viewed products",
the code value isn't needed to be seen in the website.
After this commit:
More user-friendly product name is shown
OPW-2258774
closesodoo/odoo#51719
X-original-commit: be4d0d58081bea1b75ceee8f90372ed8cedbee2e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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.
Before 13.0, when there is no salesperson on the customer or company or
website, when a ecommerce sale order is done we get the OdooBot as
salesperson because we update partner on sale order in superuser.
In 13.0, since superuser doesn't change UID, the salesperson will be
assigned to "Public User" or the customer that create this order.
opw-2232201
closes#49141closesodoo/odoo#49161
X-original-commit: 0b6a2569920b6584652c39b3465998649fe305b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Step to reproduce:
- Install delivery and restrict your delivery to a few states
- Edit an already existing shipping address in checkout which is set to a
country having restricted states in the delivery method
- The states listed in the address shipping page are not the restricted ones
but all states.
Related to #26530closesodoo/odoo#45948
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- install e-commerce;
- In the website settings, orders followup, set a salesperson;
- By something as a public user;
- Pay the order.
Before this commit:
- 2 emails where create to assign the salesperson to the SO, but these
emails didn't have a from and the salesperson didn't receive the
emails.
- 1 email was also create to assign the salesperson to the contact, this
mail is not necessary.
Now, only one email that assigns the salesperson to the SO is sent,
with a correct from address.
opw-2189683
closesodoo/odoo#44861
X-original-commit: 7c08eb158858b9573d3d84a0b54df0bfca754105
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Purpose
=======
Improve the attendees management: improve views, actions, (views, actions).
Specifications
==============
In order to allow state management in batch, state field is made editable in
multi edit mode of registrations. That way event managers are able to work in
batch. It required to move some code currently called in custom action-called
methods directly in write. It makes sense to consider that some required code
is called by writing on state field instead of depending on calling the right
method. Indeed there is not much "business" code to move: calling mail
schedulers on confirmation, and putting the closing date when closing.
Event and registration tree views are improved, some fields are now editable
in multi edit mode.
When a user register on a event from website, it will create a sale order and
a partner (the customer of the SO). Set automatically the partner of the
registration to the partner of the sale order.
Task ID 2119333
PR #40949
The tokens access rights makes it possible for a portal users to manage
cards for their 'parent' (commercial_partner_id), this commit
homogenises this concept to allow using these tokens at checkout as
well.
Side effect of task 2119417
closesodoo/odoo#42386
Related: odoo/enterprise#7430
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose of the commit is, the template website.404 is renamed
in commit https://github.com/odoo/odoo/commit/423402f1e50000186924186beba0cbe87e02e774
but still remains use of it at some places which is going to produce
the traceback so replace the template website.404 rendering with NotFound
exception as it will use the template http_routing.404
Task-2145659
closes odoo/odoo#42294
Closes: #40924
X-original-commit: e5af7617e02e39b8a37a02b102d3da0e4525ffa9
Related: odoo/enterprise#7394
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
Move as much possible content from website_* modules to portal_* modules
to ease their use in customer portal
SPECIFICATIONS
Now that publish feature is replaced by internal directly in mail and portal
rating portal inclusion can be done safely in a portal_ratign module instead
of website_rating. It allows to remove the dependency and give the rating
feature of customer chatter directly in portal applications.
LINKS
Task ID 2071556
PR #38692
Reproduce the issue:
- Install eCommerce app
- Publish a product to your website
- Add the product in your cart
- Unpublish/make unsellable/archive the product
The product is still in the cart and the checkout process can be done.
Cause: There is no check for invalid products before displaying the cart
This commit remove the invalid products while loading the cart.
OPW-2092541
closesodoo/odoo#40241
X-original-commit: ab9290e39c2d2b9eb6d6f9972c1c8b546263edfd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Romain Derie