Issue: ------------ The width of the "Upload and Set" button did not adjust based on its text, resulting in the text being clipped. Fix: ----------- This commit enables automatic width adjustment for the "Upload and Set" button to ensure both the button and its text are fully visible on the same line. Steps to Reproduce (mobile view): ------------------ - Install the project module - Open the task Kanban view - Click on Set Cover Image task-3761269 Forward-P

Issue:
------------

  The width of the "Upload and Set" button did not adjust based on its text, resulting in the text being 
   clipped.

Fix:
-----------
 This commit enables automatic width adjustment for the "Upload and Set" button to ensure
 both the button and its text are fully visible on the same line.

Steps to Reproduce (mobile view):
------------------
   - Install the project module
   - Open the task Kanban view
  - Click on Set Cover Image

task-3761269

Forward-Port-Of: odoo/odoo#160913

The live chat uses a shadow DOM to preserve its styles. However, shopify hides empty block. Since the live chat root only contains the shadow DOM, it is considered empty which leads to the chat bubble not being displayed. This commit fixes the issue by explicitly setting the "display" style on the live chat root. opw-4768389 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CL

The live chat uses a shadow DOM to preserve its styles. However, shopify hides empty block. Since the live chat root only contains the shadow DOM, it is considered empty which leads to the chat bubble not being displayed. This commit fixes the issue by explicitly setting the "display" style on the live chat root.

opw-4768389

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#209592

This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209571

This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed.

task-4791376

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#209571

In the case where the name of the related partner is changed, the bank account holder name will not reflect the changes, we add here a dependency on partner_id.name Forward-Port-Of: odoo/odoo#209436

In the case where the name of the related partner is changed, the bank account holder name will not reflect the changes, we add here a dependency on partner_id.name

Forward-Port-Of: odoo/odoo#209436

Versions -------- - 16.0+ Steps ----- 1. Have multiple companies; 2. create an eWallet program available to all companies; 3. set its email template to "Gift Card: Gift Card Information"; 4. create & confirm an order containing the "Top-up eWallet" product; 5. switch to a different company; 6. create an new order for the same client. Issue ----- Access Error Cause ----- Commit eaa6f6c5a415f added the `_get_mail_author` method to ensure gift card emails always have an author

Versions
--------
- 16.0+

Steps
-----
1. Have multiple companies;
2. create an eWallet program available to all companies;
3. set its email template to "Gift Card: Gift Card Information";
4. create & confirm an order containing the "Top-up eWallet" product;
5. switch to a different company;
6. create an new order for the same client.

Issue
-----
Access Error

Cause
-----
Commit eaa6f6c5a415f added the `_get_mail_author` method to ensure gift card emails always have an author. When using the gift card template for eWallets, this can cause an issue for 2 reasons:

1. When creating an eWallet via the top-up product, its `order_id` is the order that created the eWallet. This order may belong to a different company than the one it is getting used for.
2. The `send_reward_coupon_mail` method fetches its coupons by calling `_get_reward_coupons` on the order. This returns any applied eWallets, therefore calling `_send_creation_communication` whenever the eWallet gets used. The reason it returns applied eWallets as a "reward coupon" is because `_update_programs_and_rewards` creates `sale.order.coupon.points` records with 0 points when applying a `loyalty.card`, which then get assumed to be a reward, despite not granting any points: https://github.com/odoo/odoo/blob/9e22dbb7b6fb581d2f11bf0ec48b230047686050/addons/sale_loyalty/models/sale_order.py#L499-L504

Solution
--------
1. In the `_get_mail_author` yield to `super` if the order's company isn't in `self.env.companies`.
2. In the `_get_points_programs` and `_get_reward_coupons` methods, filter out `coupon_point_ids` that don't grant any points. (Alternatively, we could avoid creating `sale.order.coupon.points` records with 0 points, but this might be risky for stable.)


opw-4731588

Forward-Port-Of: odoo/odoo#209515
Forward-Port-Of: odoo/odoo#208637

Before this commit, when a product had multiple taxes, the X report was displaying a wrong total base tax amount. This was due to the fact that the tax amount was being calculated as the sum of all the tax bases. This was wrong as the amount tax excluded of the product sold was included twice in this sum. opw-4727830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208642

Before this commit, when a product had multiple taxes, the X report was displaying a wrong total base tax amount. This was due to the fact that the tax amount was being calculated as the sum of all the tax bases. This was wrong as the amount tax excluded of the product sold was included twice in this sum.

opw-4727830

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#208642

**Current behavior before PR:** - Clicking the reset color button did not remove the applied gradient color. **Desired behavior after PR is merged:** - The reset color button now correctly removes the gradient color when clicked. task: 4735054 Forward-Port-Of: odoo/odoo#206778

**Current behavior before PR:**

- Clicking the reset color button did not remove the applied gradient color.

**Desired behavior after PR is merged:**

- The reset color button now correctly removes the gradient color when clicked.

task: 4735054

Forward-Port-Of: odoo/odoo#206778

Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discoun

Versions
--------
- 17.0+

Steps
-----
1. Set up a Next Order Coupon program;
2. add Free Shipping as a reward;
3. create a coupon for current user with enough points to claim reward;
4. add a product to your cart;
5. go to check out;
6. claim Free Shipping.

Issue
-----
Free Shipping is still displayed as claimable

Cause
-----
The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order.

For discounts & free products, this isn't an issue, as claiming them will use as many points as possible, meaning there's no points left to claim more, but free shipping can only be claimed once per order.

Solution
--------
Filter out rewards that have already been claimed.

opw-4784359

Forward-Port-Of: odoo/odoo#209508

When the invoice can't be sent via Peppol, we are adding a footer in the Invoice email. We sent this regardless of the partner Peppol status. This PR narrows the cases when we sent the footer. Another issue is that "we recommend" Odoo, we are speaking in the name of our user. A better phrasing will make things fairer, such as this footer keeps its informative value, without being too pushy. task-4782004 Forward-Port-Of: odoo/odoo#209432

When the invoice can't be sent via Peppol, we are adding a footer in the Invoice email. We sent this regardless of the partner Peppol status. This PR narrows the cases when we sent the footer.

Another issue is that "we recommend" Odoo, we are speaking in the name of our user. A better phrasing will make things fairer, such as this footer keeps its informative value, without being too pushy.

task-4782004

Forward-Port-Of: odoo/odoo#209432

With Jordan Company setup: - Set dummy values on the Jordan electronic invoicing settings - Enable USD, set a rate and currency precision to 5 - Set the Product Price decimal accuracy to 5 - Make an invoice in USD adding a line as follows: - Price 0.13793 - Qty 9 - Discount 100% - Tax: 16% - Confirm - Send & Print, activate e-invoice (JoFotara (Jordan EDI)) Issue will raise: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template Template: accou

With Jordan Company setup:
- Set dummy values on the Jordan electronic invoicing settings
- Enable USD, set a rate and currency precision to 5
- Set the Product Price decimal accuracy to 5
- Make an invoice in USD adding a line as follows:
  - Price 0.13793
  - Qty 9
  - Discount 100%
  - Tax: 16%
- Confirm
- Send & Print, activate e-invoice (JoFotara (Jordan EDI))

Issue will raise:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
Template: account_edi_ubl_cii.ubl_20_MonetaryTotalType
Path: /t/t/cbc:TaxInclusiveAmount
Node: <ns0:TaxInclusiveAmount xmlns:ns0="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" t-att-currencyID="vals[\'currency\'].name" t-out="format_float(vals.get(\'tax_inclusive_amount\'), vals.get(\'currency_dp\'))"/>
```

This occurs because on high currency precision we may work with numbers that are represented in scientific notation (-2e-09) that when converted to string may keep the literal form unless using a specific format

opw-4739342

Forward-Port-Of: odoo/odoo#209624

Scenario: add a popup on a website page with enough text above the button so the button is not visible on the page without scrolling. Display the popup. Result: the popup is opened scrolled at the bottom (depends on if we are logged in or not), this usually works in incognito. Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the first tabbable element in the modal, but if that element is not in the view, the browser automatically scrolls to it. So there is this side effect tha

Scenario: add a popup on a website page with enough text above the
button so the button is not visible on the page without scrolling.

Display the popup.

Result: the popup is opened scrolled at the bottom (depends on if we are
logged in or not), this usually works in incognito.

Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the
first tabbable element in the modal, but if that element is not in the
view, the browser automatically scrolls to it. So there is this side
effect that happen if the first tabbable element is hidden by the
scroll.

Fix: after we focus to the element, we reset the scrollTop to 0 to
ensure we stay at the top of the popup.

opw-4647172

Forward-Port-Of: odoo/odoo#209512
Forward-Port-Of: odoo/odoo#206318

**Issue:** Some tests are failing when "account" module is not installed because they use "account.group_account_invoice". **Solution:** Skip these tests if "account" module is not installed. runbot-163123 runbot-163124 runbot-163125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209719 Forward-Port-Of: odoo/odoo#209661

**Issue:**
Some tests are failing when "account" module is not installed because they use "account.group_account_invoice".

**Solution:**
Skip these tests if "account" module is not installed.

runbot-163123
runbot-163124
runbot-163125




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#209719
Forward-Port-Of: odoo/odoo#209661

Before this commit this test `test_04_portal_sale_signature_without_name_tour` was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just `sale_management`). With this commit this test works as expected in both of them. A solution was to use `alt_trigger` instead of "," to separate two css selector, as it was not working as expected inside tour triggers runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/161357/runbot

Before this commit this test `test_04_portal_sale_signature_without_name_tour` was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just `sale_management`).

With this commit this test works as expected in both of them.

A solution was to use `alt_trigger` instead of "," to separate two css selector, as it was not working as expected inside tour triggers

runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/161357/runbot.build.error.content/runbot.build.error.content/162311

Forward-Port-Of: odoo/odoo#208824

Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported. Steps to reproduce: - open CRM - switch to the graph view - Check the "cumulative" checkbox - Group by create date: month - Filter on March and April (the last 2 months in the filter) - insert in spreadsheet - reload => the chart data changed. It now includes historical data Task-4792009 Description of the issue/feature this PR addresses: Current behavior before PR: Desired be

Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported.

Steps to reproduce:
- open CRM
- switch to the graph view
- Check the "cumulative" checkbox
- Group by create date: month
- Filter on March and April (the last 2 months in the filter)
- insert in spreadsheet
- reload

=> the chart data changed. It now includes historical data

Task-4792009

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#209637

In case of a multi-company enabled database, it was possible to assign a journal to an online account of a different company, which didn't make much sense. Forward-Port-Of: odoo/enterprise#84909 Forward-Port-Of: odoo/enterprise#82080

In case of a multi-company enabled database, it was possible to assign a journal to an online account of a different company, which didn't make much sense.

Forward-Port-Of: odoo/enterprise#84909
Forward-Port-Of: odoo/enterprise#82080

This is a fix-of-fix. #### Explanation of the first fix Before the fix abd6cc063e86ed6adc5559ff7cd09d605bbbecb9 the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used. However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those c

This is a fix-of-fix.

#### Explanation of the first fix
Before the fix abd6cc063e86ed6adc5559ff7cd09d605bbbecb9 the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used.

However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice.

To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice.

However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future).

#### The fix-of-fix (this PR)

To solve both those issues, here is what we do:
- now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change).
- if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too.

task-none

Forward-Port-Of: odoo/enterprise#85162
Forward-Port-Of: odoo/enterprise#85026