It can happen that the payment transaction route is called without the
amount kwargs, the code would crash in that case as we tried to access
it either way.
We moved the code after setting the default amount in the kwargs to
avoid a crash.
closesodoo/odoo#105576
X-original-commit: c124fb3292439a6237f16eff406c0a7d375cab65
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- on Ecommerce website Add an item to your cart.
- Billing/Shipping info > Stop on Payment page.
- Duplicate tab, On the duplicate, add more products to your cart.
- Go back to the original tab (Payment page) > Check out with Stripe.
- Stripe acquirer page does not reflect the updated cart amount.
- Complete payment > Website will say order is confirmed.
- Go to this SO in backend
Bug:
SO is not confirmed and Stripe status says there is a mismatch
because it did not take updated amount.
Fix:
double check the ammount before processing payment
opw-2978244
closesodoo/odoo#105060
X-original-commit: be9d2a57c4628fc867aefc932aaf8c503e76b60f
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: website_event, website_event_sale, website_forum, website_sale,
website_sale_slides, website_slides, website_slides_forum
This commit removes the remaining controllers that are no longer used
since the use of form views on website new content dialogs (following
the website in backend merge at [1] and the many iterations afterwards).
With the website in backend work, a feature was lost for the creation of
events: dummy tickets were created. This commit actually removes the
feature for good. Events default values are managed by templates.
Moreover there are links in frontend to edit the event when being
allowed to edit it (event groups), notably when there is no ticket in
registration page. So it makes no sense to create dummy tickets, without
price, for 1000 seats. Those values are random so they will have to be
edited. Better let users create real tickets if necessary, than editing
and/or removing dummy tickets.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102928
X-original-commit: d559ce5d1518ac1293db1c4f52efb8094daf5b49
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The bubble is showed whenever a filter is activated and/or a price range
is selected in the filters.
However due to float precision the comparison made to check whether
there is a price filter could be wrong when using "weird" numbers.
TaskId-3009210
closesodoo/odoo#102507
X-original-commit: 9359a5b5f0f72550d69671f975da23d4734b490f
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Bug: Users are able to modify their eCommerce cart after it has been
paid when they fail to return to Odoo through the payment provider's
return route. This prevents the cart from being confirmed.
Steps to reproduce:
1. Install the payment provider Mollie and set it to test mode.
2. Go to the /shop page, add a product to the cart, and select Mollie
for the payment.
3. On Mollie's hosted payment page, use the card number 4111111111111111
with the expiry date 03/30 and the secret code 123. Select 'paid' as
the payment outcome.
4. Confirm the payment but take care not to be redirected to the
/payment/status route. For examples, close the tab before or comment
out https://github.com/odoo/odoo/blob/15.0/addons/payment_mollie/controllers/main.py#L38.
5. Go back to /shop/cart and modify the cart.
6. Wait up to 20 minutes for the "payment: post-process transactions"
cron to try to confirm the cart.
7. Check the cart's chatter: the confirmation failed because the cart's
and transaction's amounts mismatch.
Explanation: The post-processing of the transaction is responsible for
confirming the cart, but it failed to be triggered because the user did
not visit the /payment/status page. The post-processing cron takes care
of pending post-processings after 10 to 20 minutes, which is long enough
for the user to modify their cart.
Fix: Force creating a new cart as soon as the current one is paid and is
being requested by the website.
task-2995504
closesodoo/odoo#102060
X-original-commit: 5f8674621cbf5919e10e32f29b66ae171fe05993
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Fixup for d823033ad67702b1b92d27a3f66c7a4ec304c644
Portal user should not modify partner's name if an invoice for this partner is
already issued. However, delivery address contact may have empty name, while
eCommerce UI requires filling out the name. This blocks checkout process. Fix it
by allowing name changes, when it's not set.
opw-2981455
closesodoo/odoo#101796
X-original-commit: 781dbeaccac76a6ec4f4b8cac1b607810697e394
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commits fixes the fact that we were having a traceback when puting an image inside a div that was in the div with id #product_detail and clicking on the remove button in the editor. In reality this butotn should not have been available because the image is not in the carousel.
We now check that the image is in the
o_wsale_product_images div (which is the carousel) to display the remove button.
To remove an image outside of this carousel, simply click on the remove block button.
task_id=2973363
closesodoo/odoo#99757
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit enables eCommerce customers to pay with the express payment
methods Apple Pay and Google Pay from the cart page.
For the moment, only Stripe supports this additional feature but it
was designed to make it easy to implement with a new provider.
task-2754209
closesodoo/odoo#88374
Related: odoo/enterprise#29915
Related: odoo/documentation#2392
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds a new feature to eCommerce: "Reorder"
The system administrator may enable the feature in the website's
settings.
It will add a new button on a completed sales order portal page to
reorder the same content.
Upon clicking the button a dialog will pop up to configure the different
product's quantities and display any error that would prevent a product
from being added to the cart.
If the user has something in his cart already a confirmation dialog will
be prompted asking the user if they want to clear their cart before
adding the products to the cart.
TaskId-2837571
closesodoo/odoo#96040
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
- Fix linter error
- Checking only "if group B" is the same as "if group B and if group A"
if group A implies group B, it is the case here, being a designer also
mean being a restricted editor
Part-of: odoo/odoo#98200
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Searching by attributes works via a separate form. It has a copy of other search
parameters (`category`, `search`), but not `order`.
STEPS
1) enable View "Products Attribute's Filters" in eCommerce
2) enable View "Show Sort by" in eCommerce
3) Set sorting to specific value
4) Change Product Filters Attribute values
5) as you can see, the sorting set in Pt3 is lost....
opw-2956280
closesodoo/odoo#98716
X-original-commit: 7e9afa3f167bd3251984c2027fb50f127bc002c2
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
/my/account controller blocks name/vat/company_name updating if there are issued invoices.
However Before this commit, user can change name via /shop/address page
STEPS
1/ install sales, eCommerce,inventory,Accounting
2/ create a sales order from the portal page, validate and create an invoice from SO and post it
3/ Try to change the name from the Portal > Account
Result - not possible = correct
4/ Place a new SO by the same portal user and edit the name on the address before proceeding to checkout
[1]: https://github.com/odoo/odoo/blob/1f49528a4b198e8912beb33be921d2855c694e2e/addons/account/controllers/portal.py#L111-L113
opw-2848251
closesodoo/odoo#98335
X-original-commit: 3c8337d17c23779ef265cb5037243b533725c494
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
1. Add a few products to your cart.
2. Go to the checkout page, and stop right before clicking on 'Pay now'
(ie: customer goes to find the credit card and comes back later)
3. On another tab, go to the backend and cancel the sale.order
4. Go back to the website tab, and click on Pay now
5. Complete the payment process
Result:
* The customer is able to pay a cancelled order.
Expected:
* It shouldn't be possible to click on 'Pay now'
closes odoo/odoo#97630
Forward-port-of: #96549
X-original-commit: 37c3cf55d507e0bccf9db3e63503dfec896dfaef
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit adds an 'Add To cart' snippet to the 'Web Editor'.
The snippet works as follow:
1. You choose the `product template` that you wish your users to buy.
2. If the product has more than 1 `variant`, a widget will offer you to either
let the visitor choose - this will open a modal for him to choose the variant
by himself - or select a variant yourself.
3. if `visitor choice` is not selected, a `buy_now` or `add_to_cart` action can
be configured; this will determine the behaviour of the button after the user
clicks it.
task-2824359
closesodoo/odoo#91882
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Co-authored-by: Morgane <morm@odoo.com>
This commit adds more functionalities to the web editor when editing a
product's page in order to make it more user friendly to add change or
resequence the many images a product may have.
TaskId-2692189
closesodoo/odoo#85686
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Filter product templates search result if there are any possible attribute
combination to get/create a product variant regarding the searched attributes.
For example if the combination (A, B) is excluded, filtering on (A, B)
will filter that product out of the result.
task-2558970
closesodoo/odoo#89018
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds a new display type for a product page, namely the grid
mode.
The web designer will now be able to choose between carousel (previous
mode) and grid.
The web designer may also choose how much space the images take on the
page between 0%, 50% 66% and 100%.
TaskId-2833507
Part-of: odoo/odoo#92447
Before this change we would have to use other ways to add filtering forms in e-commerce. For example, using the context of the request in 'product.template' to catch what we need in the _search_get_detail method.
After these changes, we will not need to pass the context of the request outside the controller because it will be the _search_with_fuzzy options that will give us the information we need for inheritance.
closesodoo/odoo#94858
X-original-commit: d29f2f3ac5f8c3e8109287e0933609bdbe0cadb1
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
15.3 introduced a new setting in the website to force users to sign
in/up whenever they try to buy something from the store.
This commit adds the mechanism to redirect the "process checkout" page
to the login page whenever the option is enabled and the user is not
logged in.
TaskId-2844980
closesodoo/odoo#90901
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*: website_blog, website_hr_recruitment, website_sale, website_slides
This commit changes the redirections from the controllers, that were
always redirecting to the frontend before.
Now, we want to open the website in its backend client action most of
the time (for example, when clicking on the "go to website" buttons on
the form views).
For that, a new get_client_action_url is introduced on the website
model.
See merge commit for more information.
task-2687506
Since this commit [1], we don't want to display the "List View of
Variants" option on the product page if option "Variants" in settings
was disabled. Now that the customize show menu options have become
snippet options in edit mode, the code to do this has been adapted.
[1]: https://github.com/odoo/odoo/commit/1cd63d81908511ee136f0ca2600d85eab48f258f
task-2710582
*: website, website_sale_comparison, website_sale_loyalty,
website_sale_slides, website_sale_wishlist
This commit adapts "customize show" options from website sale modules by
creating new options available in edit mode.
See merge commit for more information.
task-2710582
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Purpose
=======
Avoid having "dead-ends" when registering to an event.
Specifications
=============
Add link to event to registration confirmation for free events.
Display list of each bought event on the confirmation page for paid
events.
PR: odoo/odoo/pull/78599
Task-2657635
closesodoo/odoo#78599
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task-id : 2791237
PR : https://github.com/odoo/odoo/pull/87636
Allows customers to see a list of delivery carriers as shops in the website page;
A delivery carrier may now be an onsite one, which means the client comes to the corresponding store to pickup the products.
Also adds a payment acquirer based on wire transfer, for paying on site.
The customer can only pay on site if he also comes to pick the product on site
Notes :
- If a warehouse is set on a delivery carrier, the sales order will take it's address.
closesodoo/odoo#87636
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit:
redirect_url may have never been asssigned before being read
opw-2827002
closesodoo/odoo#90374
X-original-commit: 1aa35cba14528f413e9813707c406f31bfb07967
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit aims to fix multiple issues with the "Customer Account"
parameter in the backend config.
- Hide the parameter from general and sales settings if website is
installed.
- Properly compute the right value once website is installed, as it was
not using the website's value.
- Fix a traceback when clicking on "Default Access Rights".
TaskId-2825096
closesodoo/odoo#89806
X-original-commit: 8b162f507f881619061d61530cc03b4b4654c1fe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The value of _checkout_form_save was validated because
in some cases the method returns Forbidden()
and this value is set directly to the order
closesodoo/odoo#89786
X-original-commit: 860370f5ed03e2fdc801ddbe02115818bb251655
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds hooks to give more flexibility on cart updates. It
allows to add parameters when a product is added to a cart. It gives a
method to disable the quick add and multiple hooks for further smooths
developments.
task-2382027
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
Allow editing the attribute's display type from the front end using the
web editor.
Closes: odoo/odoo#85153
TaskId-2675390
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit updates the cart quantity even if the html page comes from
browser cache, i.e. the user comes back to a previous page with the
browser back method.
task-2741846
closesodoo/odoo#84861
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Expected behavior : The pricelist must be the one chosen by the customer on the website.
Current behavior : The price list is reset when the address is edited
Steps to reproduce the error :
First of all, you need to setup 2 pricelists on the website:
~ The first in dollars
~ The second in euros
~ Removes the group of countries from both
1. Create an order with the second price list (EURO)
2. Set your address
3. Edit your address
4. The pricelist will be changed to dollars
When you set the address for the first time, It redirects to /shop/confirm_order which
executes sale_get_order(update_pricelist=True) to correct the price list.
But when you edit the address sale_get_order(update_pricelist=True) is not executed
closesodoo/odoo#83061closesodoo/odoo#86764
X-original-commit: e5a76880320ce0606e6a0fc2a6ba776f79ce126e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
* consistent/clear sale_get_order params (force_create is a boolean value, do not provide integers)
* use one coherent way to get website current pricelist, through the dedicated computed field
Part-of: odoo/odoo#82374
Donatas