Steps to reporduce: - Make two orderlines that are cannot be merged with same product (add a comment, combo, etc ...) - Open the split bill screen - Selecet any of the orderlines and try to unselect it - Impossible to unselect the orderlines with same product but different line Fix: Calculate the line quantity selected based on the linked order line quantity and not the total number of same product in the order. Description of the issue/feature this PR addresses: Current behavior

Steps to reporduce:

- Make two orderlines that are cannot be merged with same product (add a comment, combo, etc ...)
- Open the split bill screen
- Selecet any of the orderlines and try to unselect it
- Impossible to unselect the orderlines with same product but different line

Fix:
Calculate the line quantity selected based on the linked order line quantity and not the total number of same product in the order.

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#209633
Forward-Port-Of: odoo/odoo#208640

The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications. Steps to Reproduce: - Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop`

The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications.

Steps to Reproduce:
- Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop` page
- Navigate to the shop page and scroll to the last product
- Add the last product to the cart
- The pop-up does not appear unless you scroll back up

Issue:
- The add to cart pop-up is not visible when the user is scrolled down on the page

Root cause:
- The CSS class `position-absolute` restricts the pop-up to a specific location in the scrollable content

Fix:
- Replace `position-absolute` with `position-fixed` to keep the pop-up visible regardless of scroll position

opw-4686886
Affected version - 18.0

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

Forward-Port-Of: odoo/odoo#208973

Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson

Steps:
- Create a partner and it's parent partner and set different salesperson on each.
- Login with child partner and add product to cart.
- Go to backend and open related quotation.

Issue:
- Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson.

Cause:
- In eCommerce we gave parent's salesperson first priority then customer's salesperson.

Fix:
- Swap priority to set first customer's salesperson

opw-4757042

Forward-Port-Of: odoo/odoo#210557
Forward-Port-Of: odoo/odoo#209062

Because of commit https://github.com/odoo/odoo/commit/b5ba14bc77a12268e5ce1e2a7aa7e48ba209f876 tours are faster and don't wait much between two steps. Also, when removing or adding a facet in the search view, there is no way to determine that the subsequent reload has been done. The factet is removed or added immediately, the reload happens after. So, before the refactoring of macro.js, we waited a little bit longer, allowing the reload of the view to be done before going to the next s

Because of commit https://github.com/odoo/odoo/commit/b5ba14bc77a12268e5ce1e2a7aa7e48ba209f876
tours are faster and don't wait much between two steps.

Also, when removing or adding a facet in the search view, there is no
way to determine that the subsequent reload has been done.
The factet is removed or added immediately, the reload happens after.

So, before the refactoring of macro.js, we waited a little bit longer, allowing
the reload of the view to be done before going to the next step.

This commit mitigates this by making the dataset of the tour more dterministic in
order to be able to check that in the DOM.

It is possible that the problem occurs in 18.0 as well, so feel free to backport this fix.
runbot-error-162145

Forward-Port-Of: odoo/odoo#210548

Problem: In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like: `setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function. Solution: When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an elemen

Problem:
In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like:
`setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function.

Solution:
When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an element.

Steps to reproduce:
1. Add enough text to make the editable area scrollable.
2. Insert a list (any type).
3. Copy some text and paste it into the last list element. → Even if the selection is in the viewport, it still scrolls
   incorrectly.

opw-4745939

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

Forward-Port-Of: odoo/odoo#207673

Scenario: - add a form with studio - change its action to "Create a Task" - delete the field "Full Name" - send the form with an unknown email Result: an error happens Cause: if the email does not find a user, the code expects the partner_name to always be present, even if it is an optional field. Fix: make the code work without partner_name field. opw-4773357 Forward-Port-Of: odoo/odoo#210160

Scenario:
- add a form with studio
- change its action to "Create a Task"
- delete the field "Full Name"
- send the form with an unknown email

Result: an error happens

Cause: if the email does not find a user, the code expects the
partner_name to always be present, even if it is an optional field.

Fix: make the code work without partner_name field.

opw-4773357

Forward-Port-Of: odoo/odoo#210160

Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order. Steps to reproduce: ------------------- * Create 2 pricelists, A and B, let's say A always adds a 10$ fee * Set both as available in the POS, with A being the default one * On the contact "Simplified invoice parner", set the pricelist A * Open pos * Change pricelist to B * Pay and validat

Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order.

Steps to reproduce:
-------------------
* Create 2 pricelists, A and B, let's say A always adds a 10$ fee
* Set both as available in the POS, with A being the default one
* On the contact "Simplified invoice parner", set the pricelist A
* Open pos
* Change pricelist to B
* Pay and validate order
> Observation: Order is not validated, 10$ left to pay

Why the fix:
------------
Prior to the use of `set_partner`, we used to simply write the partner field of the order when using the simplified invoice partner.

Now we are using `set_partner` which is a generic function that handles everything related to changing partners, such as updating pricelist. https://github.com/odoo/odoo/blob/69057e41fb4cd800d23401ead8ae11bf7cba7c64/addons/point_of_sale/static/src/app/models/pos_order.js#L941-L948

In our example since the default pos pricelist was manually changed it means that the intention was to use this set pricelist.

What we do now in this case is to check if the pricelist was purposefully changed (it differs from the default pricelist), and in this case we want to use this pricelist on the order.

opw-4662248

Forward-Port-Of: odoo/odoo#208880
Forward-Port-Of: odoo/odoo#208624

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts. Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed whe

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We also revert the commits https://github.com/odoo/odoo/commit/818602363a751bf1777b57261e1accafb45e7439 and https://github.com/odoo/odoo/commit/4dfdab2d84f95e657961c2ee6fff8b8bd6b29570 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

Another commit make the domain field pass a new prop allowExpressions to the domain
selector. If that prop is false (default true), the within operator is not proposed for selection for date/datetime fields. This is done to prevent users to introduce expressions in their domains when they are not supported.

Forward-Port-Of: odoo/odoo#210482
Forward-Port-Of: odoo/odoo#208876

Before this commit, the `message sound on receiving new message` was sometimes failing. It occurs because the test uses the `waitFor` web method to wait for the message unread counter to change. However, `waitFor` has a much smaller timeout than `contains` (200ms vs 3s). In this particular scenario, receiving the bus notification, fetching the channel and rendering the chat hub initially can take a little bit more time than 200ms, making the test fail. This commit increases the time out to

Before this commit, the `message sound on receiving new message` was sometimes failing. It occurs because the test uses the `waitFor` web method to wait for the message unread counter to change. However, `waitFor` has a much smaller timeout than `contains` (200ms vs 3s).

In this particular scenario, receiving the bus notification, fetching the channel and rendering the chat hub initially can take a little bit more time than 200ms, making the test fail.

This commit increases the time out to match the `contains` one for this test.

fixes runbot-159866

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#210547

Usecase: - Create a new company without warehouse - Create a purchase.order with a dropship type You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19) 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 guidel

Usecase:
- Create a new company without warehouse
- Create a purchase.order with a dropship type

You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19)

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#194897

**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out will happen at 17:00 if the company's tolerance in the attendance's setting is set at 0. Previously, it would happen at 16:00, resulting in only 7 worked hours for the attendance while the user may expect the attendance's worked hours to match the expected working hours of the schedule. **Solu

**Issue**
For example, in the case of a working schedule from 8:00 to 17:00 with
a 1 hour lunch period, 8 hours of work are expected. By taking the
lunch interval into account, the auto check out will happen at 17:00
if the company's tolerance in the attendance's setting is set at 0.
Previously, it would happen at 16:00, resulting in only 7 worked hours
for the attendance while the user may expect the attendance's worked
hours to match the expected working hours of the schedule.

**Solution**
- include lunch attendances (not taken into account by `duration_hours`)
in the total time that needs to be exceeded before an `hr.attendance` is
automatically checked out.
Note that this solution manages the case where `hr.attendance` are outside
lunch periods (e.g. 8-12 and 13-17, but no attendance between 12-13). Though
in that case, the automatic check out will be delayed by at least 1h.

Note: a change was also made to account for 2 weeks calendars.

opw-4402321

Forward-Port-Of: odoo/odoo#197395

Versions -------- - 17.0+ Steps ----- 1. Create a coupon that grants a discount; 2. add a second reward giving free products; 3. use a product tag to turn it into a multiproduct reward; 4. save program, generate coupons, and copy a code; 5. add the free product tag to two or more products; 6. go to eCommerce; 7. add any product to cart and go to checkout; 8. apply coupon code; 9. claim a reward. Issue ----- - Claiming a free product results in a traceback. - Claiming the dis

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

Steps
-----
1. Create a coupon that grants a discount;
2. add a second reward giving free products;
3. use a product tag to turn it into a multiproduct reward;
4. save program, generate coupons, and copy a code;
5. add the free product tag to two or more products;
6. go to eCommerce;
7. add any product to cart and go to checkout;
8. apply coupon code;
9. claim a reward.

Issue
-----
- Claiming a free product results in a traceback.
- Claiming the discount does not apply the discount.

Cause
-----
Commit db3ffae3ef5a5 modified the reward claiming logic to allow for multiproduct rewards, but overlooked the possibility of the program having multiple rewards, multiproduct being one of them.

It therefore passes all of the coupon's rewards to `_apply_reward`, which only expects a single reward.

This is also a consequence of commit 6525d5fba40c, which moved part of the `claim_reward` logic to `pricelist`, without passing which reward was claimed to `pricelist`.

Solution
--------
Add an optional `reward_id` parameter to `pricelist`, letting it know which reward we intend to claim.

opw-4778945

Forward-Port-Of: odoo/odoo#210214
Forward-Port-Of: odoo/odoo#209610

### Steps to reproduce: - Navigate to Time off app -> Reporting -> By type - Access any leave record - Notice it will open an allocation record form ### Cause: This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns. https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53 https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c7

### Steps to reproduce:
	- Navigate to Time off app -> Reporting -> By type
	- Access any leave record
	- Notice it will open an allocation record form

### Cause:
This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns.

https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53

https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L68-L70

in those two sub-queries the order of fetching the allocation_id and leave_id is not the same which cause that leave_id column will be always null and every id value -either leave_id or allocation_id- will be stored in allocation_id column.

### Fix:
Since columns' order matter when fetching sub-queries we unified the order in both queries.

opw-4723952

Forward-Port-Of: odoo/odoo#208773

*: account,l10n_hu_edi,l10n_sa,purchase,purchase_stock,sale When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. The `:` character is inconsistent with other reports, but will be removed in the master forward port to avoid overriding stable translation. task-4730464 Enterprise PR: https://github.com/odoo/enterprise/pull/84281 | Issue solved in this PR | |--------| | ![ima

*: account,l10n_hu_edi,l10n_sa,purchase,purchase_stock,sale

When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read.

The `:` character is inconsistent with other reports, but will be removed in the master forward port to avoid overriding stable translation.

task-4730464

Enterprise PR: https://github.com/odoo/enterprise/pull/84281

| Issue solved in this PR |
|--------|
| ![image](https://github.com/user-attachments/assets/002cfb48-53cf-4a16-a60e-3810ac05a466)| 


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

Forward-Port-Of: odoo/odoo#207725

Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the l

Some services or applications (Outlook, Google Messages) display
previews of links sent through messages or email. In an effort to
strengten user privacy, these services fetch the previews from their
own servers rather than from the user's device.

Since these services' requests had not been added to the list of
known bot identifiers, they generate parasite "clicks" which don't
match their user.

This commit adds identifiers for the Outlook and Google Messages
service requests to the list of known bot IDs, thereby preventing the
parasite clicks from generating.

task-3672491

Forward-Port-Of: odoo/odoo#200148
Forward-Port-Of: odoo/odoo#167799

- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. - Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account. - Make a purchase using the `"demo"` payment method with the new partner. The ge

- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment.
- Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account.
- Make a purchase using the `"demo"` payment method with the new partner.

The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable).

The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner.

After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard)  avoiding any discrepancy.

opw-4669927

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#209318
Forward-Port-Of: odoo/odoo#204489

This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673

This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French.

task-4717339




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

Forward-Port-Of: odoo/odoo#208673

### Approach: - When the entire content of a single table cell is selected, store the `ev.clientX` value once the cell content is fully selected. Afterward, if the mouse moves in the direction of the selection (left or right) by a sensitivity threshold of 5px, the entire cell is selected. ### Steps to Reproduce: - Create a table (e.g., using /table). - Add multiple blocks with varying text lengths inside a cell. - Try selecting all the content inside the cell using the mouse. - Obser

### Approach:

- When the entire content of a single table cell is selected, store the `ev.clientX` value once the cell content is fully selected. Afterward, if the mouse moves in the direction of the selection (left or right) by a sensitivity threshold of 5px, the entire cell is selected.

### Steps to Reproduce:

- Create a table (e.g., using /table).
- Add multiple blocks with varying text lengths inside a cell.
- Try selecting all the content inside the cell using the mouse.
- Observe that the cell does not get selected.

### Description of the issue/feature this PR addresses:

- The cell does not get selected when all content inside the cell is selected with the mouse.

### Desired behavior after PR is merged:

- The entire cell is selected when the content is fully selected.

task-4743170

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

Forward-Port-Of: odoo/odoo#210677
Forward-Port-Of: odoo/odoo#207028

Steps to Reproduce: 1. Go to the To-do module. 2. Create a link. 3. Select the entire content using Ctrl + A. 4. Change the font style from 'Normal' to another (e.g., 'Header 1'). 5. A traceback is thrown, although the link’s font style is changed. Description of the issue/feature this PR addresses: - The issue was caused by the presence of a `FEFF` (zero-width no-break space) character inside the selected text. This caused a conflict during selection restoration after the font styl

Steps to Reproduce:

1. Go to the To-do module.
2. Create a link.
3. Select the entire content using Ctrl + A.
4. Change the font style from 'Normal' to another (e.g., 'Header 1').
5. A traceback is thrown, although the link’s font style is changed.

Description of the issue/feature this PR addresses:

- The issue was caused by the presence of a `FEFF` (zero-width no-break space) character inside the selected text. This caused a conflict during selection restoration after the font style change. The clean handler was being triggered after the font change attempt, which led to an invalid cursor state.

 Current behavior before PR:
- A Traceback occurred when changing the font style of a selected link text.

Desired behavior after PR is merged:

- The clean handler is now explicitly called before the font change tries to restore the cursor, avoiding the invalid range or selection error.

task-4743390

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

Forward-Port-Of: odoo/odoo#207202

To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes => Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't). This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we d

To reproduce the issue:

1) Create a Belgian company, with CoA installed
2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes

=> Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't).

This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we declare them in in the csv. When creating those 0% taxes, the transition account had to be mapped. Since Belgium does not have any cash basis taxe, we relied on the first account used in the tax repartition of the tax to convert. However, those 0% taxes obviously had no account there (since they're 0% anyway), so we ended up not entering this condition https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L970 and mapping the transition account to None. Because of that, we did not create any equivalent for that account, for any of the taxes using it.

This commit solves that by sorting the tax templates to first treat those with accounts in their tax repartition.

We also fix here the fact that instantiating such cash basis taxes did not enable the "cash basis" setting on the company ; which didn't make any sense, and caused an error message when trying to edit the settings afterwards.

Forward-Port-Of: odoo/odoo#210070

This change uses python set subtraction over recordset \_\_sub\_\_ on calendar.attendees. Before this change, when doing a large calendar synchronization such as setting up Google Calendar, notified_attendees could be a large recordset of calendar.attendees. When performing a recordset subtraction in _notify_attendees, this uses \_\_sub\_\_ and browse multiple times. Synchronizing around 5000 events took about ~350 seconds (on my own calendar data), where _notify_attendees took ~313 seconds (

This change uses python set subtraction over recordset \_\_sub\_\_ on calendar.attendees.

Before this change, when doing a large calendar synchronization such as setting up Google Calendar, notified_attendees could be a large recordset of calendar.attendees. When performing a recordset subtraction in _notify_attendees, this uses \_\_sub\_\_ and browse multiple times. Synchronizing around 5000 events took about ~350 seconds (on my own calendar data), where _notify_attendees took ~313 seconds (83%). 

After this change, _notify_attendees takes ~1 second operating on the same synchronization.

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

Forward-Port-Of: odoo/odoo#210271

Versions -------- - saas-18.1 - saas-18.2 Steps ----- 1. Install `website_event_sale` without demo data; 2. run `test_sold_out_event_cart_reminder`. Issue ----- Test fails. Cause ----- The test uses `base.partner_admin` to test sending an email. As of saas-18.1, this partner record no longer gets created with an email value when demo data is disabled. This causes the test to fail unexpectedly, as it cannot send an email without email address. Solution -------- Ensure the

Versions
--------
- saas-18.1
- saas-18.2

Steps
-----
1. Install `website_event_sale` without demo data;
2. run `test_sold_out_event_cart_reminder`.

Issue
-----
Test fails.

Cause
-----
The test uses `base.partner_admin` to test sending an email.
As of saas-18.1, this partner record no longer gets created with an email value when demo data is disabled. This causes the test to fail unexpectedly, as it cannot send an email without email address.

Solution
--------
Ensure the record has an `email` value.

runbot-223119

Forward-Port-Of: odoo/odoo#210416

This commit ensures that the group `uom.group_uom` is correctly applied on the test user, so that the tour doesn't fail on the step looking for "Packagings" field on the product view which happened in some [single module tests](https://runbot.odoo.com/odoo/runbot.build.error/222678). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210536

This commit ensures that the group `uom.group_uom` is correctly applied on the test user, so that the tour doesn't fail on the step looking for "Packagings" field on the product view which happened in some [single module tests](https://runbot.odoo.com/odoo/runbot.build.error/222678).

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

Forward-Port-Of: odoo/odoo#210536

In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...). This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values. However, before this commit, the logic

In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...).

This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values.

However, before this commit, the logic was incorrect. It didn't take into the account the fact that date and time formats are language dependant. It assumed that the required space for the english formats (+ a bit of security margin) was enough. Moreover, the fonts may obviously has an impact as well (some fonts requiring more space to display the same text, than others).

As a consequence, on macos and, for instance, in deutch, date and datetime values were trimmed, which is something we never want: dates and datetimes should always be fully displayed. This is even worse in some languages, like arabic, basque or chinese, in which the month and/or the day of week is displayed in letters.

This commit comes with a more elaborated solution to deal with those variable date and time formats + fonts. We no longer hardcode the ideal widths of dates and datetimes, but instead compute it (lazily) once, by rendering values in the DOM.

This commit also improves the datetime and daterange cases with option "show_time" set to false: in that case, we know those fields only require the width of date values, not datetime, so we can shrink their columns.

X-original-commit: c7421ddb2bfea433d56faa928c36b5ef7d5aef4c

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#210739

This commit addresses a typo in the archive and restore buttons within the kanban menu, introduced in this commit https://github.com/odoo/odoo/commit/d220bb4c872d3660d15373d15565c846e3a35d9f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193209

This commit addresses a typo in the archive and restore buttons within the kanban menu, introduced in this commit https://github.com/odoo/odoo/commit/d220bb4c872d3660d15373d15565c846e3a35d9f

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

Forward-Port-Of: odoo/odoo#193209

Before this commit it was not possible to start the Ace editor (via its owl wrapper codeEditor) with an initial cursor position. After this commit it is now possible to do just that. This comes handy in the use case where: - one makes modification on the edited resource. - saves the result. This could mean that the codeEditor must be restarted from scratch (reloading all the data) - functionally stay on the saved resource at the right position. Note that the onChange call back now recei

Before this commit it was not possible to start the Ace editor (via its owl wrapper codeEditor) with an initial cursor position.

After this commit it is now possible to do just that. This comes handy in the use case where:
- one makes modification on the edited resource.
- saves the result. This could mean that the codeEditor must be restarted from scratch (reloading all the data)
- functionally stay on the saved resource at the right position.

Note that the onChange call back now received the position at which the edition *started*.

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#210659
Forward-Port-Of: odoo/odoo#208803

…ve and reload sources In the reportEditor edit the xml, modify a view's arch and save. Before this commit, the cursor position in the XMLEditor was reset to [0,0]. After this commit, we restore the position of the cursor according to the start position of the last edition. opw-4745895 Forward-Port-Of: odoo/enterprise#85919 Forward-Port-Of: odoo/enterprise#84877

…ve and reload sources

In the reportEditor edit the xml, modify a view's arch and save. Before this commit, the cursor position in the XMLEditor was reset to [0,0].

After this commit, we restore the position of the cursor according to the start position of the last edition.

opw-4745895

Forward-Port-Of: odoo/enterprise#85919
Forward-Port-Of: odoo/enterprise#84877

**Steps to reproduce:** 1. Install `website_sale_renting` 2. Go to the website editor. 3. Drag and drop the `rental search` snippet. 4. Set the rental timing to `hour` **Issue:** - The default date was always set to the next day with the current time, making it impossible for users to select the current date without adjusting the time manually. https://github.com/odoo/enterprise/blob/a6ec35e94bdd4f721982c32716f716948f74c875/website_sale_renting/static/src/js/website_sale_renting_dateran

**Steps to reproduce:**
1. Install `website_sale_renting`
2. Go to the website editor.
3. Drag and drop the `rental search` snippet.
4. Set the rental timing to `hour`

**Issue:**
- The default date was always set to the next day with the current time, making it impossible for users to select the current date without adjusting the time manually.
https://github.com/odoo/enterprise/blob/a6ec35e94bdd4f721982c32716f716948f74c875/website_sale_renting/static/src/js/website_sale_renting_daterangepicker.js#L147-L148

**Solution:**
- Updated the logic for hourly rentals to set the default date next day with
  adding one hour from the current time,  to allow customers to select the
  current date.
- For daily rentals, the logic remains unchanged and defaults to the next day.

opw-4770823

Forward-Port-Of: odoo/enterprise#85613

The tours fails because when we edit the value in the input field of customer it clicks on the field and then fills out the value and then a change event is propagated and text based autocomplete results are shown (and m2o fields with partner autocomplete wizard are a tad bit slower), after that tours moves to next step and the new result dropdown menu is not loaded and it gets its reference from older menu which got closed in between and tries click it and no change is reflected but the n

The tours fails because when we edit the value in the input field of customer it
clicks on the field and then fills out the value and then a change event is
propagated and text based autocomplete results are shown (and m2o fields with
partner autocomplete wizard are a tad bit slower), after that tours moves to
next step and the new result dropdown menu is not loaded and it gets its
reference from older menu which got closed in between and tries click it and no
change is reflected but the new menu is not closed and tour continues to
industry_fsm_report where we create a worksheet from a many2one field using
create and edit so we click on the m2o input and wait for options but as partner
field loaded dropdown is loaded it clicks on click and edit trying to create a
new partner and opening thus fails the tour.

Fix:

- After entering the text to instantly load the dropdown by clicking on it and
give time for loading of menu.

task-4800194

Forward-Port-Of: odoo/enterprise#85905
Forward-Port-Of: odoo/enterprise#85622

The xsd changed. Now the rounding needs to be to 2 decimals everywhere. The official xsd does not mention it, but the field submit_more must appear on the xml. Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it. opw-4789154 Forward-Port-Of: odoo/enterprise#85593 Forward-Port-Of: odoo/enterprise#85464

The xsd changed. Now the rounding needs to be to 2 decimals everywhere. 
The official xsd does not mention it, but the field submit_more must appear on the xml.

Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it.

opw-4789154

Forward-Port-Of: odoo/enterprise#85593
Forward-Port-Of: odoo/enterprise#85464

Follow the changes made in community commit. When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. Note: there are leftovers `:` characters that will be removed on master forwardport to avoid wiping existing translation on stable (not worth) task-4730464 Community PR: https://github.com/odoo/odoo/pull/207725 Forward-Port-Of: odoo/enterprise#84281

Follow the changes made in community commit.

When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read.

Note: there are leftovers `:` characters that  will be removed on master
forwardport to avoid wiping existing translation on stable (not worth)


task-4730464

Community PR: https://github.com/odoo/odoo/pull/207725

Forward-Port-Of: odoo/enterprise#84281

This reverts the recent commits https://github.com/odoo/enterprise/commit/fbfa23e4ee86666e6c0903206ff49a918f281c67 and https://github.com/odoo/enterprise/commit/a4351c97e1017b918d940db2618704aa25e84aff. Indeed, for security reasons, it is preferable to avoid calling safe_eval whenever possible. Note that in https://github.com/odoo/odoo/pull/210576 a new mechanism is introduced in order to block the creation of expressions in domain fields where we only want domains with literals because they ar

This reverts the recent commits https://github.com/odoo/enterprise/commit/fbfa23e4ee86666e6c0903206ff49a918f281c67 and https://github.com/odoo/enterprise/commit/a4351c97e1017b918d940db2618704aa25e84aff. Indeed, for security reasons, it is preferable to avoid calling safe_eval whenever possible.
Note that in https://github.com/odoo/odoo/pull/210576 a new mechanism is introduced in order to block the creation of expressions in domain fields where we only want domains with literals because they are evaluated with literal_eval.

Forward-Port-Of: odoo/enterprise#85620
Forward-Port-Of: odoo/enterprise#85298

## Version: 17.0+ ## Issue: Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal. ## Steps to reproduce: Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer: - Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date; - Confirm and create regular invoice: - Set `Invoice Date` to the s

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

Forward-Port-Of: odoo/enterprise#85813
Forward-Port-Of: odoo/enterprise#85314