This commit is the continuity of a42c27f9 that fixed some bugs.
One of the bug was that a discount was only applied on price without taxes.
E.G: A $100 product with 20% excluded tax would cost $120 but a 50% discount
would give the user only $50 discount and not $60 as expected.
User would lose $10 discount.
With these fixes, the discount line would correctly be set to $60 but since the
discount line would not have tax, the merchant would lose the discount amount
on the tax, in this case 50% of $20.
This commit will improve this case by adding a tax on a discount line.
Thus, since a global discount can be applied to multiple products having
different taxes or even multiple taxes on the same product, a discount line
should be split for every product taxes the discount applies on.
Obviously, this is a big behavior change, even if the discount is now finally
correct: the discount is applied on the total price and the merchant does not
lose any taxes.
To make it more clear, the discount lines description will mention on which
taxes it is applied.
There won't be any changes in the e-commerce since we will group the discount
lines so it will appear as before even if there are multiple lines. This is
only possible because we don't show taxes on line on the e-commerce.
This commit also fixes more complex flows/use cases.
Note: Fixes & flows will be illustrated with a SO but the behavior is the
same with a cart on front-end.
== Fixes ==
===========================================================================
The biggest flow that needed to be fixed is when a promotion program give a
reward on the next order.
Let's illustrate with a promotion program giving a free `product_B` on next
order (so it will generate a coupon) if the SO meets the requirements.
The requirements are: buy a `product_A` and buy for at least $600.
(This program needs a code: 'free_b_on_next')
1. If the SO has a `product_A` and over $600, applying the promotion code
`free_b_on_next` will error saying that `product_B` is not in the cart.
This error should not appear, since the `product_B` is the reward for
the next sale order that will use the generated coupon.
Anyway, if you add `product_B` and apply the promotion code `free_b_on_next`
to generate the coupon to check the rest of the flow. It will generate the
coupon and send email to the customer.
2. Every time you will apply the promotion code `free_b_on_next`, it will
regenerate a new coupon and resend a new email to the client.
Then, create a second SO, add 2 `product_B` and try to apply the generated
coupon from the first SO.
3. It will error saying that the $600 requirement is not met.
It should not since the requirement was only required to generate the
coupon on the first SO. User has now a coupon to enjoy a free `product_B`
and should not buy $600.
Anyway, let's add some products to meet the 600$ requirement to check the rest
of the flow.
4. It will now error saying that `product_A` is not in the cart.
As bug 3., it should not since this requirement was also required to
generate the coupon on the first SO.
Anyway, let's add `product_A` to meet the requirement to check the rest of the
flow.
5. Updating the promotions will remove the reward and you won't be able to
reapply the coupon since it was `used`.
This bug was even more critical in front-end since any action on the cart
will recompute the coupons and automatically delete the reward after adding
it. The customer never saw the reward on his cart.
This bug is related to 3. and 4. Indeed, when recomputing coupons, it will
remove programs that are not applicable anymore. The code wrongly think it is
the case with this coupon since we don't have $600 or a `product_A`.
`_remove_invalid_reward_lines` should treat coupon coming from a promotion
program set on `next_order` differently and not filter on requirements.
===========================================================================
6. (extension of 2.) Every time an user would meet the requirements of a
promotion program generating a coupon for a next order, it would generate a
coupon and send an email.
E.g: If buy 2 iPads get 1 for free on next order. If user add and remove iPad
for some reason, every time he has 2 iPads in his cart it will receive
an email with a new coupon.
6'. When applying a promotion code that will reward next order, it will not be
set in the SO `code_promo_program_id` (I did not change that behavior since
it could make sense to be able to apply another coupon that will give -20%
on current order).
This will allow applying multiple promotion rewarding a next order and/or a
promotion rewarding current order. (Which would not be possible if was
stored on `code_promo_program_id` since you can only apply one code on an
order)
But this cause a bug: since the promotion program is not stored on the order,
every time you will apply the coupon it will generate a new coupon and send
an email.
So if you work on a draft sale order and do some tests, it will send many
emails to customer..
7. Having multiple global discounts (on the whole SO) was forbidden: you can't
apply a coupon promotion or a program promotion if there is already a global
coupon discount or a global promotion discount with code. But still you could
apply a global discount if there were a global promotion discount automatically
applied (without a code).
8. On the generate coupon wizard, if you select `Number of Selected Customers`,
by default it is set to 'Match all records (X records)'.
But when you click on generate, it won't generate anything even if visually
it selected every partner by default.
This is because the domain default value is an empty string. Thus, the domain
widget is selecting everything but once it is sent back to the server, since
it's an empty string it won't get through the `if` condition.
It was even weirder when you add something to the domain and remove it, you
then visually come back to where you were at the beginning but the domain got
changed from '' to '[]' so in this case it will generate the coupon for every
partner.
== More like improvements ==
1. `action_cancel` and `action_confirm` would handle correctly the states of the
applied and generated coupons (valid, consumed, expired..).
But `action_draft` would not handle the states at all.
2. The generated coupon on a SO are now sent by email only when the SO is validated.
This is part of the fix n°2 on coupon being generated multiple times and sent by
email multiple times.
The coupon sent by email was not usable anyway since it would error saying the
SO that generated the coupon was not validated.
3. Discount line limited to a max amount (set in the program) will mention on
the line description that the discount is limited.
This will avoid cases where you don't understand why 50% discount of $2000
SO shows $40.
4. If you archive a program and there is still some SO containing this program's
reward line, these line will be 'floating free' and will never be updated or
removed. Indeed, the `_remove_invalid_reward_lines` is basically checking
which programs could be applied on the order and which one are applied on the
order. If a program is applied on the order but is not supposed to, his
reward line will be removed.
Of course, since the program got archived, it won't get retrieve and the line
will never get removed. Even if the case of a free iPad: if you buy an iPad
and you removed the paid iPad from the SO. The free iPad will remain forever.
Note: We can't remove these discount line directly when archiving a program
because there might be quotations that we don't want to modify since it
is waiting for customer confirmation.
Improved behavior:
- Archiving a program archives its related reward product but unarchiving
the program does not unarchived the product.
task-1866977
opw-1832967
opw-1857843
Closes#2224
Comes with https://github.com/odoo/odoo/pull/24971
Previous commit fixed some bugs on `sale_coupon` (#2224).
This commit add some tests to be sure these bugs are fixed and won't appear
again.
task-1866977
Related to #2224
This commit is the continuity of a42c27f9 that fixed some bugs.
One of the bug was that a discount was only applied on price without taxes.
E.G: A $100 product with 20% excluded tax would cost $120 but a 50% discount
would give the user only $50 discount and not $60 as expected.
User would lose $10 discount.
With these fixes, the discount line would correctly be set to $60 but since the
discount line would not have tax, the merchant would lose the discount amount
on the tax, in this case 50% of $20.
This commit will improve this case by adding a tax on a discount line.
Thus, since a global discount can be applied to multiple products having
different taxes or even multiple taxes on the same product, a discount line
should be split for every product taxes the discount applies on.
Obviously, this is a big behavior change, even if the discount is now finally
correct: the discount is applied on the total price and the merchant does not
lose any taxes.
To make it more clear, the discount lines description will mention on which
taxes it is applied.
There won't be any changes in the e-commerce since we will group the discount
lines so it will appear as before even if there are multiple lines. This is
only possible because we don't show taxes on line on the e-commerce.
This commit also fixes more complex flows/use cases.
Note: Fixes & flows will be illustrated with a SO but the behavior is the
same with a cart on front-end.
== Fixes ==
===========================================================================
The biggest flow that needed to be fixed is when a promotion program give a
reward on the next order.
Let's illustrate with a promotion program giving a free `product_B` on next
order (so it will generate a coupon) if the SO meets the requirements.
The requirements are: buy a `product_A` and buy for at least $600.
(This program needs a code: 'free_b_on_next')
1. If the SO has a `product_A` and over $600, applying the promotion code
`free_b_on_next` will error saying that `product_B` is not in the cart.
This error should not appear, since the `product_B` is the reward for
the next sale order that will use the generated coupon.
Anyway, if you add `product_B` and apply the promotion code `free_b_on_next`
to generate the coupon to check the rest of the flow. It will generate the
coupon and send email to the customer.
2. Every time you will apply the promotion code `free_b_on_next`, it will
regenerate a new coupon and resend a new email to the client.
Then, create a second SO, add 2 `product_B` and try to apply the generated
coupon from the first SO.
3. It will error saying that the $600 requirement is not met.
It should not since the requirement was only required to generate the
coupon on the first SO. User has now a coupon to enjoy a free `product_B`
and should not buy $600.
Anyway, let's add some products to meet the 600$ requirement to check the rest
of the flow.
4. It will now error saying that `product_A` is not in the cart.
As bug 3., it should not since this requirement was also required to
generate the coupon on the first SO.
Anyway, let's add `product_A` to meet the requirement to check the rest of the
flow.
5. Updating the promotions will remove the reward and you won't be able to
reapply the coupon since it was `used`.
This bug was even more critical in front-end since any action on the cart
will recompute the coupons and automatically delete the reward after adding
it. The customer never saw the reward on his cart.
This bug is related to 3. and 4. Indeed, when recomputing coupons, it will
remove programs that are not applicable anymore. The code wrongly think it is
the case with this coupon since we don't have $600 or a `product_A`.
`_remove_invalid_reward_lines` should treat coupon coming from a promotion
program set on `next_order` differently and not filter on requirements.
===========================================================================
6. (extension of 2.) Every time an user would meet the requirements of a
promotion program generating a coupon for a next order, it would generate a
coupon and send an email.
E.g: If buy 2 iPads get 1 for free on next order. If user add and remove iPad
for some reason, every time he has 2 iPads in his cart it will receive
an email with a new coupon.
6'. When applying a promotion code that will reward next order, it will not be
set in the SO `code_promo_program_id` (I did not change that behavior since
it could make sense to be able to apply another coupon that will give -20%
on current order).
This will allow applying multiple promotion rewarding a next order and/or a
promotion rewarding current order. (Which would not be possible if was
stored on `code_promo_program_id` since you can only apply one code on an
order)
But this cause a bug: since the promotion program is not stored on the order,
every time you will apply the coupon it will generate a new coupon and send
an email.
So if you work on a draft sale order and do some tests, it will send many
emails to customer..
7. Having multiple global discounts (on the whole SO) was forbidden: you can't
apply a coupon promotion or a program promotion if there is already a global
coupon discount or a global promotion discount with code. But still you could
apply a global discount if there were a global promotion discount automatically
applied (without a code).
8. On the generate coupon wizard, if you select `Number of Selected Customers`,
by default it is set to 'Match all records (X records)'.
But when you click on generate, it won't generate anything even if visually
it selected every partner by default.
This is because the domain default value is an empty string. Thus, the domain
widget is selecting everything but once it is sent back to the server, since
it's an empty string it won't get through the `if` condition.
It was even weirder when you add something to the domain and remove it, you
then visually come back to where you were at the beginning but the domain got
changed from '' to '[]' so in this case it will generate the coupon for every
partner.
== More like improvements ==
1. `action_cancel` and `action_confirm` would handle correctly the states of the
applied and generated coupons (valid, consumed, expired..).
But `action_draft` would not handle the states at all.
2. The generated coupon on a SO are now sent by email only when the SO is validated.
This is part of the fix n°2 on coupon being generated multiple times and sent by
email multiple times.
The coupon sent by email was not usable anyway since it would error saying the
SO that generated the coupon was not validated.
3. Discount line limited to a max amount (set in the program) will mention on
the line description that the discount is limited.
This will avoid cases where you don't understand why 50% discount of $2000
SO shows $40.
4. If you archive a program and there is still some SO containing this program's
reward line, these line will be 'floating free' and will never be updated or
removed. Indeed, the `_remove_invalid_reward_lines` is basically checking
which programs could be applied on the order and which one are applied on the
order. If a program is applied on the order but is not supposed to, his
reward line will be removed.
Of course, since the program got archived, it won't get retrieve and the line
will never get removed. Even if the case of a free iPad: if you buy an iPad
and you removed the paid iPad from the SO. The free iPad will remain forever.
Note: We can't remove these discount line directly when archiving a program
because there might be quotations that we don't want to modify since it
is waiting for customer confirmation.
Improved behavior:
- Archiving a program archives its related reward product but unarchiving
the program does not unarchived the product.
task-1866977
opw-1832967
opw-1857843
Closes#2224
Comes with https://github.com/odoo/odoo/pull/24971
When introducing the 'employee rate' mode to timesheet
on project, we break the wizard: its goal was to link the
existing timesheets to the SO line in order to invoice them.
(Employee rate commit: b4af54f9c2)
This commit makes the wizard compatible with the employee rate
feature, without breaking invoicing at task rate flow.
Two possible flows, starting with a non billable project:
* project rate: the wizard will create a SO with one SOL,
and will link the task without SOL set to the new one.
The project will also be linked to that SOL.
* employee rate: the user has to fill a map to associate
product and employee. If the same product is set 2 times
with the same price (and so, 2 different employees), only
one SOL will be created on the SO. When submitting, the
project map will be filled and the project will be linked
to the SO. No fallback SOL will be set on project or on
the tasks.
Both use cases will be stopped if a timesheet of the project's
tasks is already linked to a sale line. If not, the timesheets
will be associated to the correct SOL (dependning of the billable
type), and the delivered quantity will be incremented, making
the SO invoicable. The tasks'customer will also be set.
Future work: setting a product per task (which will be a real
'task rate' feature).
Task #1883640
Before this commit, the message was always displayed.
Now we only show into the default homepage the message "Follow all the tooltip"
when there at least 1 tooltip in the current page.
task-1878245
Before this commit, we return an act_url, in this case the breadcrumb is not
build and the user cannot retruen to the settings in one click.
task-1878245
Advanced user can do it from the backend by the way and it is not
obvious to understand the impact to set/unset this option.
Seems like I was the only guy to think that this feature was needed
task-1878245
The report layout "background" has an image background from bottom to
top. When we transform the report in PDF, we have no idea in the
document of how many page, which orientation, width or height it will
take.
Thus to be able to have the background at the bottom of a page when
there is not enough content, we set a min-height for the body content.
This height was 1000px originally and has been decreased to 900px in
41c75ad0c3 because an empty page was possibly added (since the height of
body + header + footer was bigger than page size).
This issue is about getting a blank page when pdf is in landscape.
For example in A4 with 90ppi has a 1052px height in portrait, but 744px
height in landscape so we always get at least two pages with possibly a
blank one.
With this commit we lower it to 620px allowing 124px headers/footers.
opw-1881059
closes#26962
Purpose of this code is to synchronize user and employee timezones. However
if the employee has one and the user none it is better to keep the one
set on the employee to avoid issues.
mrp.workcenters are resources instances. Their resource_type is human by
default while workcenters should be considered as material. This commit
set the resource_type as material by default in case of workcenter
Mrp workcenters have a resource_calendar_id to specifie its working
hours. On the form view, this field is optionnal but is mandatory in the
form view.
This commit set it as required in the view to avoid the classical 'object
with reference * - *' error.
Task : 1876847
- Set a vendor on Product A
- Create a SO with 1 Unit of A, set the Drop Ship route
- Confirm the SO
=> a PO with 1 Unit is created
- Change the oredered quantity to 2
The PO is updated with a total quantity of 3 instead of 2.
Since the removal of procurements, the quantity is computed based on the
stock moves. However, in this case, no stock move has been created since
the PO is not yet confirmed.
In this specific case, we fall back on the PO line quantity. The logic
is similar to `_quantity_in_progress`.
opw-1879118
- added two new actions to the form view debug action list,
both opens list (+ form) views of messages and attachments respectively
for which the domain is restricted to the current record.
task: 1860031
- Added a new button to the chatter that displays the amount of
attachments on the current record and when clicked, all the attachments
attached to the current record
- added mail.FormView (includes), used by the chatter attachment
button to fetch the field value of attachment_count.
- added a computed field "attachment_count" to mail.thread that
contains the amount of attachment attached to the record.
- changed the followers div, it is now sharing a "right side"
area with the attachment button.
task: 1860031
When duplicating a task, we want the copy to have
the same sale order line then the original.
However, we duplicating a project, the tasks are
copied too. But, in that case, we don't want them
to be linked to any sale line, as the copy project
will not be.
This commit fixes that use case, and provides a test.
Task #1883640
The generated SQL constraints name is too long, and so, when raising, it
does not show the defined error message, since Postgresql truncated the
name. thus Odoo can not match the error with the error message.
Task #1883640
Since in sale_timesheet (and elsewhere), the sale line is link to
some document, the user might click on this field to get more
information.
Unfortunately, he will get an odoo-generated form view, as no one
exists for this model.
This commit provides a basics and beautiful view for SOL, available
for all modules.
Task #1882245
Since the recent fixes on multi website, the customization modal
is restored but is a lot slower the first time we use it (around 20sec
to save an option on my machine). This was because when we change an
option, all the others options are sent to the server to be (re-)saved
and, on the first time, the multi-website system has to duplicate them
all to make them website-specific.
Now, we only enable/disable views which are modified by the user.
The write method did not work properly for views anymore as soon as it
was called on a multi-records recordset which contains at least one
view which is not website specific. In that case, it used the cow
system for that view (and thus created a specific copy)... but forgot
to continue the write method for the other views, leading to strange
results.
The code used the xml_id field instead of the key field at some point,
so the modal was not fetching the proper views.
This commit also removes the useless code in there.
Steps to reproduce the bug:
- Create three stockable products P1, P2, P3
- Create a BOM for P1 with P2 and P3 as components
- Create a MO with 5 P1
- Check the availability and plan it
- Go on the WO and process only 3 P1
- Go to the MO and update the quantity to 3
Bug:
From this point, it was impossible to pass the MO to the state= 'done'
With this fix, you can now, click on "Post inventory" and the button
"Mark as Done" will appear.
opw:1874227
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Backport of 611c836a46
Before this commit, extra_info was never considered enabled since it was
checking the original view and not the current website view.
By default disabled, when you enable the view, multiwebsite duplicate this
view to enable it for the current website.
+ fix redirect to kanban adress after editing the billing address instead of
the step 'choose your shipping address'
task-1878245
Romain Derie