Since 3eb9680602, the signature of method
`_notify_by_email_prepare_rendering_context` has been changed to provide
a default values to `msg_vals` and some overrides were not adapted
(or have been added afterwards).
No true bug/issue has been found caused by that discrepancy, but for
consistency, this commit makes sure those overrides are adapted to
provide the same API as the parent method.
Fixes#162742closesodoo/odoo#163418
X-original-commit: d4b31842d6c3e1c5c86d9019a353601914ebf1f7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Standard `sale` tax flows rely on `_get_tax_included_price_unit`,
whereas part of `website_sale` flows do, while another part relies
on `_fix_tax_included_price_company`, which doesn't handle some
advanced cases (fiscal position mapping of price_included taxes).
This commit drops the use of `_fix_tax_included_price_company` in
website_sale, to only use the newest API of `_get_tax_included_price_unit`,
supposed to handle more cases.
Also makes all taxes computation go through a single entry point,
`_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product),
but not in `_get_sales_prices` (/shop page).
opw-3700803
original commit : 662ea281515156a781ab68079d0123ea45ebf40f
closesodoo/odoo#160198
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
separate the true computation of the tax value from the computation of the base unit price (uom & curr conversion, ...).
That way, the risks of unwanted side-effects is reduced when the base unit price is already computed (sale, website_sale).
Also allows preprocessing the taxes mapping, which doesn't have to be done multiple times when we compute different amounts for the same product/template.
original commit: bc79770d1e00cf86a46002d633afd8b32921610b
Part-of: odoo/odoo#160198
Wild try to avoid failures on runbot builds (not reproducible locally).
* simplify and split tour steps
* correctly specify check steps as isCheck: true
* make sure python setup is deterministic
* batch template creation to avoid creation of dummy archived variant
* target values for the variant to archive instead of its number in the
list of variants
runbot build error 25046
closesodoo/odoo#159372
X-original-commit: 9906785faf81d3152a94942f8e25827d2234db29
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
It cannot happen through the default SO form view, but some funny guys
have found other ways to do it, even though it can be quite problematic,
especially if the new pricelist is in another currency.
closesodoo/odoo#157742
Related: odoo/enterprise#58744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue
where the volume and weight were incorrectly computed
for carriers based on rules.
But it was done by changing the method api, which
seems to break some custom modules using/extending
the modified methods.
This commit reverts the API change, conveying the
needed information through the context for now
(the api change will be done in master only).
opw-3826165
closesodoo/odoo#159220
X-original-commit: d6e004b23822e98e8d1052b75b66a7d4f6d2c38c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
* Create a product tag (available on ecommerce)
* Select that filter on the /shop page
* Enter a search string
-> Traceback
The selected tag is given as a string to the
autocomplete route, and not a list of ids,
which fails when converted to an 'in' domain leaf.
`[('product_variant_ids.all_product_tag_ids', 'in', tags)]`
This commit makes sure to convert the given ids to a
list, correctly handled by the orm.
Fixes#155327closesodoo/odoo#155430
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In some conditions, a x2many field can be considered
as modified by the webclient when in fact there is
no change in 'meaningful' stored fields.
In this case, on save, an empty list of magic commands
will be sent to the server, potentially triggering
unexpected recomputations.
Steps to reproduce:
* install sale_stock & sale_management
* create a new storable product
* create a new SO
* create a new line with this product
* Confirm the SO
* Set or Update the SO delivery date (Other info tab)
* Save
-> In the chatter, you will notice an useless tracking
value being printed for the SO Total, with identical values
before and after update.
Cause
Since the server received an empty list of commands for
the `order_line` field, this triggered a recomputation
of the total amounts of the SO, even though there were no
effective changes in the lines.
Solution
Do not send empty command lists for x2m fields.
This will avoid unexpected recomputation and also improve
performance since the fields were recomputed for 'nothing'
closesodoo/odoo#155549
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This reverts commit 789186a43c.
The fix is not necessary in 17+ since the new onchange only
sends the necessary information and not the whole x2m record
data.
closesodoo/odoo#155550
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce
* Create a new SO
* Add a new line with a storable product and 15.12 as quantity
* change the price to X
* Save and confirm
* Set a scheduled date (Other info tab)
* Save
-> The price of the SOL is recomputed.
Cause
Because of floating point issues, the value returned by the onchange for
the product_uom_qty field is 15.1200000....1, therefore being considered
in the client-side as having been changed by the onchange.
The value is then sent to the server on save, triggering a recomputation
of the SOL prices.
Until there is a clear solution in the framework, this commit drops
'unmodified values' for the product_uom_qty field, only if there is
one updated line in the write call.
opw-3670318
closesodoo/odoo#155392
X-original-commit: ef1b59062266ee4ab58b5330ce0012dcee69f2b7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Updates to existing product configurations with custom attributes
were not correctly applied on configurator closure.
This was probably caused by a recent update in the framework.
Nevertheless, to solve the problem, this commit drops the use
of custom code used only by the configurator to stick to the
standard usage of magic commands.
closesodoo/odoo#152934
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since fd2fb212c5, the
sepa provider (enterprise module) behaves as a custom
provider but despite some adaptations, the removal
of providers on module uninstall was not properly
adapted.
The uninstall of the sepa provider failed as its
inline template was not unlinked from the provider
before the template deletion.
This commit makes sure that custom providers are
correctly considered in the uninstall util supposed
to restore a provider to its state before the
installation of its module.
opw-3734697
opw-3721846
closesodoo/odoo#153843
X-original-commit: e70dbbae56472b124a59c38a1fbfeea23c8ec28b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Rules always have a pricelist, so we can avoid an
useless database query when we are computing the
prices without any pricelist.
Also makes sure that the modified context used
for the pricelist items search is not propagated
by enforcing the same context in the returned
rules.
closesodoo/odoo#153624
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
While fixing a non deterministic test failing
on nightly l10n builds, slight incoherences between
sale & website_sale tax computation have been noticed
in the computation of the contextual price (used in
some snippets).
This commit fixes the test, making sure it doesn't fail on
l10n builds, but also uses the same tax util in website_sale
than in sale, to make sure the displayed amounts are coherent
(and supposedly correct).
runbot error: 52831 (& a bunch of others)
closesodoo/odoo#153299
X-original-commit: 91f9057c73810c34a4b0b85a60c84bb1c482efa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since 857c485175, rates are
not truncated anymore.
The stored rate value on SO, between SO currency and company currency
was not adapted and was still truncated, leading to invalid values
after rates conversion.
See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution
was appied to pos orders.
opw-3638199
closesodoo/odoo#152592
X-original-commit: 6291424bd49a55f446f87c09af71fd13a1c13851
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Summing discount percentages doesn't mean
anything.
This commit makes sure the operator used to
compute discount on group of records is 'average'.
It won't always be meaningful, but in some cases,
e.g. when the solines only hold one product,
and the lines are grouped by product.
opw-3649377
closesodoo/odoo#152455
X-original-commit: bf4aa3fdfcb6b2b3a5b4411130321e154fa098aa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The address displayed as 'Invoicing address' was
the main SO address and not the invoicing one.
Also, the pencil icon link to update the customer main address
was always displayed next to the invoicing address, even if:
* the so does not belong to the customer
* the invoicing address is different than the
customer main address
This commit fixes those two issues.
opw-3653190
closesodoo/odoo#152298
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
of check_company=True fields.
Suppose two models
class A:
company_id = fields.M2O() # not required
class B:
_check_company_auto = True
company_id = fields.M2O() # not required
a_id = fields.M20(check_company=True)
and the following code:
a = A.create({'company_id': 1})
b = B.create({'a_id': a.id, 'company_id': False})
The creation of B will fail because of the multi-company
checks, which is expected.
Nevertheless, since 0d30cc2bc9, the domain
of the field a_id would be:
(company_id and ['|', ('company_id', '=', False), ('company_id', 'in', [company_id])] or []) + ([])
which means that through the interface, if you create a record b following
the example above (no company_id on b), the evaluated domain would be empty,
allowing to select records of class A, even if they belong to another company.
Of course, this would lead to a multi-company error when trying to save the
record.
This commit makes sure that the right domain is applied on
check_company=True fields, even if the current record has no value
in its `company_id` field.
opw-3629374
closesodoo/odoo#151341
X-original-commit: aaddedc3bab4f16747fb0f71ae626d94f3975ee3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since 17.0 , calls to _get_combination_info on the
/shop/cart page were removed to avoid recomputing
values already stored on the cart, speeding up
the page loading.
See 824fc94bbc
Nevertheless, this highlighted the difference
in pricelist discount computation between sale
and website_sale.
In sale, the discount is computed while considering
the base price of the pricelist, whereas for
website_sale, the base price was always the sales price.
To make sure the crossed price displayed is the sales
price as before on /shop/cart, we override the default
sale behavior to force the sales price to be considered
as price before the pricelist discount.
closesodoo/odoo#151321
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Following a fix in 16.3 with 5052b9e4a15155c694cf005fdf330997770c6cac,
backported in 16.0+ with commit d28a8f67da06e58358b40636d1dca1f91a84e1ad,
the rates for the different carriers were computed on page loading,
to make sure unavailable carriers were hidden.
Nevertheless, this leads to significant increases of /shop/payment page
loading time depending on the enabled carriers.
This commit restricts the previous fix to the targeted type of carriers,
aka `base_on_rule` ones, whose rates do not depend on third party API
requests.
closesodoo/odoo#149657
X-original-commit: 99c8bda43f6f3bb027f8e03a753aaf2bb7ac585f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
1) Install and enable the "Onsite" payment provider;
2) As a public user, add product(s) to your cart;
3) Try to pay with the "Onsite" provider.
-> Internal Server Error
Cause of the issue:
In the log, the cause of the issue is an AccessError,
specifying that we tried to read the field `transaction_ids`
on a `sale.order` without having the necessary access rights.
This shouldn't happen, since the payment & ecommerce flows
are executed in sudo mode, after making sure that the cart
belongs to the customer.
After investigation, pending payment transactions trigger
1) the sending of a mail to the customer
2) the first mail generation will request the report assets
3) the generation of the report assets will create an
attachment and commit the transaction
4) committing the transaction will trigger a global
flush of the environment, forcing the computation
of pending mail wizard fields, with a different
environment than the sudoed one initiating the sending
of the mail.
This will lead to security errors as we try to access
`sale.order` fields content without having the rights
for it.
Standard fields being already in the cache, it will
be noticed when trying to read the `transaction_ids`
field.
Solution:
Manually prefetch the `transaction_ids` content with
the sudoed environment, since the records cache is
shared between the environments (until a more global
fix is found and deployed).
Introduced by #121376
opw-3628753
closesodoo/odoo#148199
X-original-commit: 511fe642b9860bd9d2f6b7ed728e7d3e6af48748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For each product of the shop page (if the template was enabled ofc),
a call to `_is_in_wishlist` would be made, triggering one query to find
the wishlist belonging to the current customer.
This is now done only once in the controller to load all the wishlisted
products.
This code was previously taking up to 15% of the loading time, even when
no wishlist were ever created on the database.
Now, in the best case (no wishlist, standard situation), the time taken
went down to 0.05% of the loading time, gaining > 100 ms of loading time
(when website_sale_wishlist is installed and the template is not disabled).
closesodoo/odoo#142860
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
After profiling and investigation of /shop route flamegraphs,
we have noticed that the rendering of attributes filters
is taking up to 70% of the loading time.
Since attributes are a not so frequently modified and do not depend on
any other contextual data, this part of the template can be easily
cached to improve loading time.
Part-of: odoo/odoo#142860
product prices are dependent of so many factors (taxes, pricelist, fiscal position, ...)
that caching them is either wrong or unproductive (because of the complexity of the cache to manage).
This commit removes this specific cache.
A dedicated performance review is done in the same PR to make sure
the performance is optimized as much as possible.
Part-of: odoo/odoo#142860
Checking on the searched products whether they have tags (through the field) before searching
for them is highly inefficient, will fill the orm records cache for "nothing",
and will be executed in slow, separate queries, highly slowing down the /shop
page loading time.
Part-of: odoo/odoo#142860
Customer should do it in two steps if that's really what they want to do.
This custom log was mainly intended to follow quantity changes on confirmed
orders, but it's plain wrong if the product is changed at the same time.
opw-3432715
closesodoo/odoo#142610
X-original-commit: dd526d049be27ac4852ac0eeaca04c3a2a36c39b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Added test for recent fix 495a5090a5
Also fixes a wrong recordset vs id comparison
closesodoo/odoo#141496
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* clean and improve docstrings in orm
* fix typos found with codespell
* rely on the Environment class docstring instead of doc content (and
therefore move part of the doc inside the class docstring)
closesodoo/odoo#102969
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* clean and improve docstrings in orm
* fix typos found with codespell
* rely on the Environment class docstring instead of doc content (and
therefore move part of the doc inside the class docstring)
closesodoo/odoo#102969
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Improved header (billing/shipping address instead of 'my details')
Keep the use_same input value on invalid form refresh
closesodoo/odoo#139474
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Address form forced the input of phone fields.
1) It only makes sense for shipping addresses by default, for delivery purposes
2) It was not properly handled in global checks, so you could do the whole
checkout flow without having a phone set on your address, but if you went to
the address page, you wouldn't be able to save as your phone would be invalid.
Side-change: do not check shipping address validity for orders without delivery
(only services).
closesodoo/odoo#138026
Related: odoo/upgrade#5248
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Avoid posting crappy forms when a redirection does the job
* use a dedicated route /shop/cart/update_address for address changes
* clean code from recent PR on invoicing address
* Public user shouldn't be able to create billing addresses
* Logged customer should always see his own partner as billing/shipping
address choices.
Part-of: odoo/odoo#138026
This reverts commit b1427153f8.
It seems that salesman likes to change payment terms on SO after the confirmation.
task-3562396
closesodoo/odoo#139258
X-original-commit: f83afeffeb30496ad55f901a529144db47942787
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When enable, this new feature adds the possibility to set a PDF header, footer and some product
documents to the quotation report.
These PDF can contains forms that'll then be filled using Odoo database.
This replace the previous sale quotation builder feature.
task-3249142
closesodoo/odoo#133773
Related: odoo/upgrade#5168
Related: odoo/documentation#5863
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
The value provided by the sale quotation builder feature is small due to many problems, and the
technical debt behind is high. For instance:
- The feature is nice but hidden: not visible on quotation, the most visible part is the button
"Design Template" on the quotation template (if you did activate the feature), it requires to have
eCommerce installed...
- The feature relies on fields that are shared with eCommerce which leads to unwanted behavior:
e.g. updating the bottom of the product page in eCommerce will impact quotation html description on
the portal
- The feature works as template but it is unclear for users: updating the HTML description on a
specific quotation will only impact that quotation. Updating the HTML page of a quotation only
update this quotation
- The feature is technically complex
As we want to keep most of the value of the feature but reduce its complexity, we remove the
quotation builder feature that'll get replace with the PDF quote builder feature.
task-3249142
Part-of: odoo/odoo#133773
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
the filename field shouldn't be 'false' but an empty string when
the binary file is deleted.
closesodoo/odoo#135894
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) fix automatic creation of documents when attachments are added
to product templates/variants chatters
2) fix duplication of documents
3) fix deletion of documents
Delete child record before deleting parent record.
Before this commit, when trying to delete a product document,
we deleted the parent record first, before trying to delete
the child, which had been deleted (cascade) already.
Part-of: odoo/odoo#135894
Carriers with no/invalid/incompatible rules shouldn't
be displayed in the checkout process.
opw-3413820
closesodoo/odoo#135717
X-original-commit: 5052b9e4a15155c694cf005fdf330997770c6cac
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Cache the fiscal position by request the same way it was
done for the pricelist, on the current website record.
Also clean and clarify the pricelist cache at the same time,
making sure invalidations are correctly handled, and that the
whole code relies on the unique logic (& field).
Part-of: odoo/odoo#121986
The prices displayed on the /shop page were not refreshed if the fiscal
position computed for the current partner was modified.
Part-of: odoo/odoo#121986
This method & logic is not used nor necessary anymore with
the multi-company fixes and improvements done in the recent years.
* All requests coming from website are automatically done in the website
company.
* check_company restrictions forbid the use of records from different companies
* multi-company security rules restrict the access to records from the current
company.
Part-of: odoo/odoo#121986
There is no need to manually add the pricelist context for ecommerce
flows anymore, it is automatically managed in `_get_contextual_pricelist`
override of website_sale.
Part-of: odoo/odoo#121986
Clean all code related to _get_combination_info:
* Move logic to website_sale now that backend configurator doesn't
rely on it anymore. Only frontend configurator uses that logic.
* Make sure the returned information is correct and consistent:
* request must be given the right context (multi-company)
* behavior is coherent between modules and overrides (date, company, currency, rounding)
* Performance:
* Avoid loading unnecessary information
* Avoid calling _get_combination_info when only part of the data is necessary.
* Clean/simplify uses and overrides by keeping useful information in the combination_info dict (taxes, currency, ...)
* Code cleanup
* clean imports
* clean architecture
* clean templates
* move old configurator code to website_sale
Now that the product configurator backend side has been redone
completely, the remaining parts previously shared between backend
and frontend configurators can be moved to website_sale because only
used by the frontend configurator.
Part-of: odoo/odoo#121986
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
Since the new product catalog provides filtering by product categories, and the pricelist rules have long been configurable by product categories, it makes sense to allow users to configure categories directly in the sales application.
closesodoo/odoo#133063
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since 6f182eeeab,
UoM should be created through the UoM category tab as the UoM form view is now unusable.
Previous bugfix commit 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef disabled
the menu from the different applications, but later changes in sale
brought back the menu again.
Since it doesn't hurt to have the menu in debug mode, the lowest solution
would be to disable the creation of uoms from the uoms tree view.
closesodoo/odoo#131237
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The 'onsite' payment provider shouldn't be shown to the user
if the cart/order only contains services (or if there are no onsite carriers).
The logic was there but the filtering didn't correctly update the values.
opw-3437107
closesodoo/odoo#131177
X-original-commit: 78cd9a7ab5fb860021a906400a1907b1d8b45be2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If a given template T has two attributes lines:
* standard attribute (instant creation): one value
* no_variant attribute (never create a variant for it): one value
It will have one automatically generated variant V, which will be automatically
selected on the sale order line if you chose the template T.
If optional product(s) are added on the template T, the configurator will
open to choose the optional products.
But in this situation, the main product was shown as "Option not available"
on the configurator. This is wrong since there is the valid variant V that we
can use.
This is caused by a behavioral change in 16.0, we saved the variant V directly
on the sale order line, before opening the configurator. Previously, the values
were applied to the line after the configurator was closed (if there were optional
products).
As the values were applied before the call to `_openProductConfigurator`,
the product.template.attribute.value of V (the standard one, not the no_variant)
is given to the wizard opening, disabling the automatic fallback that previously
gave the two expected ptav's (the standard AND the no_variant one), leading to
an incomplete combination, which was considered invalid.
This commit restores the previous behavior, by setting the product on the line
only if there is no optional products. If there are, everything will be
correctly managed when the configurator is closed.
opw-3355216
closesodoo/odoo#131147
X-original-commit: 902c7112c75841ede560c51d54e12e9cf809ee8c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Values removed from the product should be hidden instead of being shown
as forbidden values.
opw-3434706
closesodoo/odoo#131145
X-original-commit: 9a581c46dca46ad44957cf1a47748f0c56ad07ca
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Users are not able to reorder lines on order having more
than 40 lines as only 40 lines are shown by default.
In some advanced flows, new lines are automatically added to the
end of the lines and the user has no way to move them back in
the first ones (or in a specific section if it's not on the same
page).
opw-3437983
closesodoo/odoo#130956
X-original-commit: b316cd61bff1c05f8b07d036e9c0409998982a69
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Impose the use of the dedicated tour utils to factorize and harmonize
the way tours behave on the ecommerce.
* Introduce new utils when it seems adequate and useful.
This will reduce incoherences and non determinism in e-commerce tours,
and ease future tasks refactoring the e-commerce design and process
(since we'll be able to restrict most changes to the utils instead of adapting
all the tours one by one).
closesodoo/odoo#130378
Related: odoo/enterprise#44938
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Unless necessary, super should be called first, delegeting ensure_one()
and base logic to the base method.
closesodoo/odoo#129572
Related: odoo/upgrade#4987
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There is no need to have two bridges linking delivery & loyalty.
The two modules held the two parts of the same logic, making no
sense to keep the two modules separate.
Task-3420579
Part-of: odoo/odoo#129572
The test test_update_cart_zero_qty was checking the total amount
of the cart, but depending on installed localizations, the taxes
vary and the test can fail.
This commit changes the check to the untaxed amount to make sure
the test only depends on the sales price of the product defined in
the test setup.
closesodoo/odoo#130319
X-original-commit: a2c693795081953ed0ba07bfad210701fcf6f1f0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The test test_product_quantity_rounding fails when the currency
of the company rounds to the unit (decimal places = 0).
This commit makes sure the test doesn't fail with that setup.
Cf runbot build error 20612
closesodoo/odoo#130285
X-original-commit: fae7beacd950fcc349728f98681b6aa281572aa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The default pricelist automatically created for companies if the pricelists
are enabled should (like it was before with the Public Pricelist record in
the data) take precedence over newly created pricelists record.
This can be enforced by creating the default pricelist with a higher priority
(lower sequence).
closesodoo/odoo#130232
X-original-commit: ea1e83514bd6190a516f2cf92f800625876b789e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The test verifying the values of the sale report in a multi-comp & multi-curr
environment relies on the fact that the main company is by default in USD.
Nevertheless, the test fails when a localization is installed (if it changes
the currency of the main company).
This commit makes sure the tests always works, and resurrects the right tool
for that, which was dropped in commit 3752b3166e.
Cf runbot build error 22351
closesodoo/odoo#130201
X-original-commit: a73b5fce4fb02eefc681c55eab8f57cd35105226
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Generate account payments (and require a journal)
* Be displayed as their custom mode instead of always 'Custom'
...
Commit also includes some side bugfixes/cleanup
task-3347338
closesodoo/odoo#126929
Related: odoo/enterprise#43418
Related: odoo/upgrade#4944
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When the cart has a zero amount (because of pricelist, coupons, ...),
providers are not loaded nor displayed.
Furthermore, if there is no need for delivery (because the cart only
contains services), delivery carriers logic is not loaded either.
In this case, without carriers nor providers managing the disabling/enabling
of the confirmation button (o_payment_submit_button), the base logic handling
the T&C checkbox didn't properly enable the button when it should have.
Introduced by 608e90e998, already fixed
for payment form by 04059d09dfd7dc57a5c86c842d6fea300e1441aa
opw-3418472
closesodoo/odoo#127950
X-original-commit: d3bcf03adb93d2727ed81e1b9ffe0a2bbc5707b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Public users do not belong to "feature" groups, so anonymous users
downloading their SO report thanks to the access_token won't ever see
the discount column as the user of the request doesn't belong to the
"Discount" group.
opw-3322583
closesodoo/odoo#129962
X-original-commit: 369d71b9fb013dc87c311da6fbad47692bfcbdaa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
1. Create a product "My Test Product" (no attribute)
2. Create a quotation, select the "My Test Product" product and confirm the sale order
3. Go back to product and add an attribute "Size" with values "L", "XL"
4. Create another quotation, select the ""My Test Product" product => crash
We consider archived combination of attributes as forbidden combination in
the configurator, but when the archived product doesn't have any attribute,
the `archived_combination` was an empty list, which wasn't supported well
by the product configurator logic (client-side).
To quickly fix this issue, we can simply stop sending empty archived combination
(i.e. when the archived product had no attributes).
opw-3410383
closesodoo/odoo#127335
X-original-commit: ca1ac1a115fe06a0a2d2de0fb131a58019f73631
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If a cart has multiple lines with the same product (custom/no_variant attributes),
opening the reordering wizard on the portal would fail, because the key used in
foreach would be the same for multiple iterations.
closesodoo/odoo#126151
X-original-commit: 80bce88e73770debe64fb401003dac35cb4f6785
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Commit b30afcbdb9 introduced
a strange logic where the invoice status was magically considered
invoiced on locked orders if there was no pending stock logic and
the full delivered qty was invoiced.
Following our removal of the locked status, replaced by another boolean field,
we consider it's wrong to rely on the locked status for functional logic,
therefore removing this old logic.
If it's really a problem (and comes back in the future), another clean solution
will be thought and implemented.
task-3163931
Part-of: odoo/odoo#115871
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
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>
The whole contextual price of products relies on multiple context keys:
* uom
* pricelist
* quantity
* date
The related logic has already been partly removed/deprecated on products,
but the computation of discounts for events/event booths are still relying
on that logic, though imperfectly.
This commit makes sure this hacky logic (relying on those contextual keys)
is as clear and reliable as possible.
We factorize and harmonize the remaining use cases, with a dedicated constant
and specific methods, making sure:
* currency conversion
* price & discount computations
are coherent, while clearly explaining that it should not be used for
any new feature/logic/code.
We also restrict context updates as much as possible (there won't be
any discount when the pricelist is configured to hide the discount from the customer)
closesodoo/odoo#123848
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since d88409e8e5ce77ff3ec3b24fcdc108d8df380994, taxes from different companies
are forbidden on sale.order.line records (which is the expected behavior).
Nonetheless, this highlighted some flows where the taxes were not properly
set/recomputed, especially re-invoicing, which is fixed by the current commit.
Fixes#123675closesodoo/odoo#125434
X-original-commit: 6ce4019968bd0a1a11475910d35aa2ccfc2c6a9a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
So that we can in the future harmonize more easily the discount
computation between sale, point_of_sale, e-commerce, ...
closesodoo/odoo#123849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Victor Feyens