This fixes unreliable automated tests by making the simulated server date match the dates expected by the tests. It helps prevent false failures in mail and live chat test runs, supporting smoother releases without changing customer-facing behavior.

mock server date is by default in 2019, which
can lead to unwanted behaviors.

Mock the correct date to the server for those hard-coded date tests.

https://github.com/odoo/enterprise/pull/59436

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

This fixes a timing issue in an automated mail test so it no longer fails unpredictably. The change improves confidence in the test results without changing how users experience the mail or discuss features.

Similar to https://github.com/odoo/odoo/pull/158746, the add_members() will call the message_post(). The date should be mocked as well to prevent race condition problems.


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

This fix improves how grid-based views handle scrolling and size changes for rows or columns. It prevents outdated positioning data from affecting the display, reducing visual glitches and making large lists or grids feel more reliable.

When applying a format in an unbreakable inline (without a class), the format was immediately rolled back as we tried to remove split the unbreakable in order to remove its style. task-3768157 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159110 Forward-Port-Of: odoo/odoo#155510

When applying a format in an unbreakable inline (without a class), the format was immediately rolled back as we tried to remove split the unbreakable in order to remove its style.

task-3768157

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

Forward-Port-Of: odoo/odoo#159110
Forward-Port-Of: odoo/odoo#155510

Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id` which does: ```xml <field name="sale_order_id" string="Sale Order" filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]" /> ``` becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes: ```py [ "&", "&", "&", [ "project_id", "!=", false ], [ "display_in_project", "=", true ]

Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id`
which does:
```xml
<field name="sale_order_id" string="Sale Order"
    filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```

becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
	"&",
	"&",
	"&",
	[
		"project_id",
		"!=",
		false
	],
	[
		"display_in_project",
		"=",
		true
	],
	[
		"id",
		"in",
		[
			3341211,
			3526685,
			3692221
		]
	],
	"|",
	[
		"sale_order_id",
		"ilike",
		"SO2023/123456"
	],
	[
		"sale_line_id",
		"ilike",
		"SO2023/123456"
	]
]
```

which makes an "AND" connection between the task ids domain leaf and the sale order name ilike leaves, and all these task ids will come from these SO names, making the AND useless.

In addition to be useless, it downgrades the performance. On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms

On the below screenshot: 
![image](https://github.com/odoo/odoo/assets/5822488/3f19da7a-aafb-43a7-a092-c242a3fd7318)
The first request is with the filter `sale_order_id`
The second request is without the filter `sale_order_id`


opw-3752003

Forward-Port-Of: odoo/odoo#159115
Forward-Port-Of: odoo/odoo#158898

This commit fixes an issue where very long words were overflowing out of the notification. These words will now be split on multiple lines so they stay always readable. task-3820562 | Before | After | |--------|--------| | <img width="424" alt="Screenshot 2024-03-21 at 15 59 31" src="https://github.com/odoo/odoo/assets/110090660/717fd6e8-0d3f-42ba-b9b1-905ba3c76aa1"> | <img width="450" alt="Screenshot 2024-03-21 at 16 00 26" src="https://github.com/odoo/odoo/assets/110090660/f9311e75-3ed

This commit fixes an issue where very long words were overflowing out of the notification. These words will now be split on multiple lines so they stay always readable.

task-3820562

| Before | After |
|--------|--------|
| <img width="424" alt="Screenshot 2024-03-21 at 15 59 31" src="https://github.com/odoo/odoo/assets/110090660/717fd6e8-0d3f-42ba-b9b1-905ba3c76aa1"> | <img width="450" alt="Screenshot 2024-03-21 at 16 00 26" src="https://github.com/odoo/odoo/assets/110090660/f9311e75-3edc-4be8-955a-b7ff3c5fd431"> | 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#158604

This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted. This commit also adapts the background color of the sidebar to make it more consistent with other modules. We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode. task-3814

This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted.

This commit also adapts the background color of the sidebar to make it more consistent with other modules.

We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode.

task-3814508

| Before | After |
|--------|--------|
| <img width="1728" alt="Screenshot 2024-03-22 at 08 32 26" src="https://github.com/odoo/odoo/assets/110090660/85c0d0bf-19af-4a19-aa1b-cf990a6147d8"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 34 08" src="https://github.com/odoo/odoo/assets/110090660/dfe7198a-c011-4ead-bf6f-cfba50db93a9"> |
| <img width="1726" alt="Screenshot 2024-03-22 at 08 32 42" src="https://github.com/odoo/odoo/assets/110090660/ed5914c2-bf1c-44ee-baa6-58fb5f537d9a"> | <img width="1725" alt="Screenshot 2024-03-22 at 08 34 19" src="https://github.com/odoo/odoo/assets/110090660/fb80a723-d1d0-4d44-aded-d603385cce70"> |
| <img width="1714" alt="Screenshot 2024-03-22 at 08 59 52" src="https://github.com/odoo/odoo/assets/110090660/98c543a0-05dd-4b71-b5bf-9d702f513fb4"> | <img width="1715" alt="Screenshot 2024-03-22 at 08 57 41" src="https://github.com/odoo/odoo/assets/110090660/4005b050-4a2a-4137-b6c0-47ecbdbe89a7"> | 
| <img width="1726" alt="Screenshot 2024-03-22 at 08 33 08" src="https://github.com/odoo/odoo/assets/110090660/fde063f8-48f5-4ae2-a5c1-b1973d94f0b3"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 33 59" src="https://github.com/odoo/odoo/assets/110090660/b5875104-7d6f-4a36-8303-0cf7c14c113d"> | 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#158822
Forward-Port-Of: odoo/odoo#158019

…ail_account: fix Send & Print only Clean the implementation + missing peppol, ubl and snailmail. Forward-Port-Of: odoo/odoo#157977

…ail_account: fix Send & Print only

Clean the implementation + missing peppol, ubl and snailmail.

Forward-Port-Of: odoo/odoo#157977

this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test `test_valuation_with_backorder` Forward-Port-Of: odoo/odoo#159248

this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test
`test_valuation_with_backorder`

Forward-Port-Of: odoo/odoo#159248

In the beginning of 2024, the default tax of 20% in Estonia was changed by 22% (with the 20% still supported as a legacy) [1]. With that change, the tax report was also updated so the line previously containing the taxable amount at 20% now contains the taxable amount at 22%. However, the formula computing the tax amount itself was not updated to reflect this change and was still computing the tax by multiplying the taxable amount by 0.2. This fix corrects the tax computation in the report

In the beginning of 2024, the default tax of 20% in Estonia was changed by 22% (with the 20% still supported as a legacy) [1]. With that change, the tax report was also updated so the line previously containing the taxable amount at 20% now contains the taxable amount at 22%.

However, the formula computing the tax amount itself was not updated to reflect this change and was still computing the tax by multiplying the taxable amount by 0.2.

This fix corrects the tax computation in the report.

[1] ec25405367eaeca6bdd1f54e2a09fe6b93b8a4b6

[opw-3815147](https://www.odoo.com/web#id=3815147&cids=1&model=project.task&view_type=form)

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

Forward-Port-Of: odoo/odoo#159154

Forward-Port-Of: odoo/odoo#159262

Forward-Port-Of: odoo/odoo#159262

Before this commit, attempting to invoice an order paid by cash in a new session, with cash rounding enabled only for cash payments in the PoS config, would result in an unbalanced entries error. opw-3813932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158781

Before this commit, attempting to invoice an order paid by cash in a new session, with cash rounding enabled only for cash payments in the PoS config, would result in an unbalanced entries error.

opw-3813932

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

Forward-Port-Of: odoo/odoo#158781

Prior to this commit, the rounding setting could be modified while a session was open. This could potentially cause accounting discrepancies and lead to unbalanced account moves. opw-3677480 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158625 Forward-Port-Of: odoo/odoo#157447

Prior to this commit, the rounding setting could be modified while a session was open. This could potentially cause accounting discrepancies and lead to unbalanced account moves.

opw-3677480

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

Forward-Port-Of: odoo/odoo#158625
Forward-Port-Of: odoo/odoo#157447

Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed. This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found. Now, the view button hook will use the dialog close function put in the environment by the dialog service. Forward-Port-Of: odoo/odoo#159121

Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed.

This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found.

Now, the view button hook will use the dialog close function put in the environment by the dialog service.

Forward-Port-Of: odoo/odoo#159121

Previously, being idle in POS restaurant could cause an error. This was due to setSelectedCategory being set to 0 without a category selected. Also, clicking a selected category with a parent led to an error. This commit fixes these issues. opw-3824557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159314

Previously, being idle in POS restaurant could cause an error. This was due to setSelectedCategory being set to 0 without a category selected. Also, clicking a selected category with a parent led to an error. This commit fixes these issues.

opw-3824557

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

Forward-Port-Of: odoo/odoo#159314

Steps to reproduce: - Install **planning** app. - Go to **planning** app, and convert the view to **List**. - Group by **Resource** -for example-. - Notice how the Allocated Time column values are mis-aligned with the header label. Investigation: - in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8 - In the `getGroupNameCellColSpan` method: -

Steps to reproduce:
- Install **planning** app.
- Go to **planning** app, and convert the view to **List**.
- Group by **Resource** -for example-.
- Notice how the Allocated Time column values are mis-aligned with the header label.

Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
	- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
	- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
	- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.

The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
	- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
	- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
	- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
	- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
	- both firstAggregateIndex` = `lastAggregateIndex` = -1
	- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1`
	- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.

opw-3764616

Forward-Port-Of: odoo/odoo#156647

Steps to reproduce: - - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: - The purchase order line of the PO associated with the created alternative does not compute the taxes. Expected behavior: - The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives. Cause of the issue: - When creating a PO manually, the taxes

Steps to reproduce:
-
- Create a request for quotation for a product with set vendor Taxes
- Create an alternative purchase order from that RFQ with Copy Product

Current Behavior:
-
The purchase order line of the PO associated with the created alternative does not compute the taxes.

Expected behavior:
-
The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives.

Cause of the issue:
-
When creating a PO manually, the taxes of each purchase order line are computed when the product is set during the call of the `onchange_product_id` onchange method:
https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221 https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061 By contrast, PO created from the `action_create_alternative` generate each `purchase.order.line` using `Command.create`. Therefore these lines will not trigger the onchange method and their taxes will not be computed.

Fix:
-
To KISS, we compute the taxes of each line just after the creation of the record using the `_compute_tax_id` method.

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

Forward-Port-Of: odoo/odoo#155060

Steps to reproduce: ------------------- - install calendar, project and documents; - create an activity for a task (project.task) with meeting type; - change attendee to the meeting; - save; Issue: ------ The activity is not linked to the right task. Cause: ------ When we create a `calendar.event`, when the event is at a future date, we send an email to the attendees. This email must include an attachment corresponding to the ICS file. Depending on the `no_document` context key,

Steps to reproduce:
-------------------
- install calendar, project and documents;
- create an activity for a task (project.task) with meeting type;
- change attendee to the meeting;
- save;

Issue:
------
The activity is not linked to the right task.

Cause:
------
When we create a `calendar.event`, when the event is at a future date, we send an email to the attendees.
This email must include an attachment corresponding to the ICS file. Depending on the `no_document` context key, we may or may not create a document.

When we create the document, we have a value for the `activity_ids` field (one2many) which is the ORM command for linking the newly created document.

This will result in the document id being written to the `res_id` field of the `mail.activity` record.
Unfortunately, the activity contains a `res_model` which is not `documents.document`. The result is that the activity is linked to a `res_id` which is not that of the model previously set for it (i.e. `project.task`).

Solution:
---------
Add context key `no_document` when creating an attachment for ICS files.

opw-3746857

Forward-Port-Of: odoo/odoo#155873

When the user creates a new ribbon without a background color, a traceback will appear. Steps to reproduce the error: - Install "website_sale" - Go to Website > eCommerce > Products - Pick a product > Sales > Create a new ribbon without a background color - Save & Close Traceback: ``` TypeError: argument of type 'bool' is not iterable File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in _serve_db return self._t

When the user creates a new ribbon without a background color,
a traceback will appear.

Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close

Traceback:
```
TypeError: argument of type 'bool' is not iterable
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1824, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 74, in web_save
    self = self.create(vals)
  File "<decorator-gen-471>", line 2, in create
  File "odoo/api.py", line 420, in _model_create_multi
    return create(self, [arg])
  File "addons/website_sale/models/product_ribbon.py", line 24, in create
    if 'bg_color' in vals and not '!important' in vals['bg_color']:
```

https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24 Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.

sentry-5077714703

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

Forward-Port-Of: odoo/odoo#158561

Before this PR: 1. When an empty heading from H4 to H6 is the only element in the editable area, the backspace key doesn't turn it into paragraphs. 2. When the cursor is at the start of a heading element with text content, and the user hits the backspace key, the element gets converted into a paragraph. After this PR: All heading elements are removed on backspace if they're empty. task-3456815 Forward-Port-Of: odoo/odoo#132778

Before this PR:

1. When an empty heading from  H4 to H6 is the only element in the editable 
     area, the backspace key doesn't turn it into paragraphs.
2. When the cursor is at the start of a heading element with text content, and the 
    user hits the backspace key, the element gets converted into a paragraph.

After this PR:

All heading elements are removed on backspace if they're empty.

task-3456815

Forward-Port-Of: odoo/odoo#132778

### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`). To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them. ### Adjust hatched events for planning Prior to this commit, the "hatched" event style in Planning was

### Move common scss into web
Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module.
This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`).

To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them.

### Adjust hatched events for planning
Prior to this commit, the "hatched" event style in Planning wasn't displayed in Day and Week views.
This commit adjusts the css selector to fix this issue.

---
task-3617329
Part of task-3575827

---
| Before | After |
|--------|--------|
| ![Capture d’écran 2024-02-22 à 08 30 37](https://github.com/odoo/odoo/assets/80679690/a6a33398-522e-471c-ab75-884f72c214cc) | ![Capture d’écran 2024-02-22 à 08 43 32](https://github.com/odoo/odoo/assets/80679690/e6c07aac-8273-4772-a759-64c03ee125e5) |
| ![Capture d’écran 2024-02-22 à 08 31 10](https://github.com/odoo/odoo/assets/80679690/0ac54c01-a39b-45dd-afeb-5bcc29c912ae) | ![Capture d’écran 2024-02-22 à 08 44 50](https://github.com/odoo/odoo/assets/80679690/d0a69d3f-e68f-4c7f-97d1-e33c14c6f8bd) | 

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-03-25 à 11 00 46](https://github.com/odoo/odoo/assets/80679690/d866eadf-5c04-451c-a98e-4af7789f6d08) | ![Capture d’écran 2024-03-25 à 11 01 06](https://github.com/odoo/odoo/assets/80679690/216ddadb-8e02-4522-a7dc-cf3f6f71069e) |


---

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

Forward-Port-Of: odoo/odoo#154964

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them. Example (formatted): ```sql SELECT "mrp_routing_workcenter".id FROM "mrp_routing_workcenter" LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id" ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id" WHERE "mrp_rou

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.

Example (formatted):
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE ("mrp_bom"."company_id" in (1))
                   )
              )
           OR ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE "mrp_bom"."company_id" IS NULL
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```

If we use the single term version the generated query has only one sub-query:
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE (("mrp_bom"."company_id" in (1))
                        OR  ("mrp_bom"."company_id" IS NULL))
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.

Also, the `company_id` field is required on some models, so the "= False" comparison is useless.

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#159210
Forward-Port-Of: odoo/odoo#157861

Steps to reproduce ================== - Create a new Invoice => The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)` Cause of the issue ================== In 17, the display_name is computed for the tab title https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342 opw-3794671 Forward-Port-Of: odoo/odoo#159301

Steps to reproduce
==================

- Create a new Invoice

=> The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)`

Cause of the issue
==================

In 17, the display_name is computed for the tab title

https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342

opw-3794671

Forward-Port-Of: odoo/odoo#159301

Example of steps: - Open any record with a chatter - Log a note - Edit it - Try to save Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button. opw-3784145 Forward-Port-Of: odoo/odoo#159346 Forward-Port-Of: odoo/odoo#159092

Example of steps:
- Open any record with a chatter
- Log a note
- Edit it
- Try to save

Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button

This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button.

opw-3784145

Forward-Port-Of: odoo/odoo#159346
Forward-Port-Of: odoo/odoo#159092

If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, the test will fail because the wizard takes today as the date at creation. We just add a freeze_time (for this test only, as the other tests in the class don't have the issue). Linked to runbot error 60478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157981

If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, 
the test will fail because the wizard takes today as the date at creation.
We just add a freeze_time (for this test only, as the other tests in the class don't have the issue).

Linked to runbot error 60478





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

Forward-Port-Of: odoo/odoo#157981

Our certificate for aeat seems to not be valid anymore. We don't have a replacement currently. The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), where the certificate is still accepted. We remove this test that fail every day. Linked to Runbot error 25907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157278

Our certificate for aeat seems to not be valid anymore. 
We don't have a replacement currently.
The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), 
where the certificate is still accepted.

We remove this test that fail every day.

Linked to Runbot error 25907




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

Forward-Port-Of: odoo/odoo#157278

In the Point of Sale app, some terms were not translatable by our translators on Transifex. In this commit we make sure that the missing terms are either made translatable or exported in the related .pot file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158730 Forward-Port-Of: odoo/odoo#156929

In the Point of Sale app, some terms were not translatable by our translators on Transifex. In this commit we make sure that the missing terms are either made translatable or exported in the related .pot file.

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

Forward-Port-Of: odoo/odoo#158730
Forward-Port-Of: odoo/odoo#156929

Steps to reproduce: ------------------- - be in a UTC+08:00 (or more) timezone - go to Time Off dashboard - click on a day (to request a leave) Issue: ------ Default request dates are on 2 days instead of 1. Cause: ------ Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone. Consequently, these datetimes can be set over several days. In the backend, we will use

Steps to reproduce:
-------------------
- be in a UTC+08:00 (or more) timezone
- go to Time Off dashboard
- click on a day (to request a leave)

Issue:
------
Default request dates are on 2 days instead of 1.

Cause:
------
Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone.
Consequently, these datetimes can be set over several days. In the backend, we will use these datetimes and take only the day (because the `request_date_from/to` fields are of type date).

Solution:
---------
Put the values back into the client's timezone before they are truncated.

opw-3789265

Forward-Port-Of: odoo/odoo#159288
Forward-Port-Of: odoo/odoo#158042

### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, Notice how both **City** and **District** select boxes are visible and empty! Both should only be visible when the selected Country

### Steps to reproduce:
- Install **l10n_pe_website_sale** module.
- Switch to **PE Company**.
- While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**.
- Go to **Website** > **Shop**, Switch to the new website and add a product to the cart.
- Checkout the cart.
- In the address section, Notice how both **City** and **District** select boxes are visible and empty! Both should only be visible when the selected Country is Peru (PE)

### Investigation:
- 9f957eff4060c8680d73d608a176c0646d9aeb9b moved the method `_onChangeCountry` to another file and hence override of it wasn't in effect

opw-3793838

Forward-Port-Of: odoo/odoo#159311

In order to be able to copy the courses that have the visibility set to 'member'/'Course attendees' we need to be able to copy the enroll of the course, since this visibility requires that we have enroll set to invite and If we are unable to copy it will always be open which is the default opw-3749209 Forward-Port-Of: odoo/odoo#155843

In order to be able to copy the courses that have the visibility set to 'member'/'Course attendees' we need to be able to copy the enroll of the course, since this visibility requires that we have enroll set to invite and If we are unable to copy it will always be open which is the default

opw-3749209

Forward-Port-Of: odoo/odoo#155843

Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend. This is because RTL adaptations were defined in the backend bundle. This PR moves the RTL adaptations to be used wherever `oi` icons can be defined. task-3794966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159150 Forward-Port-Of: odoo/odoo#157214

Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend.
This is because RTL adaptations were defined in the backend bundle.

This PR moves the RTL adaptations to be used wherever `oi` icons can be defined.

task-3794966

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

Forward-Port-Of: odoo/odoo#159150
Forward-Port-Of: odoo/odoo#157214

opw-3709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159286 Forward-Port-Of: odoo/odoo#157836

opw-3709064

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

Forward-Port-Of: odoo/odoo#159286
Forward-Port-Of: odoo/odoo#157836

Current behavior: When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned Steps to reproduce: - Setup an ePos printer for the PoS - Activate QRCode on receipt option - Start a PoS session on an iOS device - Add some product to the order and validate it - On the receipt screen click on the print button - Try to scan the QR Code on the ticket (it's probably too small) Note: If you don't have an iOS device you can use browserstack and

Current behavior:
When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned

Steps to reproduce:
- Setup an ePos printer for the PoS
- Activate QRCode on receipt option
- Start a PoS session on an iOS device
- Add some product to the order and validate it
- On the receipt screen click on the print button
- Try to scan the QR Code on the ticket (it's probably too small)

Note:
If you don't have an iOS device you can use browserstack and use ngrok to expose your local server to the internet and connect to it on browserstack. You can do the same process to expose the printer so that you will be able to print from browserstack.

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

Forward-Port-Of: odoo/odoo#159185
Forward-Port-Of: odoo/odoo#157423

This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't... Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below). Steps to reproduce: - open website - go into edit mode - actually edit the page - add a snippet to the page - click on the "Dis

This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't...

Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below).

Steps to reproduce:
- open website
- go into edit mode
- actually edit the page
- add a snippet to the page
- click on the "Discard" button and move very fast out of it => the error `el.matches is not a function` is "sometimes" raised (if you got the right timing)

References:
- https://w3c.github.io/uievents/#event-type-mouseenter
- https://bugzilla.mozilla.org/show_bug.cgi?id=185889
- https://bugzilla.mozilla.org/show_bug.cgi?id=42717
- https://bugzilla.mozilla.org/show_bug.cgi?id=103055



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

Forward-Port-Of: odoo/odoo#158810

* Enable Peppol * Create a partner with: - Name: Test Peppol - Country: Belgium - Email: test-peppol@customer.example.com - Electronic Invoice Format: BIS Billing 3.0 - Peppol e-address: (blank) - Peppol endpoint: (blank) * Create an invoice and confirm it * Click on "Send & Print" => In the wizard that open, there are no option to select either Peppol nor any EDI format. Once `account_peppol` is installed, if a partner has an EDI format set but no Peppol in

* Enable Peppol

* Create a partner with:
  - Name: Test Peppol
  - Country: Belgium
  - Email: test-peppol@customer.example.com
  - Electronic Invoice Format: BIS Billing 3.0
  - Peppol e-address: (blank)
  - Peppol endpoint: (blank)

* Create an invoice and confirm it
* Click on "Send & Print"

=> In the wizard that open, there are no option to select either
   Peppol nor any EDI format.

  Once `account_peppol` is installed, if a partner has an EDI format
set but no Peppol information (EAS & Endpoint) we should still allow the user to send/print the invoice with partner's EDI format.

  Also the Peppol warning was never shown on the wizard as the option
was always disabled when the partner was not fully configured, so now the option is shown but unchecked by default if partner is not ready.

OPW-3698904

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

Forward-Port-Of: odoo/odoo#158582

Currently, on sale orders, you cannot access parent's fiscal positions from a branch. ### Steps to reproduce * install `sale_management` * set up a company hierarchy. Let's say we have two companies P and C such that C is a branch of P. * let's say that P has a fiscal position F * switch to company C * attempt to set fiscal position F on a sale order You will see that F does not appear on the list. opw-3773335 Forward-Port-Of: odoo/odoo#159042

Currently, on sale orders, you cannot access parent's fiscal positions from a branch.

### Steps to reproduce

* install `sale_management`
* set up a company hierarchy. Let's say we have two companies P and C such that C is a branch of P.
* let's say that P has a fiscal position F
* switch to company C
* attempt to set fiscal position F on a sale order

You will see that F does not appear on the list.

opw-3773335

Forward-Port-Of: odoo/odoo#159042

This update corrects a bug that caused the system to repeatedly recalculate expense product costs, which could lead to inaccurate accounting records. The fix ensures that expense costs are only calculated when necessary, improving data accuracy and reducing potential discrepancies in financial reporting. This change improves the reliability of expense tracking.

Fix a bug introduced by 67901a4429c69fbba96c32af5d8f58aff54f0be5

When an expense is submitted and for the steps after, there is no need
to recompute the product_cost as it may be confusing
or generate discrepancies with the account move by changing the totals.

task-3580004

Forward-Port-Of: odoo/odoo#155277
Forward-Port-Of: odoo/odoo#141400

The attendance Gantt planning view is being adjusted to work with the new attendance-contract connection. This helps ensure employee attendance scheduling and contract-related information stay aligned as the HR attendance tools evolve.

The debug popover in financial reports now only appears when there is useful information to show. This avoids oversized, empty popovers and makes report screens cleaner for users reviewing financial data.

The size of the popover for report lines without formulas was too big for its content. This commit fixes this issue by shrinking the popover to fit its content.

Steps to reproduce issue:
1. Open the Executive Summary report: **Reporting → Executive Summary**
2. Click on the debug icon in the last column of the 'Cash' header line

task: 3775658

This update fixes an internal Point of Sale compatibility issue affecting localization features. It helps ensure invoice and preparation display behavior continues to work correctly after recent technical restrictions.

PoS variable was use in models in localization modules. This is not allowed anymore.

This commit fixes the issue.

**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number. **Expected behavior:** The VAT Unit number will be written to the PDF if a report is being generated with that option selected. **Steps to reproduce:** 1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it 2. In th

**Current behavior:**
If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number.

**Expected behavior:**
The VAT Unit number will be written to the PDF if a report is being generated with that option selected.

**Steps to reproduce:**
1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it

2. In the Accounting app, go to the `Tax Report` view under the `Reporting` menu

3. Select the newly created VAT Unit for the `Tax Unit` option in the top right of the view

4. Select the `PDF` button to print the report, observe that the `VAT:` label on the report shows the Company VAT number instead of the Unit's

**Cause of the issue:**
The XML template for the PDF report is only setup to show the company VAT number here.

**Fix:**
Use the selection for the `Tax Unit:` configuration to inform the VAT number that is shown on the final report.

opw-3747319

Forward-Port-Of: odoo/enterprise#59240
Forward-Port-Of: odoo/enterprise#58361

This improvement removes unnecessary attribute parameters from product URLs when a product has no variants. Previously, product URLs would display with empty attribute markers (e.g., /shop/product-1#attr=), which looked unprofessional. Now, simple products without variants will have clean, straightforward URLs (e.g., /shop/product-1), improving the appearance and user experience of your eCommerce store.

Description of the issue/feature this PR addresses:
Avoid ugly URL if no variant on your eCommerce.

Current behavior before PR:
Product URL are like /shop/product-1#attr=

Desired behavior after PR is merged:
Product URL are like /shop/product-1 when no attributes



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

This update removes an old URL pattern from the forum system that was causing unnecessary redirects. Previously, forum links using the /question/ path would redirect to the standard forum post URL, creating redundant steps. This fix eliminates that outdated redirect path, making the forum navigation cleaner and more efficient.

Avoid redirect to forum/<name>/question/<post> that will rediret in all case to /forum/<name>/<post>.

A recent update to the survey test suite caused an issue where multiple surveys were being created with duplicate session codes. This fix ensures that each survey receives a unique session code as required by the system. This resolves test failures and maintains data integrity in the survey module.

In c983f8a5 we updated the `test_survey_invite_action` test to create surveys in batch instead of one by one.
This is problematic because `session_code` (given by utility method) must be unique for all surveys.

Task-3829536

The certificate used for testing Spanish tax authority (AEAT) integration has expired and is no longer valid. This fix removes the failing daily test while maintaining test coverage through alternative regional certificates (Bizkaia and Gipuzkoa) that use the same technical flow. This prevents continuous test failures without impacting the actual functionality.

Our certificate for aeat seems to not be valid anymore. 
We don't have a replacement currently.
The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), 
where the certificate is still accepted.

We remove this test that fail every day.

Linked to Runbot error 25907




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

Forward-Port-Of: odoo/odoo#157278

This update fixes a test failure in the accounting module that occurred when a test ran across midnight. The test was creating a financial transaction at 23:59:59 and then running a wizard the next day at 00:00:01, causing the wizard to use the wrong date. The fix ensures the test runs consistently regardless of what time of day it executes.

If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, 
the test will fail because the wizard takes today as the date at creation.
We just add a freeze_time (for this test only, as the other tests in the class don't have the issue).

Linked to runbot error 60478





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

Forward-Port-Of: odoo/odoo#157981