* website, website_sale, website_sale_delivery
While we used BS3, we used our own responsive classes for text
alignment (text-right-sm, text-center-not-lg, ...). Now BS4 classes can
be used to achieve the same behavior so there is no point in declaring
our own ones anymore.
Also, as the breakpoint names changed (lg -> xl, md -> lg, ...), the
current code was not working as intended anymore anyway.
* website_sale
Bootstrap chose not to implement this feature, probably relying on their
grid system (see https://github.com/twbs/bootstrap/issues/21943).
We have a case where a responsive size of 0px is needed though: applied
on a table, this forces the table to its contents' natural width. So
this commit implements the behavior and adds the size of 0 to replace
the non-responsive class 'o_table_column_fit'.
The depreciation was hardcoded as starting the first of January.
If a user changed the configuration to set a different value than 31/12 it had
no impact.
In saas-11.3, this was improved to allow to configure the behaviour at 805f3a610
opw-1878927
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
Since d5b687a an error is logged when trying to insert duplicates in
ir_model_data. An error appears when installing this module because of
the duplicate.
As this module is not yet tested, this error flew under the radar.
Note: a new test that installs l10n* is developped
- Set a product with real-time valuation
- Create a SO, select the Drop Ship route
- Validate the SO, the PO, and receive the picking
=> an accounting entry is created
- Return the picking
The reversed accounting entry is not created.
This is because the return of a drop ship picking is not recognized as
some kind of dropshipping.
opw-1879117
get the product_name thanks to a function, so that we can reuse it somewhere else (account_predictive_account)
Part of PR #26876.
Part of task #1882329
It has been argued that a regression took place because of e2efec8e54
Before that commit, everything was reconciled together
After, only payments and orders with a partner set were
While that commit improved performances (there are much less move lines to reconcile),
it introduced an inconvenience business wise because of the noise created
by the unreconciled lines
This commit proposes to cut the pear in half by introducing an ir parameter
to choose between the two options
OPW 1883594
closes#26971
Show the source and destination location in the detailed operation view
if the multilocation is active. Also hide locations if only the delivery
package settings.
Issue: 1882695
On a website page, click on promote and add the keyword "DS1517"
before this commit, the javascript froze
after this commit, it doesn't freeze
OPW 1880341
closes#26771
The group_by was passed from context from the action spawning a new view.
This meant that it could give a group_by a field that was not defined on the
destination view, causing a js traceback.
opw 1884035
Modal generic:
- Fix footer overflowing buttons by pushing them to a new line.
Page manager:
- Add an SEO column to easily see which pages have incomplete SEO.
- Add an edit SEO column to navigate to the SEO modal on said page.
- Hide "edit in backend" column as debug.
- Generally improve the whole view by adding appropriate titles on icons, etc.
SEO modal:
- Improve general style.
- Add description length alert.
- Restructure the keyword table/suggestions.
- Reset page meta to their initial value on Discard.
- Various small usability improvements.
PR: #26897
task-1850579
Rumor say that that 1x/100... the variant is not selected and that the tour crash.
So we are not sure that it will avoid that, but it will be not worse.
I will keep my fingers crossed for that.
Before this commit, it was not possible to open systray menus in mobile.
This is due to popper.js that is wrongly dynamically positioning the
dropdown menu.
This commit fixes the issue by disabling dynamic positioning by popper.js
for the systray menus, so that it uses ou custom styles for dropdown menu.
Closes#26434
Revision on https://github.com/odoo/odoo/commit/d91ec258e6a31153beb9eb16cfe8f916546b7688
The commit above reverts a commit when we were using bootstrap 3.
The equivalent of XS in bootstrap 3 is SM in bootstrap 4.
So the correct revert with bootstrap 4 is to use SM.
Also removing useless style on 'o_mobile_menu_opened'.
Closes#26434
Tests from hr_recruitments work luckily until now.
Because module maintenance imply base.group_user for group_equipment_manager
<record id="group_equipment_manager" model="res.groups">
...
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
and module hr_maintenante imply group_equipment_manager for hr_user
<record id="hr.group_hr_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('maintenance.group_equipment_manager'))]"/>
</record>
After this commit launch test on hr_recruitment module without any other module will works.
Design-theme repo show this error because repo tests hr_recruitment without installing maintenance
(Repo install website_* modules -> website_hr_recruitment -> hr_recruitment -> hr)
Backport-of d5b0f99943 to have runbot design-theme green
- When checking if a recipient has already received a mass mailing, the
record model for the recipient was not checked.
Which leads to false positives.
When choosing a project template on a service (product
config), and then archive it, the generated project
on sale line confirmation will be inactive too.
This commit forces the generated project to be active.
Task #1884328
Using a pricelist set as `without_discount` will show a strikethrough price on
reward line (discount and free product).
This is happening because the program reward line (discount_line_product_id) is
created with the default 1$ price as this price is not usefull when computing
coupons. Only the line price is checked.
Now, we create a reward line with a -1 000 000$ price to prevent this UI
behavior.
Step to reproduce:
- Activate pricelist (Sales>Config>Settings>Pricelist formulas)
- Activate discounts in Sales Configuration (Manual discount on order lines)
- Set pricelist to 'Show public price & discount to the customer'
- Add a discount in your cart
- There in a strikethrough price of $1 above the discount line price
task-1878245
A discount on products with different taxes will result in as many discount
lines as there is different taxes.
Before this commit, removing one of these lines would not do anything else.
Then, recomputing the coupon would regenerate/add back this line.
On e-commerce, it means you would never be able to remove the program by
deleting its reward lines if there are multiple taxes (and so multiple lines)
since it would `recompute_coupon_lines` right away, adding it back directly.
Now, this commit will ensure that removing one of these lines will also remove
the other ones coming from this program on other taxes.
It means removing a regular product will remove it's reward line that will also
now remove the other program's discount line on other taxes and ultimately will
remove the program from the SO since all the program reward lines got removed.
(It won't affect auto applied program since it will be regenerated afterward)
task-1866977
Related to #2224
A discount on products with different taxes will result in as many discount
lines as there is different taxes.
This commit will merge all these lines in a single one on the front-end (cart)
to not change the behavior/display for the end user. This will be purely visual
as it does not affect SO lines.
task-1866977
Related to #2224
A discount on products with different taxes will result in as many discount
lines as there is different taxes.
Before this commit, removing one of these lines would not do anything else.
Then, recomputing the coupon would regenerate/add back this line.
On e-commerce, it means you would never be able to remove the program by
deleting its reward lines if there are multiple taxes (and so multiple lines)
since it would `recompute_coupon_lines` right away, adding it back directly.
Now, this commit will ensure that removing one of these lines will also remove
the other ones coming from this program on other taxes.
It means removing a regular product will remove it's reward line that will also
now remove the other program's discount line on other taxes and ultimately will
remove the program from the SO since all the program reward lines got removed.
(It won't affect auto applied program since it will be regenerated afterward)
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
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
qsm-odoo