Steps to reproduce:
- set shipping methods country to mexico (empty states)
- fill an order on website on check out select seprate shipping/billing
- on billing set country as US
- on shipping the only country avialable is mexico
- avialable states are the ones from the US not mexico
Bug:
the states are set from the country of the customer even though it isn't
an option on any carrier.
bug was introduced by this commit[1]
Fix:
revert the mentioned commit(1) since a new commit[2] was introduced that
correctly handles that use case too
[1]:https://github.com/odoo/odoo/commit/d59fe9c58c2dcc2bf6613adb7ac3662597b50496
[2]:https://github.com/odoo/odoo/commit/297641da69982d6c76bd591296636b479cabf657
opw-3230361
closesodoo/odoo#128349
X-original-commit: c59bc765f186858bffb642987cd88fcb80fe262a
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
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
Version: 16.0
Prerequisites:
- "Pricelist" enabled
- "Prevent Sale of Zero Priced Product" enabled
Steps:
- Create a product:
- Sales Price: 0
- In the "Sales" tab set "website" to a website
- Add Extra Prices (smart button)
- Public Pricelist (USD)
- Min. Quantity: 0
- Price: 100
- Go to the shop, choose the correct pricelist and try to add the product to the cart
Issue:
UserError: The given product does not have a price therefore it cannot be added to cart.
Cause:
It doesn't compare the good price list considering the context
opw-3339524
closesodoo/odoo#124898
X-original-commit: facd44d0bd4352be3d0eb11a2675e7a518c97e59
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behaviour:
If you have a product with tax included, and you make a discount via
a pricelist, the `base_price` of the product in the /shop page is not
correct. (it's not the same as the one on the product page, which is
correct)
Expected behaviour:
The base price in the /shop page and on the product page should be
the same in general. Should the price with tax included before the
discount.
Steps to reproduce:
- Install eCommerce, Sales
- Settings > Display Product Prices > Tax Included
- Settings > Pricelists > Advanced price rules
- Check Settings > Comparison Price
- Create a tax of 21%
- Create a product, set it's Sale's Price to $61.98, with the tax
(tax incl = $75)
- Create a pricelist that apply to the product, give it a discount
of 20%, and apply the discount policy "Show public price &
discount to the customer".
- Go to the /shop page and search for your product, observe the
`base_price` of the product is not correct.
(refer to video in ticket for a walkthrough)
Reason for the problem:
Lack of adaptation of a fw-port in commit:
30ad33de9c320f19258974a8eb77df26480d653c
Fix:
Correct the fw-port and aggregate the conditions when applying taxes
on the base price.
Affected versions:
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3194646
closesodoo/odoo#124649
X-original-commit: a4500d1535bbf5cff7014a29971fb2e7637e2acc
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
add chatter to product pricelist to improve collaboration. Track
currency, company, country groups, discount policy and website fields.
task-3316528
closesodoo/odoo#121244
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, on a multi-company environment with different website domains set, the terms and
conditions web page, which should be company-specific, are not correctly "pulled" if you check a SO
This was due to the website override that searched for a current_website, even if none was set on a
SO, thus setting the website url instead of the company one.
opw-3239061
closesodoo/odoo#123855
X-original-commit: ac5c042d3b1e0774ad430a66142437fc8db2fded
Signed-off-by: Morgane Demesmaeker <edm@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>
We do not want to allow the creation of lines with zero quantity,
Although we do not know of a standard flow making such requests,
the cart_update routes could accept information such as
* {"product_id": X, "set_qty":0}
* {"product_id": X, "add_qty":0}
If a line with product X already exists, it'll be deleted.
If no such line exists, a new one would be created, which is not
something we want to support.
closesodoo/odoo#118999
X-original-commit: 231c8aa79ddd0b1f4ed47508fa22596ac19daacb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Paul Morelle <pmo@odoo.com>
Current behaviour:
When a pricelist discount with a % is present for the /shop, but
doesn't apply for the product, for some base prices that are not
easily representable as floats, the comparison between the base
price and the post-pricelist price may be different, when they are
not, due to floating point inaccuracy.
Expected behaviour:
Even if floats are not accurate, if the price is essentially the
same, it shouldn't be counted as a discount.
Steps to reproduce:
- Install eCommerce and Sales
- Settings > Activate all pricelist settings for discount and check
the "Comparison Price"
- For a product set the base price to `4,152.48`
- Create a price list that shows the discount of 25% that *doesn't*
apply for the product we set, set it selectable for the e-commerce.
- Go to the /shop, set the pricelist and look for your product, see
that the base price and discounted price are the same, but one is
strikedthrough as if there is a discount.
Reason for the problem:
Floating point inacuracy when computing the base price of the
product, and we compare with the "reduced" price, they are different
(4,152.48 vs 4,152.480000xx), so when we compare them, they are
different, when they shouldn't be.
Fix:
Use `compare_amount(...) != 0` of the currency to safely compare the 2
prices.
Affected versions:
- 16.0
- saas-16.1 (couldn't reproduce, but the line is present, so
possibly faulty)
- saas-16.2 (couldn't reproduce, but the line is present, so
possibly faulty)
- master (couldn't reproduce, but the line is present, so
possibly faulty)
opw-3246461
closesodoo/odoo#119072
X-original-commit: aaaae309d38651c9ce5cd63439695e858a7c047d
Signed-off-by: Piryns Victor (pivi) <pivi@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>
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
Problem:
Results do not show when users search the internal reference of the product template on the ecommerce page
if the product has other variants aside from itself.
The search only searches internal reference of product variants and not the product template.
Steps to reproduce on Runbot 15:
- Install Sales and eCommerce
- Create a product (can be sold), Set its Internal reference, and Add attributes and variants to the product --> Save
Note: the internal ref of the product variants are not set by default
- Go to ecommerce webpage and search the internal reference --> no product found
Proposed solution:
Add a condition to the domain to also search based on the internal reference of the product template
opw-3212883
closesodoo/odoo#116771
X-original-commit: 5f0578059fe436d770e38ca90d8311ee80301878
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps:
- In the global settings:
- Activate Comparison Price (group_product_price_comparison)
- Put Line Subtotals Tax Display to “Tax Included”
- Go to a product (e.g. Customizable Desk)
- Set Compare to Price to a higher price than the sales price
- Set a Customer Tax
- Go to the shop on the website
Issue:
The crossed-out price is not the same in the product list page and in the product detail page.
Cause:
No condition of the application of the tax on base_price.
Similar to: https://github.com/odoo/odoo/pull/113108/commits/8b7595deace98da26ee016ca565776ffd537284c
opw-3199343
closesodoo/odoo#116821
X-original-commit: b58014d87d9e7b9520ec8aff35395ec3d921c36e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Steps to reproduce:
1) website config: show strikethrough price (price comparison), show tax included price, discounts, pricelists(with advanced price rules).
2) create a pricelist with "show price and discount to customer", and any rule like 50% off any category (doesn't really matter).
3) apply the pricelist to the website
Issue:
Notice that some strikethrough price is applied wrongly - the crossed amount is the same as the written amount
Cause:
Strike is applied if base price not equal to price_reduce, which is actually calculated using taxes prior.
it should not be the case for the tax-included product ( or base price should also have tax applied).
opw-3140616
closesodoo/odoo#116668
X-original-commit: 58108a84946817175a07c5e8f09f7a5ba88266ee
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Problem:
The prices for products shown on the dynamic content: products on the website
can be displayed incorrectly.
Example:
Consider Product AB that is shared between Company A and Company B.
Company A sets Tax A for Product AB.
Company B sets Tax B for Product AB.
Product AB is published on Website A that belongs to Company A.
However, the price shown for Product AB on the dynamic content: products
is incorrect because the price includes taxes from both Company A & B.
Solution:
Filter the tax records based on the current context's allowed_company_ids.
The price for the product should only include taxes based on the website's company.
opw-3201283
closesodoo/odoo#115114
X-original-commit: 7046dd7c3095686c7cb33f441532e4234e8bdf1b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
To reproduce the issue:
1. Go to Settings > Website
2. Activate "Automatically send abandoned checkout emails"
3. Click on "Customize Abandoned Email Template"
4. Template "Gamification" appears
Error: The template "Ecommerce: Cart Recovery" should have
appeared instead
The hardcoded res_id was wrong
OPW-3207424
closesodoo/odoo#116440
X-original-commit: 92a9fe972337554f8dac8bad47e911f054fb27d9
Signed-off-by: Demany Antoine (ande) <ande@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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
The `website_id` field is defined in the `website_payment` but not used
for anything until `website_sale` is installed.
This commits moves the `_get_compatible_providers` override filtering
providers based on the current website from `website_sale` to
`website_payment`, where the `website_id` field is defined.
Task-3084364
closesodoo/odoo#111148
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Small correction to make the code more robust.
Technical note: we encountered a case where the group 'portal_customer' (to
classify recipient for mail_thread) where not present although it is added by
portal.mixin inherited by sale.order. That problem has been fixed since. So it
doesn't fix an actual problem but a potential one (condition of the "if" cannot
be false because the generator will generate an exception before).
Task-2674649
Part-of: odoo/odoo#103966
Various: im_livechat, rating, test_mail_full, website_{sale|slides}
Allows to rate any record extending mail_thread. This change was needed because
rating template could be created for any models, even those not inheriting from
rating.mixin. If sent on a record of such model, it was crashing when the
controllers using rating mixin features were used. This is no longer the case.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Base behavior accepts rating and provides an access to ratings through the
'rating_ids' field. Rating.mixin inherits now from mail.thread to ease
computation, and adds statistics and some advanced capabilities.
Inheritance of some model have been reordered now that rating is build on
top of mail.thread.
Task-2674649
Part-of: odoo/odoo#103966
This method is not used by rpc calls and wrongly allowed users to read the standard_price
field by calling the method through rpc.
Make it private to reduce its uses and avoid this potential leak of information.
closesodoo/odoo#113234
Signed-off-by: Victor Feyens (vfe) <vfe@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>
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>
Steps to reproduce:
- website settings, set "Display Product Prices" to "Tax Included";
- apply a tax A to a product;
- with Accounting app, create a fiscal position
which maps tax A to tax B;
- realize the ecommerce flow with a public user.
Issue:
We notice that the `/shop/product` page
does not have the correct fiscal position.
Cause:
We use the geoip in `/shop` but not in `/shop/product`.
opw-3078766
closesodoo/odoo#110197
X-original-commit: cb850a4ef8352a358b1c7d73a67e4e25ba0b4e38
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
In order to be able to do a pre or post processing on the order line
updates, we extract the code to a dedicated method.
i.e.: will be used in this PR: https://github.com/odoo/enterprise/pull/35689
opw-3099515
closesodoo/odoo#110082
X-original-commit: 7129806a9aad0ea87e0e73b9322b56006caed202
Related: odoo/enterprise#35879
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- go to e-commerce;
- add a product to the cart;
- add a gift card;
- remove the gift card form the cart.
(the user must not belong to the group 'base.group_system')
Issue:
A user error appears.
Cause:
The gift card is a product that cannot be added
to the cart like the others.
Therefore, an error is triggered.
Solution:
Make the error trigger only when adding products to the cart.
opw-3114090
closesodoo/odoo#109654
X-original-commit: 9cc699b89688261220aeb39a99fd866c27808d0a
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
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
Compare list price as base price or list price in comparison or comparison preview
task-2795129
closesodoo/odoo#87134
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce:
- Install `l10n_ar_website_sale` module
- Go to shop (Argentinian website) and add a product to cart
- Open cart and click on checkout
- Click on Customize and disable `Show b2b fields` feature
Issue:
Fields are no more displayed.
Cause:
Since the b2b fields template (`address_b2b`) is customizable (meaning
it can be enabled/disabled), it is possible for all countries to
display/hide the b2b fields, but for some countries (for example
Argentina) it should not; the b2b fields should always be displayed.
Solution:
Add a method (`_display_partner_b2b_fields`) on website model to know
if b2b fields should be displayed: return True if `address_b2b` view
is active on current website or if the company (based on the country)
must display them.
Move content (b2b fields; vat and company name fields) of view
`address_b2b` in `address` main view and let the `address_b2b` only be
used as switch to display or hide the b2b fields.
Add a condition in `address` view to display b2b fields only if the
method `_display_partner_b2b_fields` returns `True`
opw-2941199
closesodoo/odoo#104505
X-original-commit: 1b5c85722db00a44ed8c6cb0c2bdba8905dc5292
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- set a price on the product form;
- set a base unit count on the product form;
- define at least a pricelist with an other price;
- go to website on the product page;
- change the selected pricelist;
- change the Tax-Excluded/Included option.
Issue:
The base unit price ignores the tax included option.
Solution:
Update the display of the base unit price taking into consideration that it is not possible to set the "base_unit_price" field (otherwise we risk an AccessError).
Calculate the base unit price using "list_price" (which takes into account the tax) when we need to display it without saving.
opw-2995474
closesodoo/odoo#104302
X-original-commit: b766d68287b73b70a784e7291c567fb2e59de0c3
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit the base_unit_price was computed using the price of
the template instead of the list price displayed on the eCommerce, so it
sometimes made no sense when compared to another currency.
It will now be converted properly and use the list_price instead of
template price to compute the base_unit_price.
Some other issues with the base_unit_price display in the form view have
also been fixed (mainly mobile stuff)
TaskId-3006015
closesodoo/odoo#102884
X-original-commit: 7701033a4d480881d9e1d2c3c842150ca8f55aec
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The invoices and sale orders got a button "Preview" to reach their
frontend/website page. One of the goal is to then be able to enter edit
mode and customize it.
But since we merged frontend > backend with [1] (and multiple iterations
since then), landing on the frontend is not a good idea to do that as
you would then need to click on the "Editor" button to go back to the
backend and be able to enter edit mode. Now we reach the iframe preview
directly.
Note: this will be improved in a further update to not require a reload
of the backend when clicking on the button.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102787
X-original-commit: 007ae49e9c94061adf34aa9f911c7a9a0e873e0e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@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>
Walid