In 5c2380e9f an issue when modifying variants values was solved when an
attribute on the product variant had "create_variant" unset.
This commit forward-port what was lost of it in 11.0, that part was
probably lost because the code was previously changed when adapting to
python3.
Without the change, the added test failed creating a new variant keeping
the existing one. With this change, 'nocreate' value are ignored when
computing new variants to create.
opw-1815226
closes#23332
Changes to a bank account should not be happening without approval and
not in an in-transparent way. In some cases, a third party can pay an
invoice for another account
opw-1817138
Steps to reproduce the bug:
- Go to Fleet
- Group by status
- Click on a vehicule
- Click on Costs
Bug: A traceback was raised because a group_by was made on the model "fleet.vehicle.cost"
for the field "state_id" and this field doesn't exist on this model.
opw:1815454
- Removed 'Invoices' and 'Credit Notes' filters.
- Removed inherited view of filters to remove the 'Not Draft' filter.
- Renamed 'Not Paid' to 'Open' filter.
- Added new filter 'Paid'.
- When click on 'Invoices/Bills' or 'Credit Notes' link of 'View'
column from 'Customer Invoices' and 'Vendor Bills' dashboard, it
should be open invoices with a specific domain instead of default
filters.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1817236
Previously, bank accounts were created at the line creation, even if the partner was unknown. That was a very weird behavior since
- that use case of a res.partner.bank belonging to no one is meaningless
- the default partner was actually set to the current'user company, which was even more wrong.
This has been already improved by https://github.com/odoo/odoo/commit/7b322d08de2b5343cdf6935a7ae4a12f1fd61958 but that first patch ignored the use case of res.partner.bank created thr$
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
Currently the rating value coming from the rating application is stored
on the message it belongs to. However storing it is not necessary as
there is no direct search using it. Having a computed field is sufficient
for all use cases we currently have in Odoo.
Removing the store allow to gain queries. Indeed the field is not
computed anymore after each message creation meaning we save queries
by not having to check existing ratings. It allows to gain a lot of
computation as mail.message is a critical model.
On the whole community runbot when installing all modules this leads to
a gain of more than 14K queries on 585K which means 2.4% of performances
increase. Considering the code size of this optimization this is quite an
interesting result.
Looking at test_mail performance tests we gain several queries (2/3) for
each new message which is coherent with the model change.
Finally it allows to lessen the performance difference between tests done
with test mail only and tests done with other modules already installed.
This is especially simple mail thread-enable records.
Related to task ID 51523. #Closes #23294. Done with blessing of @jem-odoo .
From time to time, it happens that a developper forget to remove debuggers.
This commit adds a test to find such imports (pdb and pudb). The test
will fail if that kind of import is found. The Odoo runbot should run
this test and prevent developper from those small mistakes.
Before this commit, while performing a check on whether a customization
being imported was done using studio or not, we would assume that the
.zip would, at the very least, contain a data folder.
This is not the case as loose files can be imported and the data folder
is only generated by studio customizations.
To solve this, we walk over the whole zip instead of walking over the
data/ folder only (which may be non-existant), so loose files, files
inside the data folder and potentially files in other folders can be
parsed without raising unexpected errors.
Previously, trying to register a payment on today towards an invoice posted with a date prior to the FY lock date, was raising an error... which was completely wrong.
Previous to this rev.:
*Install stock w/ demo data
*Uninstall stock
*Reinstall stock
Result: Boom! Installation crashes.
Reason: The demo data installed with stock is not properly deleted after
the module is uninstalled, which causes issues/conflicts upon
reinstallation of the same demo data.
Solution: Remove any demo data of stock models upon installation if any
exist through a pre_init_hook, ideally this would be done by overriding
the unlink() of the affected models / setting some ondelete='cascade',
or even a uninstall_hook, however these solutions prove insufficient for
databases that are currently affected by the problem.
Fixes#22243
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Purpose of this merge is to clean a bit various methods and remove some
dead code. All those commits come from other work-in-progress branches
in mail aiming at improving performances and reducing code size. We can
already merge some light cleaning in order to lessen diff and ease
understanding of real feature-based branches.
It contains
* some renaming in notification methods to match the _notify prefix used
in most of them;
* removal of some dead code coming from old implementations of chatter;
* removal of unnecessary context switch in email sending process;
* small cleaning of notification group methods in various addons;
It allows to gain some queries in various test_mail performance test as
stated in the test_performance file update. When notification emails are
sent 4 queries are gained with this merge. On the whole community runbot
the impact is small (about 1K queries) probably because most of email
sending part is skipped on runbot.
This merge is related to the task Id 59039. #Closes #23089.
Overrides of _notify_get_groups are used to add some buttons in notification
emails and control the display of "Access document" button. This commit
cleans some overrides :
* accounting: portal users that are not the customer have no access to the
invoice and should not have the access button;
* project: remove unnecessary override on project model and consider portal
users have access to the document through customer portal;
* sale: portal users that are not the customer have no access to the sale
order and should not have the access button;
* website_blog: display access button to everyone only if the post is
published; otherwise keep standard behavior;
* website_forum: display access button to everyone only if the post
has not been closed or deactivated; otherwise keep standard behavior;
* website_slides: display access button to everyone only if the slides
has been published; otherwise keep standard behavior;
Send methods of mail.mail model are set private and simplified. Those
methods have been written when a lot of overrides were necessary to
generate notification emails. Since then the flow has changed but
methods have not been updated completely. This commit therefore simplified
a bit the call chain and parameters.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
Commit 0d3d0e9563 added a key in context when sending emails to know
the target model name. It was used at that time to forge for footer of
notification emails.
Since that time notification emails have evolved a lot. The code based on
that context key has been removed. Context key has been transformed into a
context switch. However it is not used anymore and can be removed. It allows
to clean a bit the code and save a context switch.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit allows to gain some queries in mail sending process, meaning
removing context switch is interesting. One query is gained when using
the send process. Complex performance test involving several message post
gain 3 queries each.
1d57a09112 added a two-steps parent fetch when posting a message
on a discussion thread. At the time this commit was done responsible were
notified of the first thread message. It was helpful to notify them of the
original email that created the thread instead of the "document created"
generic message. Indeed for documents like leads or issues having the
original email containing the customer question is interesting when being
notified. This is why this commit was done.
However since quite a long time responsible notifications have changed.
They now receive an email notification telling they have been assigned on
a document. This commit is not necessary anymore and we therefore remove
it in order to clean a bit the message_post process.
This commit globally reverts 1d57a09112. Please note that @beledouxdenis
agreed after a long thinking.
This commit has a slight impact on mail performance tests, allowing to save
one query in some more complex test case.
- set due date based on payment terms at generation for recurring bills
- do not generate "This vendor bill has been created form POXXX" for bills that have been generated by cron
Before this rev., it crashed when trying to create records of the
res.users model. This is due to commit ad1cceb.
The 'default_get' of 'res.users' always returns a value for field
'groups_id', whereas the docstring of 'default_get' states that it
only returns default values for fields given in arguments.
Rev. ad1cceb changed a bit the way the result of 'default_get' was
processed, by iterating over the values instead of over the fields
in the view. So, before ad1cceb, 'groups_id' was simply ignored,
and after, the BasicModel tried to process it and it crashed when it
attempted to retrieve its fieldsInfo, as this field isn't in the
view.
This rev. restores the previous behavior.
Fixes#23303Fixes#23305
Purpose of this commit is to simplify a bit message_post API. It has
a content_subtype parameter allowing to receive plaintext content.
It is then automatically converted into html.
This commit removes the parameter and consider the content is always
html. Code calling message_post should handle the conversion. In Odoo
the only use was in the chat_post controller that now perform the
plaintext to html conversion before calling message_post.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
Posting on users is not supported anymore. It was implemented in a time
we thought having a twitter-like behavior in Odoo was a good idea.
Posting on users was redirected on its related partner in mail. It was
redirected on its related employee in hr. It does not make sense anymore
as employee are records with limited access and partners used for other
purpose than discussing notably in accounting.
Now that we have chat channels it makes no sense to have this kind of
behavior still implemented. Let us remove it. No functional change
should occur with this commit.
Propagation was not correctly done at 8a026e26c6 . This commit
ensures all parameters are passed to sub-calls when redirection is done
in message_post.
Before this commit, doAction returns a deferred that is
resolved when the action is performed (the exact moment
depends of the type of the action).
However, the deferred was not resolved with the action.
This is misleading, hence a traceback in the web_client
when clicking on 'Run JS Tests' in debug mode (enterprise):
after doAction, the web_client should hide the home_menu
depending on the type of the action.
With this commit, any doAction returns a deferred that is
resolved with the performed action.
When uploading an image as attachment, the document viewer doesn't
support the EXIF data. Therefore, a picture taken with a non-zero angle
will not appear with the right orientation (preview or full-size image).
Unfortunately, supporting EXIF data is not trivial in Python or
JavaScript without external libraries. Therefore, we add a rotate button
which allows the user to rotate the image by 90°. Moreover, we add the
`image-orientation: from-image` CSS property, which is only supported by
Firefox.
opw-1814407
Let's assume a one2many displayed over several pages with a default
order such that a record, say R, that would normally be on page 1
is actually on another page. Moreover, there is an onchange on that
one2many which converts all commands 4 (LINK_TO) into commands 1
(UPDATE), which is standard in the ORM.
When the first line of the one2many was edited, the record R was
fully loaded, whereas it shouldn't have been (as it is not on the
current page). So basically, a useless read was performed.
Moreover, if there was an x2many field in the one2many list, a
crash occurred because relational data of R that shouldn't have
been read wasn't postprocessed by the BasicModel.
The useless read occurred because the one2many subrecords weren't
correctly sorted before checking if some of them/some of their
fields should be read. This is not the case anymore.
OPW-1816800
A customer can pay an order with a non-cash journal (e.g. a credit
card through a stand-alone terminal).
When this order has to be refunded later it should be possible to do
so on that same journal.
Some code prevented this from happening, notably a check in
order_is_valid which explicitly prevented this for an unknown
reason. There is no explanation in the
commit (4647f896a4) introducing that.
This commit allows the following:
1. input what you want to refund with a negative qty
2. click 'Payment'
3. click the Credit Card (type Bank) journal
4. (amount is auto-populated)
5. click 'Validate'
opw-805302
Commit a42c27f99e0061b7c4f recently fixed some bugs on sale_coupon.
This commit add some tests to be sure theses bugs are fixed and won't appear
again.
This closes#1744
Commit a42c27f99e0061b7c4f recently fixed some bugs on sale_coupon.
This commit add some tests to be sure theses bugs are fixed and won't appear
again.
This closes#1744
Commit a42c27f99e0061b7c4f recently fixed some bugs on sale_coupon.
This commit add some tests to be sure theses bugs are fixed and won't appear
again.
This closes#1744
Some use cases were wrong, this commit attempt to fix those.
Here is the most important ones:
1. Discount was offered on free product 'value' aswell
Cart: 4 iPad Mini + one free offered + 10% discount
| qty | unit value | line total |
----------------------------------------------------
iPad Mini | 4 | 320 | 1280 |
- 10% discount| 1 | 128 | 128 |
= 1152
- free product| 1 | 320 | 320 |
= 832
Should be
| qty | unit value | line total |
----------------------------------------------------
iPad Mini | 4 | 320 | 1280 |
- free product| 1 | 320 | 320 |
= 960
- 10% discount| 1 | 96 | 96 |
= 864
The error result is $32 which is the 10% discount applied on the free iPad.
2. Decreasing product quantity below the minimum threshold to be elligible for
the promotion doesn't remove the product
- (With a promotion offering a free iPad when you buy 3 (fourth is free))
- Create a quotation with 3 iPads Mini, save and update promotions, you don't
have a free one, which is 'correct'
- Edit, change the quantity to 4 iPads, save, update promotions, you have a
free iPad (reduced from total), still correct
- Edit, change the quantity back to 3 ipad, update ptomotions, you still have
a free iPad even if you only bought 3 of them (the way it is designed, the
free iPad should only appears when you order your fourth).
The error result in a 'loss' of $320 since at the end we are offering a free
iPad and the user only pays 2 instead of 3.
3. Free product will be considered as regular product when updating quantity
of regular product afterward
This error is kind of exponential: the more you play with the flow explained
bellow, the more incorrect it becomes.
Buy 100 iPads, get 25 free iPads.
Then set quantity (on regular iPad) to 50, it will recalculate the amount of
free iPad thinking the 25 previous free iPads are regular iPad.
(50 + 25) = 75 regular iPads = 18 free iPads (25 previous free iPads were
wrongly used for the calculation but they are simply gone at this point).
Cart is now 50 regular iPads and 18 free one, total: $10240 (50×320 - 18×320).
It should be 12 free iPads, not 18, so $12160 (50×320 − 12×320)
The error result in a loss of $1920: ~ 20% of the total amount of the order.
This error will also appear the other way around if you add quantity instead of
removing some.
Playing with this error multiple times, you can arrive to a negative total
(more free than paid products), 0 total or very low total ($320 for 100 iPads).
4. Free product are wrongly calculated, user get too many of them
- Create a quotation with 10 iPads, you get 3 free iPads instead of 2
- Indeed, your first 4 iPads should give you a free one
- Your next 4 iPads should give you a second one (you got 8)
- The last 2 (to reach 10) are not enough to give you a third free iPad
The error result in a loss of $320 out of a total of 2560$ which is ~ 15%
5. Paid/regular products related to a promotion won't be taken into account
when checking if you have the minimum amount threshold to apply the promotion
Promotion: 3 Computer Case(25$) = 1 Free Little Server (40.000$), auto applied
-Have a cart with 3 'Computer Case' and 2 'Little Server'
-One little server of the 2 is free (because you have 3 computer cases)
-You so pay 3x25 + 1x40000 which is 40075$
-Create a promo code that will give you 10% discount if you bought over $2000
-You won't get the reduction even if you bought over $40.000 because the
little server you pay is considered as the product of the reward product
even if you dont have it free. It doesn't check how many regular product
should be substracted according to the number of free product you have
6. Wrong product is checked for the required quantity to apply the promotion
Promotion: 3 iPads Mini ($320) = 1 free Bose Mini Bluetooth Speaker ($247)
- Add 8 iPads Mini and a Bose Mini Bluetooth Speaker to your cart
- The system should give you a free Bose Mini Bluetooth Speaker since you
only have one regular Bose
- But the system is giving you 2 free Bose Mini Bluetooth Speaker
Cart is: 8 iPad ($2560), 1 Bose ($247), 2 free Bose (-$496)
The system think that it should give you 2 free Bose because you are eligible
to, since you have 8 iPad, but it doesn't check that you have enough regular
Bose.
The error result in a loss of $247 out of a total of $2311
7. Auto applying promotion are not applied if there is already a promotion code
Promotion:
- Free iPad Mini if you buy 3 (so the fourth become free), auto applied
- 10% discount with code '10pc'
- Add 4 iPads Mini, you got a free one
- Set quantity back to 1 iPad, free one is gone
- Add code 10pc, you got a 10% reduction line
- Set quantity to 4 iPads again, you dont have the free iPad since there is
already a promo code
This could make sense but it is not coherent since the 2 promotions would be
applied if they were both on auto apply mode.
Note:
- If both promotions are on auto apply, you will get both
- If 10% discount becomes auto applied and iPad promotion now has a code
(reverse situation) it will work
8. Discount is only applied on untaxed amount, not on tax
Discount will ONLY be calculated on the untaxed amount and then reduced from
the sale order/cart total.
The taxes would be unchanged and charged like the product was full price.
Let's illustrate with a $100 product, a 15% tax and a 20% discount:
1. Tax included:
$100 : Product with 15% included taxes
$86.96 : Untaxed product
$13.04 : Taxes
After aplying 20% discount, result should be:
$80 : Product with 15% included taxes
$69.57 : Untaxed product
$10.43 : Taxes
Instead we have:
$82.61 : Product with 15% included taxes
$69.57 : Untaxed product
$13.04 : Taxes
There is a difference of $2.61 which is the result of the taxes not being
discounted: 13.04-10.43 = 2.61
2. Tax excluded:
$115 : Product with 15% excluded taxes
$100 : Untaxed product
$15 : Taxes
After aplying 20% discount, result should be:
$92 : Product with 15% included taxes
$80 : Untaxed product
$12 : Taxes
Instead we have:
$95 : Product with 15% included taxes
$80 : Untaxed product
$15 : Taxes
There is a difference of $3 which is the result of the taxes not being
discounted: 15-12 = 3
9. Taxes of the free shipping reward would be considered as paid value when
checking if required threshold is met.
------------------------------------------
Not really a bug, more an improvement:
1. The way it was designed, the rule_minimum_amount would check if your order
amount was over the required threshold to be eligible for the reward.
'Problem' is that it your order has already a discount (eg: 10%), it would
check if the price without discount is above the required amount.
I don't think it is coherent, let's illustrate:
- First pomotion (auto applied): 1 iPad Mini for free if you buy over $2000
- Second promotion (auto applied): 50% on order
If an user is buying for $2000, he is actually paying $1000 thanks to the 50%
discount.
Should we give him the free iPad?
The current implementation is giving it, which is not convenient IMHO.
Now, we use the amount the user really pay to check if he is elligible.
2. Since new promotions have the same sequence by default, they will be sorted
and applied by their creation order. This will result in inconsistent behavior:
- Promotion 1 : 10% discount
- Promotion 2 : free shipping
- Both promotion are auto applied and need a minimum of $872.73 tax excluded
Let's illustrate with a $873 order:
If the promotions were created in the order above, you won't get both rewards
since the 10% discount will be applied first and will lower the SO total.
The order will then fall below the $872.73 required amount and won't be
eligible for the free shipping.
But if you created the free shipping promotion before the discount one, you
will be eligible for both since the free shipping will be applied first and
won't change the SO total.
To keep the same behavior independently of the promotion creation order, we now
sort by reward_type ('discount' > 'free_shipping' > 'product' to apply
discounts first.
This is better IMHO, since you want to give promotions with a minimum threshold
ONLY if the user really pays that amount. It wouldn't be the case if the total
is checked before the discount is applied.
Some use cases were wrong, this commit attempt to fix those.
Here is the most important ones:
1. Discount was offered on free product 'value' aswell
Cart: 4 iPad Mini + one free offered + 10% discount
| qty | unit value | line total |
----------------------------------------------------
iPad Mini | 4 | 320 | 1280 |
- 10% discount| 1 | 128 | 128 |
= 1152
- free product| 1 | 320 | 320 |
= 832
Should be
| qty | unit value | line total |
----------------------------------------------------
iPad Mini | 4 | 320 | 1280 |
- free product| 1 | 320 | 320 |
= 960
- 10% discount| 1 | 96 | 96 |
= 864
The error result is $32 which is the 10% discount applied on the free iPad.
2. Decreasing product quantity below the minimum threshold to be elligible for
the promotion doesn't remove the product
- (With a promotion offering a free iPad when you buy 3 (fourth is free))
- Create a quotation with 3 iPads Mini, save and update promotions, you don't
have a free one, which is 'correct'
- Edit, change the quantity to 4 iPads, save, update promotions, you have a
free iPad (reduced from total), still correct
- Edit, change the quantity back to 3 ipad, update ptomotions, you still have
a free iPad even if you only bought 3 of them (the way it is designed, the
free iPad should only appears when you order your fourth).
The error result in a 'loss' of $320 since at the end we are offering a free
iPad and the user only pays 2 instead of 3.
3. Free product will be considered as regular product when updating quantity
of regular product afterward
This error is kind of exponential: the more you play with the flow explained
bellow, the more incorrect it becomes.
Buy 100 iPads, get 25 free iPads.
Then set quantity (on regular iPad) to 50, it will recalculate the amount of
free iPad thinking the 25 previous free iPads are regular iPad.
(50 + 25) = 75 regular iPads = 18 free iPads (25 previous free iPads were
wrongly used for the calculation but they are simply gone at this point).
Cart is now 50 regular iPads and 18 free one, total: $10240 (50×320 - 18×320).
It should be 12 free iPads, not 18, so $12160 (50×320 − 12×320)
The error result in a loss of $1920: ~ 20% of the total amount of the order.
This error will also appear the other way around if you add quantity instead of
removing some.
Playing with this error multiple times, you can arrive to a negative total
(more free than paid products), 0 total or very low total ($320 for 100 iPads).
4. Free product are wrongly calculated, user get too many of them
- Create a quotation with 10 iPads, you get 3 free iPads instead of 2
- Indeed, your first 4 iPads should give you a free one
- Your next 4 iPads should give you a second one (you got 8)
- The last 2 (to reach 10) are not enough to give you a third free iPad
The error result in a loss of $320 out of a total of 2560$ which is ~ 15%
5. Paid/regular products related to a promotion won't be taken into account
when checking if you have the minimum amount threshold to apply the promotion
Promotion: 3 Computer Case(25$) = 1 Free Little Server (40.000$), auto applied
-Have a cart with 3 'Computer Case' and 2 'Little Server'
-One little server of the 2 is free (because you have 3 computer cases)
-You so pay 3x25 + 1x40000 which is 40075$
-Create a promo code that will give you 10% discount if you bought over $2000
-You won't get the reduction even if you bought over $40.000 because the
little server you pay is considered as the product of the reward product
even if you dont have it free. It doesn't check how many regular product
should be substracted according to the number of free product you have
6. Wrong product is checked for the required quantity to apply the promotion
Promotion: 3 iPads Mini ($320) = 1 free Bose Mini Bluetooth Speaker ($247)
- Add 8 iPads Mini and a Bose Mini Bluetooth Speaker to your cart
- The system should give you a free Bose Mini Bluetooth Speaker since you
only have one regular Bose
- But the system is giving you 2 free Bose Mini Bluetooth Speaker
Cart is: 8 iPad ($2560), 1 Bose ($247), 2 free Bose (-$496)
The system think that it should give you 2 free Bose because you are eligible
to, since you have 8 iPad, but it doesn't check that you have enough regular
Bose.
The error result in a loss of $247 out of a total of $2311
7. Auto applying promotion are not applied if there is already a promotion code
Promotion:
- Free iPad Mini if you buy 3 (so the fourth become free), auto applied
- 10% discount with code '10pc'
- Add 4 iPads Mini, you got a free one
- Set quantity back to 1 iPad, free one is gone
- Add code 10pc, you got a 10% reduction line
- Set quantity to 4 iPads again, you dont have the free iPad since there is
already a promo code
This could make sense but it is not coherent since the 2 promotions would be
applied if they were both on auto apply mode.
Note:
- If both promotions are on auto apply, you will get both
- If 10% discount becomes auto applied and iPad promotion now has a code
(reverse situation) it will work
8. Discount is only applied on untaxed amount, not on tax
Discount will ONLY be calculated on the untaxed amount and then reduced from
the sale order/cart total.
The taxes would be unchanged and charged like the product was full price.
Let's illustrate with a $100 product, a 15% tax and a 20% discount:
1. Tax included:
$100 : Product with 15% included taxes
$86.96 : Untaxed product
$13.04 : Taxes
After aplying 20% discount, result should be:
$80 : Product with 15% included taxes
$69.57 : Untaxed product
$10.43 : Taxes
Instead we have:
$82.61 : Product with 15% included taxes
$69.57 : Untaxed product
$13.04 : Taxes
There is a difference of $2.61 which is the result of the taxes not being
discounted: 13.04-10.43 = 2.61
2. Tax excluded:
$115 : Product with 15% excluded taxes
$100 : Untaxed product
$15 : Taxes
After aplying 20% discount, result should be:
$92 : Product with 15% included taxes
$80 : Untaxed product
$12 : Taxes
Instead we have:
$95 : Product with 15% included taxes
$80 : Untaxed product
$15 : Taxes
There is a difference of $3 which is the result of the taxes not being
discounted: 15-12 = 3
9. Taxes of the free shipping reward would be considered as paid value when
checking if required threshold is met.
------------------------------------------
Not really a bug, more an improvement:
1. The way it was designed, the rule_minimum_amount would check if your order
amount was over the required threshold to be eligible for the reward.
'Problem' is that it your order has already a discount (eg: 10%), it would
check if the price without discount is above the required amount.
I don't think it is coherent, let's illustrate:
- First pomotion (auto applied): 1 iPad Mini for free if you buy over $2000
- Second promotion (auto applied): 50% on order
If an user is buying for $2000, he is actually paying $1000 thanks to the 50%
discount.
Should we give him the free iPad?
The current implementation is giving it, which is not convenient IMHO.
Now, we use the amount the user really pay to check if he is elligible.
2. Since new promotions have the same sequence by default, they will be sorted
and applied by their creation order. This will result in inconsistent behavior:
- Promotion 1 : 10% discount
- Promotion 2 : free shipping
- Both promotion are auto applied and need a minimum of $872.73 tax excluded
Let's illustrate with a $873 order:
If the promotions were created in the order above, you won't get both rewards
since the 10% discount will be applied first and will lower the SO total.
The order will then fall below the $872.73 required amount and won't be
eligible for the free shipping.
But if you created the free shipping promotion before the discount one, you
will be eligible for both since the free shipping will be applied first and
won't change the SO total.
To keep the same behavior independently of the promotion creation order, we now
sort by reward_type ('discount' > 'free_shipping' > 'product' to apply
discounts first.
This is better IMHO, since you want to give promotions with a minimum threshold
ONLY if the user really pays that amount. It wouldn't be the case if the total
is checked before the discount is applied.
For the tests on coupon on enterprise, there is a need of a new class to wait
search results to be loaded, or it would click on the /shop product instead of
waiting, resulting in a conccurent update error.
This closes#22263
Aaron Bohy