Steps to Reproduce:

- write on ir.model.data to modify noupdate.
- _lookup_xmlids still returns the old noupdate value.

Example:
In [1]: imd = self.env['ir.model.data']

In [2]: xml_id = self.env['ir.model.data'].search([], limit=1)

In [3]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[3]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]

In [4]: xml_id.write({'noupdate': not xml_id.noupdate})
Out[4]: True

In [5]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[5]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]

In [6]: imd.flush_model()

In [7]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[7]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, True, 149)]

Issue:

- _lookup_xmlids is returning values from ir.model.data executing an SQL query w/o flushing.

Fix:

- Add flushing in _lookup_xmlids.

Forward-Port-Of: odoo/odoo#262791

The search order on account move line depends on date, move name and id.
This search result order can be non deterministic because,
when creating account move line from stock valuation, it depends on the order from a set, but sets are unordered.

**Step to reproduce**
Run [test_subcontracting_purchase_bill](https://github.com/odoo/odoo/blob/13b2781978b0edad0df0800404276919b767e32b/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L268) in:
Single app, community, with demo data.

**Observation**
* The search:
When doing the search since we didn't specify any order,
the search from account.move.line will ordered by:
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L23
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L1664
Since, for the components the date and move name are the same it will only depend on the aml ids:

* `Account.move.line` creation:
When it validate the receipt (`button_validate`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L296

It will mark as done the picking (`_action_done`) and the productions (`button_mark_done`) linked to this picking.
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/stock/models/stock_picking.py#L1429
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting/models/stock_picking.py#L49
Modify the inventory accordingly (`_post_inventory`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp/models/mrp_production.py#L2231
while inside of `_post_inventory`, it will process all the production moves, for this it will divided them in set to process them by batch:
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1904-L1911

From this set, it will create the `account.move.line`:
It retrieve the actual stock move with the browse, and call `_action_done`, from where the stock valuation layer will create the `account.move.line`.
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1913
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/stock_account/models/stock_move.py#L187
The issue arise because a set read order is non deterministic.

runbot-939794

Forward-Port-Of: odoo/odoo#279396

Currently, an error occurs when the user removes the payslip period.

**Steps to Reproduce:**
 - Install the `hr_payroll` module.
 - Go to `Employees` and create an `employee`, or use an existing one.
 - Make sure the `employee's version` has a `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips` and create a payslip.
 - Select that `employee` on the payslip, then remove the `payslip start date`.

`TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'`

After the [recent commit], which computes the version from the payslip period without allowing it to 
be overridden, when the user selects an employee whose version has a contract start date, it 
checks whether the version overlaps with the payslip period [1]. However, since the payslip 
dates have not yet been set, it raises an error.

This commit ensures that the check for the version overlapping with the payslip period is 
skipped if the payslip does not have both a start and end date. It also makes the method 
depend on date_to, because if the user changes the payslip end date, it should recheck 
whether the version overlaps with the payslip period.

[recent commit]: https://github.com/odoo/enterprise/commit/569ce2af32477d410b79e98ca72729385042619b

[1]- https://github.com/odoo/enterprise/blob/8a66d7beabe6f9b28000ef12725f3a9937d5d1ee/hr_payroll/models/hr_payslip.py#L1716-L1725

sentry-7632216317

Forward-Port-Of: odoo/enterprise#126515

Problem:
When applying color on a selection that spans across partially selected inline elements (e.g. `<p><b>a[b</b>c]d</p>`), container elements whose contents are not fully selected (such as `<b>`) were included in `targetedNodes`. This caused improper color formatting/nesting on partially selected elements.

Cause:
In `ColorPlugin._applyColor()`, `targetedNodes` were filtered by checking `isNodeEditable(node)` and `nodeName !== "T"`, but did not check whether the contents of `node` were fully selected (`areNodeContentsFullySelected(node)`). As a result, partially selected ancestor elements were included in `targetedNodes`.

Solution:
Filter `targetedNodes` in `_applyColor()` using
`this.dependencies.selection.areNodeContentsFullySelected(node)` to ensure only fully selected nodes are targeted when applying colors.

Steps to reproduce:
1. Open html_editor.
2. Insert content: `<p><b>ab</b>cd</p>`.
3. Select `b` inside `<b>` and `c` inside `<p>` (`<p><b>a[b</b>c]d</p>`).
4. Apply text color (e.g. red).
5. Observe "ab" and "c" was colored instead of just "b" and "c".

task-6456443

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

Forward-Port-Of: odoo/odoo#285658
Forward-Port-Of: odoo/odoo#281462

Currently, an error occurs when the user tries to update suggested products.

**Steps to Reproduce:**
 - Install the `website_sale` module.
 - Go to `Settings` and enable `Automate suggested products` under the `eCommerce` section.
 - Go to `Website` > `eCommerce` > `Products` > `Products`.
 - Create a `product` and, in the `eCommerce` tab, add a `category`.
 - Make sure the `product` is `not published`.
 - On the `product`, click the `gear icon` and select `Update suggested products`.

`ValueError: TypeError('unsupported operand types in: product.template() | None') while evaluating 'records.action_update_suggested_products()'`

When the user updates suggested products, the system updates the product's suggested 
products - optional, accessory, and alternative products [1]. While updating the alternative 
products [2], the system tries to find products based on the categories and attributes shared 
with the current product [3]. When retrieving products from the current product's category, 
it gets None [4] because the products linked to that category are unpublished and are 
therefore excluded by the domain [5]. Later, using this None value raise the error.

This commit ensures that when accessing a missing key in the category dictionary, then it falls 
back to an empty product recordset.

[1]: https://github.com/odoo/odoo/blob/21e3310a3eba2ce915b33cf10ee4c14bdda7aad4/addons/website_sale/models/product_template.py#L346

[2]: https://github.com/odoo/odoo/blob/21e3310a3eba2ce915b33cf10ee4c14bdda7aad4/addons/website_sale/models/product_template.py#L384-L386

[3]: https://github.com/odoo/odoo/blob/21e3310a3eba2ce915b33cf10ee4c14bdda7aad4/addons/website_sale/models/product_template.py#L471-L483

[4]- https://github.com/odoo/odoo/blob/21e3310a3eba2ce915b33cf10ee4c14bdda7aad4/addons/website_sale/models/product_template.py#L482

[5]- https://github.com/odoo/odoo/blob/21e3310a3eba2ce915b33cf10ee4c14bdda7aad4/addons/website_sale/models/product_template.py#L445-L456

sentry-7660509183

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

Forward-Port-Of: odoo/odoo#281487

# Before this commit:
The image controller performance test expects the admin partner to be
unpublished. In parallel test runs, the website_partner demo data
publishes the admin partner, causing the test to follow a different
code path and fail.

However, during parallel test execution, the website_partner module
installs its demo data, which updates the admin partner:

```
<record id="base.partner_admin" model="res.partner">
    <field name="is_published">True</field>
</record>
```

As a result, user_admin.website_published becomes True.

# After this commit:
The test explicitly restores the required precondition by setting the
admin partner's is_published value to False before executing the
performance check.

As a result, the image controller always follows the expected
"unpublished" code path, making the test deterministic regardless of
whether website_partner or any other module with demo data has already
been installed during parallel testing.

Runbot-241102

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

Forward-Port-Of: odoo/odoo#278550

Currently, an error occurs when loading the sample data in the Shop Floor.

**Steps to Reproduce:**
 - Install the `mrp_workorder` module.
 - Go to `Employees` > `Configuration` > `Working Schedules`.
 - Delete the `Work Center 40 hours/week` record.
 - Go to `Settings` > `Users & Companies` > `Groups`.
 - Open the `Manage Work Order Operation` group and add the `Administrator` to the `users` list.
 - Open the `Shop Floor`. If the `Activate your Work Center` dialog appears, click it and then click `Configure Later`.
 - Click `Load Samples`.

`ValueError: External ID not found in the system: mrp.mrp_workcenter_calendar`

After the [recent commit], the sample work center uses the `Work Center 40 hours/week` working 
schedule instead of `Standard 40 hours/week`. As a result, if the `Work Center 40 hours/week` 
record is deleted, loading the sample data raises the error [1].

This commit ensures that when the Work Center 40 hours/week calendar is not available, it 
falls back to `Standard 40 hours/week`, restoring the previous behavior [2].
This fallback is required because `resource_calendar_id` is mandatory from the view perspective, 
even though it is not required at the model level. If it is left empty, the form displays a missing 
required field. The `Standard 40 hours/week` calendar is always available because it is linked to 
the main company [3] and its `resource_calendar_id` field uses `ondelete='restrict'` [4], preventing 
it from being deleted.

[recent commit]: https://github.com/odoo/enterprise/commit/336d721f7b353473fe5e07c29ce14ed77a88fb98

[1]- https://github.com/odoo/enterprise/blob/c0045ec3cf94650d66192a4ca3e0dc3c17daa5bd/mrp_workorder/models/mrp_production.py#L213-L216

[2]- https://github.com/odoo/enterprise/blob/51c1e74e90e510d59aad78820e2c29e821ba2854/mrp_workorder/models/mrp_production.py#L214-L217

[3]: https://github.com/odoo/odoo/blob/4c4219a7d9d51f703b15e83ab755faf1f2c8a71d/addons/resource/data/resource_data.xml#L10-L12

[4]: https://github.com/odoo/odoo/blob/4c4219a7d9d51f703b15e83ab755faf1f2c8a71d/addons/resource/models/res_company.py#L12-L13

sentry-7651161729

Forward-Port-Of: odoo/enterprise#126859

Steps to reproduce the issue:

- Create a link in editor.
- Copy another URL.
- Select entire link.
- Pasting copied link throws traceback.

This issue happens after merging commit [1] where `normalize_processors` callback returns nothing. After merging commit [2] each processor must return the original root if no processing is needed or processing is in place.

As a result, when this.processThrough("normalize_processors", container) is called from the `insert` method, the next processor in the chain uses `this.editable` as its default argument and removes the FEFF node, which is the anchor node. Later calling closestBlock(selection.anchorNode) returns null, resulting in the traceback. This PR aims to fix the traceback by returning the `root` in processor.

[1]: https://github.com/odoo/odoo/commit/be77a9a2003e09f4621d0ff774bf8749b326d037
[2]: https://github.com/odoo/odoo/commit/17d58d2fdf8da3a69c731fc5ea0d90b95e28efd6

task-6456004






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

Forward-Port-Of: odoo/odoo#283185

*=helpdesk_planning_field_service{,_sale_timesheet}

Steps to reproduce:
-------------------------
1. Install helpdesk_planning_field_service_sale_timesheet with demo data.
2. Open a helpdesk team (e.g., Customer Care) and enable field service planning.
3. Create a new ticket in Customer Care, plan two interventions, and mark them as completed.
4. Click the cog menu of the helpdesk ticket and click Preview.
5. In preview mode, click **Field Service** in the left sidebar.

Issue:
---------
A traceback occurs:
```python
File "/home/odoo/odoo/community/odoo/addons/base/models/ir_qweb.py", line 875, in _render_iterall
    raise QWebError(qweb_error_info) from error
odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the template:
    KeyError: 'format_datetime'
    Template: planning_field_service.portal_my_field_service_report_list
    Reference: 866
    Path: /t/t/t[3]/t/tbody/t/tr/td[1]/a/t
    Element: <t t-out="format_datetime(intervention.start_datetime, dt_format='MMM d, YYYY')"/>
```

Cause:
---------
https://github.com/odoo/enterprise/blob/28637781cd3ffc4c3dc0c2016dd5d6051793f641/helpdesk_planning_field_service/controllers/portal.py#L59-L63
After this 6857d1a, date formatting was changed to use `format_datetime`, and [planning_field_service](https://github.com/odoo/enterprise/blob/28637781cd3ffc4c3dc0c2016dd5d6051793f641/planning_field_service/controllers/portal.py#L42) was updated accordingly. However, `helpdesk_planning_field_service` was not updated to pass `format_datetime` in the template values, causing a **KeyError** when opening the field service intervention list.

Solution:
-----------
Pass `format_datetime` in the template values, following the same approach used in `planning_field_service`.

opw-6467400

Forward-Port-Of: odoo/enterprise#129227
Forward-Port-Of: odoo/enterprise#128519