This dashboard depends on the website dashboard which is to be re-done
in OWL. Instead of keeping this dashboard as a separate component, it
will be re-done in the Dashboard App (see task-3222991).
task-3164163
Part-of: odoo/odoo#112819
When no payment provider is active, admin users should see the 'Activate
Stripe' button on the checkout page, allowing them to configure Stripe
faster.
This commit also disables the provider 'Pay in store when picking the
product' in the demo data to improve the testing experience of the
eCommerce settings on runbot.
task-3235154
closesodoo/odoo#121138
Related: odoo/enterprise#40934
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to “Test Name”, we
shouldn’t be able to change the info
Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.
Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability
The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085
Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394
opw-3126325
closesodoo/odoo#126261
X-original-commit: 972c55bf76f4c5f1b1bedec4a77ddaeac8be1483
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
New "Re-order from portal" feature for e-commerce orders was not
considering specified no_variant & custom information on the order at all.
This commit makes sure the information is correctly forwarded to the cart,
ensuring the reordered products are the same as the ones previously ordered.
opw-3380312
X-original-commit: 9e774cf88398b7ffc701c4adf44451e39963db08
Part-of: odoo/odoo#126151
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
It's not a specific state, it should be considered separately,
as a boolean.
This allows to reduce code complexity (flows should not rely (much) on
the locked logic) and to have a clearer flow.
Task-3163931
Part-of: odoo/odoo#115871
Before from the portal the user could see all the payment providers
even if the payment provider was not available from the website
where the order was made. Now the payment providers are filtered if
the order has website_id.
task-3284582
closesodoo/odoo#120679
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Commit 91d0e9c645 made sure that excluded
combination did not appear in /shop search results, but it significantly
slowed down searches, even in databases without exclusions.
Since the excluded combinations cannot be added to the cart (and the
original feedback did not come from an effective ticket), we believe
the gain is not worth the cost.
This commit reverts that change.
Task-3326948
closesodoo/odoo#125722
X-original-commit: 3082ac99dc195a89e1299be73ef149f40231f86e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-------------------
- install website_sale and delivery_sendcloud module;
- create a shipping method (use Sendcloud provider);
- configure the integration with
"Mondial Relay Point Relais International 1-2kg";
- configure option with shipping rule and use location;
- on website create a new quotation with the pubic user;
- process the checkout;
(Check in backend the shipping weight)
- fill City and Zip Code fields with correct value
(example: Paris | 75011)
(- configure the company's country)
Issue:
------
[1.] If the shipping method is the only one, the locations are not displayed.
[2.] The delivery address is not the address of the chosen location.
Cause:
------
[2.] The method `update_eshop_carrier` is retriggered after update the `access_point_address` field.
The `access_point_address` is reset.
Solution:
---------
[1.] Show the option to choose a location if we only have one delivery method
(we are certain that the options should be displayed).
[2.] Use a parameter in the post request to instruct
not to reset the `access_point_address` field.
opw-3326139
closesodoo/odoo#125647
X-original-commit: 677bff31d3acdd05fff6567b693de78cff256ea2
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When user tries to enter extra info from Configure Form from 'settings' so
'website.sale_get_order' method does not get any order.
Steps to reproduce:
1) Install website_sale module.
2) Click on settings > activate 'Extra Step During Checkout' > click on 'Save'
button.
3) Now in 'settings', click on 'Configure Form' under
'Extra Step During Checkout'.
4) Now, click on 'Discard' button on top right of screen.
5) Enter something in textbox 'Give us your feedback' > click on 'Next' button
and traceback will be generated in backend.
Error: ValueError: Expected singleton: sale.order() traceback will be generated
because in method '_message_log' it is expecting a record.
Sentry-4126876202
closesodoo/odoo#125259
X-original-commit: 43506c5934e50bc1b132a135466b405f1d1ebb20
Signed-off-by: Mohit Beniwal (mobe) <mobe@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When user enters empty space in name field instead of entering an
actual name and confirm their billing, shipping address then when
they click on paynow to confirm order they will face the issue
'list index out of range'.
Note : Do the paypal configuration before following below steps.
Steps to produce:
1) Vist the website as a public user.
2) Create a sale order by adding some products to the cart.
3) While entering shipping and billing address, in the name field enter
some space.
4) Click on next button.
5) Now a sale order is created.
6) Go to orders through 'website' module.
7) Open the order created and generate a payment link.
8) Paste that payment link in another tab or browser .
9) Click on pay
10) By following above steps you will encounter the error.
This commit will prevent the above error.
sentry - 4177783431
closesodoo/odoo#122572
X-original-commit: bce2c37770ec43548f0cb9f35e87820e74254d09
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Steps to reproduce:
Without being logged in,
complete the purchase flow on the ecommerce,
taking care to have a different billing
and shipping address.
If you change the delivery address,
you will get an access error.
Cause:
In some cases, we do not have access to
the `name` field of the `partner` record.
Solution:
Add `sudo` to be able to read the fields.
opw-3276877
closesodoo/odoo#122329
X-original-commit: 1d6ae6bbc765de5673fab5830a81510a1d8857ae
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Since 15.0, it is no longer possible to have partnerless transactions.
Nonetheless, migrated databases could contain transactions without a
`partner_id` set.
This commit cleans existing rules to make those transactions are not
accessible to unwanted users.
We take the opportunity to clean the security of payment.transaction
records globally.
Now only admin and accounting users have access to payment.transaction
records. The code of different applications has been adapted accordingly.
Task - 3102824
closesodoo/odoo#113515
Related: odoo/upgrade#4564
Related: odoo/enterprise#40939
Signed-off-by: Masereel Pierre <pim@odoo.com>
On the ecommerce, we want the pricelist to be adapted
to the user who is connected.
If no user is logged in, the 'Public Pricelist' is used.
To determine the pricelist that will be used (by default):
https://github.com/odoo/odoo/blob/a3169ede4f609b56c83da04756d20b1c7a07251f/addons/website_sale/controllers/main.py#L350-L354
Therefore, if we have been to the shop as a 'Public user' and we decide to log in,
we already have a pricelist in `request.session.get('website_sale_current_pl')`.
So we have to clear the pricelist when we connect to determine the new pricelist
of the user.
opw-3228998
closesodoo/odoo#121074
X-original-commit: 71b2d817df93f0cc8c1f5c424a3555bcadf33b2d
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
In the case of transaction linked to sales orders it is
more appropiated to use the invoice partner related to the
sale order than its main partner.
After this fix the invoice partner of sale orders will be
used for transactions linked to it.
opw - 3212748
closesodoo/odoo#119962
X-original-commit: 6eaf11d1ac0d9fc3cd9d458e6ee1f27159216d40
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Currently, `website_sale` uses the same logic as `sale` to show the
product variant configuration.
This commit aims to separate this logic and let each module handle its
own product variant configuration.
task-3056806
Part-of: odoo/odoo#106511
- company
- published state
Search a product on shop, Filter on shop
must compute data and take care of company and published state
opw-3251404
closesodoo/odoo#119352
X-original-commit: 4ea5ca541a12435c48a4f9f41f2cee3cf21532c4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue:
With the "Extra Step During Checkout" setting,
it is possible to click on the "Configure Form" button
which should redirect us to the form in order to edit it.
However, we will always be redirected to the first website
(even if we have modified it in the settings).
Furthermore, if we don't have a cart in progress,
we will be redirected to the shop.
Solution:
Add a parameter specifying that it is for editing.
In this way, we can modify the form without having to create a cart.
Due to a technical limitation (reloading settings after saving),
we will always be redirected to the first website.
But it is possible to change the website (with the website editor)
and modify the second website if necessary.
opw-3245772
closesodoo/odoo#117870
X-original-commit: a3169ede4f609b56c83da04756d20b1c7a07251f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
If the SO partner changes, we shouldn't use the pricelist id stored
on the session, only the new partner pricelist.
opw-3138262
closesodoo/odoo#116434
X-original-commit: 16ba84c25c107996fd0c57f4ffbeb63737601406
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In ecommerce, the form vue of shipping methods should be improved to
easily set up fixed delivery costs. This commit improves the
user-experience and solves bugs on the fields displayed.
task-3203210
Part-of: odoo/odoo#110686
It's currently impossible to set fixed delivery costs in eCommerce
without installing Inventory. This is a problem for one-app free
instances on our SaaS, which would need to pay for a feature that
should be part of the basic eCommerce features bundle.
This commit makes it possible to define fixed-cost delivery methods in
eCommerce without installing Inventory by adding a direct dependency of
`website_sale` on `delivery`. The bridge between those two modules is
therefore included in the former.
Part-of: odoo/odoo#110686
If you specify an empty VAT number in the Contacts app, it will store it
as `False` in the ORM. If a new partner is created through the shop, the
VAT number is set through HTML form submission. It will use `''` for an
empty VAT number. When evaluating the VAT number in Python code, it will
usually be converted to a boolean, so it doesn't matter if it's `False`
or `''`. But in ORM queries those are two different values and code that
checks on `False` to check for the presence of a VAT number can
misinterpret `''` as being one.
This fix replaces `''` values submitted through the address form in the
shop with `False`.
opw-3114246
closesodoo/odoo#114617
X-original-commit: 84106a1d43fa768429f555cd49a72e0fd2adee4b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
The payment values in the Qweb context of sale, sale_subscription and
website_sale were computed separately, although there is a large common
basis. This split made it hard to communicate between modules and
generated a lot of duplicates. The new function `_get_payment_values`
in sales is now used as a common basis method for all sale_* modules to
get the common payment values.
closesodoo/odoo#107788
Related: odoo/enterprise#34922
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Before this commit, when using express checkout, the shipping address
was requested only if the technical module 'delivery' was installed.
Now, over express checkout, the shipping address will be requested if
the sale order contains products that aren't services.
task-3149536
closesodoo/odoo#111796
X-original-commit: 9c16e83336b042ab77c267607ac43e0ef0db9997
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Add hooks before rendering the `website_sale.cart` and
`website_sale.extra_info` templates. This allows to pass flags to
trigger style variation in the checkout wizard (add an extra step). In
addition, add the country_code to the sale_order view form, since it
will be needed everytime we add l10n_* fields in this view (with attrs
based on `country_code`).
Related: https://github.com/odoo/enterprise/pull/35050/commits/fce5e682946cfa7d9e19c0c3c6abfab3dcbcc54a.
task-3089169
closesodoo/odoo#108181
Related: odoo/enterprise#35050
Signed-off-by: Laurent Smet <las@odoo.com>
In the current state of the code, pricelist are always recalculated according to the partner id of the user. In the case of a custom pricelist applying to anyone with a code, Odoo will bring back the default pricelist, forcing us to retype the code once or twice during the checkout process.
opw-3101158
closesodoo/odoo#110569
X-original-commit: 39797d3fe27b9f0545c34a538454d5f3ad5209d0
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Purpose of this commit is to avoid html entities in logged message by correctly
managing enclosures. For that purpose a new tool 'nl2br_enclose' is added that
eases Markup management on top of 'nl2br' simple tool.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In website(_sale) messages are created from website forms. However those
are technical models, you should always use the MailThread API notably to
ensure values coherency. In our case using message_log seems to be what
original committers wanted to do (even creating a message as a comment
which has no effect as the notification process is not called that way).
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
request.geoip is no more a dictionnary cached in the session. It is now
a full blown object with lazy and smart geolocalisation capabilities.
Among other things, the previous dictionnary API is now deprecated. The
changes are:
* `request.geoip['country_name']` -> `request.geoip.country_name`
* `request.geoip['country_code']` -> `request.geoip.country_code`
* `request.geoip['city']` -> `request.geoip.city.name`
* `request.geoip['latitude']` -> `request.geoip.location.latitude`
* `request.geoip['longitude']` -> `request.geoip.location.longitude`
* `request.geoip['region']` -> `(request.geoip.subdivisions[0].iso_code if request.geoip.subdivisions else None)`
* `request.geoip['time_zone']` -> `request.geoip.location.time_zone`
It is safe to access all the attributes. Doing `request.geoip.city.name`
when the geolocalization failed (missing db, invalid address, ...)
evaluates to None. It does not raise an AttributeError.
Task: 2848206
Part-of: odoo/odoo#91337
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>
Arthur Detroux (ard)