## Steps to Reproduce:
- Install `l10n_tr_nilvera_edispatch` module.
- Run "**Nilvera: retrieve e-Dispatch purchase PDFs**" Scheduled Action.

## Error:
```
ValueError: Binary field stored in attachment, accepts only existence check; skipping domain in condition ('l10n_tr_nilvera_edispatch_xml_file', 'in', OrderedSet([True]))
```

## Cause:
After commit https://github.com/odoo/odoo/commit/3641f23a9b4cd401444ca3371873d8123922f7b1, The condition operators `=` and `!=` are normalized to `in` and `not in` respectively.

As a result:
```
('field', '=', True) becomes ('field', 'in', OrderedSet([True])) and 
('field', '=', False) becomes ('field', 'in', OrderedSet([False]))
```

After this normalization, the domain optimizer `_optimize_type_binary_attachment()` is applied - [1]. 
For attachment-type binary fields, it only allows `in/not in` operators, and a value should be `{False}`. 
Therefore, the condition (converted) `('l10n_tr_nilvera_edispatch_xml_file', 'in', [True])` is rejected.

Binary fields with `attachment=True` are not stored as a boolean value. When converting their domain to SQL, `condition_to_sql()` - [2] handles them as an EXISTS check on `ir.attachment` to determine whether an attachment exists.

## Fix:
This commit replaces the `= True` in the condition with `!= False`.

[1] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/domains.py#L1782-L1784
[2] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/fields_binary.py#L217-L218

sentry-7627832395

When an incoming mail server has the "Keep Original" option enabled, a
copy of every incoming mail is stored as original_email.eml. Because it
is not a document of the invoice, the system unattaches it, however
it may still be used as main attachment in case no other PDF or image
was attached to the message.

Steps to reproduce:
- Configure an incoming mail server with "Keep Original" enabled, using
  an alias pointing to a vendor bill journal.
- Send a mail to that alias containing an xml embedding a PDF.
- Open that bill

Issue:
The invoice's main attachment points to the .eml file.
This occurs because it is set before the PDF is extracted from the xml.
Then, when import extracts the PDF, it is added as attachment on the invoice,
but we already have a main attachment that won't be overwritten.
However, once a pdf or image is added as attachment, the system will show
the (broken) preview.

opw-6431726

Forward-Port-Of: odoo/odoo#285409
Forward-Port-Of: odoo/odoo#280318

Step to reproduce:
- install `pos_sale`
- create a pos and go to settings
- remove product from `Default Sale Product`
- start pos and select a product

Observation:
- we will get a blank screen and error in browser console
```
TypeError: Cannot read properties of undefined (reading 'id')
    at get orderDisplayProductName (point_of_sale.assets_prod.min.js:20914:497)
    at get orderDisplayProductName (point_of_sale.assets_prod.min.js:27593:14)
```
- similar case when we de-select downpayment product and load a SO
with downpayment

Cause:
- `default_product_id` was introduce in commit[1] which is necessary for
description first order line
- if we remove this field, for pos config, `this.config.default_product_id`
is undefined, and accessing its id raises error
[1] https://github.com/odoo/odoo/commit/0ce605f8db9aa9901bf6b14c4888e5bcc0734401

Fix:
- as in stable, we cannot make a field "required", we use python constraint
and hook `_check_before_creating_new_session` to ensure every session/config
has these products available with only exception to those session which are
already running
- for master, we plan to make the field required.

opw-6458117

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

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

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

Forward-Port-Of: odoo/odoo#281691

**Steps to reproduce:**
- Create a quotation
- Add order lines until reaching 200 (duplicating helps), save and ensure that the pager appeared (1-200/201)
- Drag one of the lines with the handle to reorder them
- Discard all changes (X shaped button) 

You will have an evaluation error

**Behavior:**
When loading a list of records exceeding the limit, only parts of the records are saved in `_cache`.
When triggering a reordering of said list, all records need to be loaded including the ones on other pages: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/static_list.js#L1139-L1149 `_getResIdsToLoad()` gets all Ids missing from the cache, these are then passed through `._createRecordDatapoint` and will then be stored in `_cache`.
The issue is that the Datapoints are getting created with only `activeFields` as data, which in our case are `id` and `sequence`

When discarding the changes `._checkValidity()`is called on each Datapoint: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/record.js#L423-L429 And then `._isInvisible()` is called.
This is where the issue happens, since only `sequence` and `id` are stored, when we try evaluate `combo_item_id`, which is the condition to see if sequence is invisible, `combo_item_id` is not found and we get an Evaluation Error.

This commit prevents going into `._checkValidity()` by adding `this.isInEdition` to the check leading to it, requiring that the record is in 'edit' mode which is not the case for records created with `_createRecordDatapoint()`

opw-6399024

Forward-Port-Of: odoo/odoo#281018

Steps to reproduce:
- Call your softphone with your smartphone.
- Let the smartphone ring forever. => At some point, you reach the voicemail and the softphone stops ringing but: - The softphone displays a weird message with emojis. - The call record stays "Trying to call" (and might *display* "Ended unexpectedly" in 19.2).

This commit fixes those two issues by showing a proper "Call missed" message and switching the call record status to "Missed". This is done in 19.2 and not before... because the behavior before is even more problematic:
- 19.1: the softphone keeps ringing and crash if you try to answer, that was mostly fixed thanks to [1] and this commit takes profit of those big ameliorations to fix the issue here.
- 19.0: you do not even reach voicemail (it stops without saying anything). This was apparently fixed as a side-effect of [2], which we do not consider worth even partially backporting as not critical.

[1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
[2]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf

task-6453500

Forward-Port-Of: odoo/enterprise#128731
Forward-Port-Of: odoo/enterprise#127075

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

### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses:
**Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client incorrectly retains the  `active_id` and `active_model` of the alias in the context.

**Solution:** We updated the `action_view_ticket` method in `helpdesk.team` to explicitly inject the correct `active_model` and `active_id` into  the context before calling `_for_xml_id`. This overwrites the polluted Alias data before the window action is evaluated.

### Current behavior before PR:
Clicking the "Tickets" smart button passes the old alias context into the action. This bad data flows into the ticket view, which attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message, resulting in a `MissingError`.

### Desired behavior after PR: 
The Python action sanitizes the context at the source, ensuring that the XML action and subsequent view evaluations receive the correct Helpdesk Team ID. Ultimately, the view will load normally without crashing.

opw-6395638

Forward-Port-Of: odoo/enterprise#129939
Forward-Port-Of: odoo/enterprise#125232

### Steps to reproduce: 

- Create a subcontracted product P1
- Create a storable product P2
- Buy 5 units of both products from your subcontractor
- On the receipt set both moves quantity to 2 Units
- Validate the receipt and create a backorder
#### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2.

### Cause of the issue:

Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO: 
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91
However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164
This is problematic since picking a move line will also pick the move:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267
And only picked moves are considered to be processed at picking validation.

### Note:

The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549
However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made  hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b

The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding  a picked move line on a subcontracted move will still pick that move).

Enterprise: https://github.com/odoo/enterprise/pull/123884

opw-6330584

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

Forward-Port-Of: odoo/odoo#285614
Forward-Port-Of: odoo/odoo#275304

Currently, an error occurs when a user tries to view the WhatsApp Business account.

**Steps to Reproduce:**

 - Install the `whatsapp_oauth` module.
 - Go to `Settings` > `Languages` and add `French (BE)`, then `switch to it`.
 - Go to `WhatsApp` > `Configuration` > `WhatsApp Business Accounts (Comptes Whatsapp Business)`.

`ValueError: L'élément '<xpath expr="//div[contains(normalize-space(.), 'Receiving Messages')]">' ne peut être localisé dans la vue parente`

When the user changes the language, the text in the view is translated [1]. Since the WhatsApp 
account view tries to locate the div using the plain text Receiving Messages [2]. Since the text 
has been translated in the parent view, the XPath can no longer locate the element and raise 
the error.

This commit ensures that the XPath uses the name attribute to identify the element, which is 
language-independent. We cannot use the class attribute because the same class is used by 
other div elements.

[1]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp/views/whatsapp_account_views.xml#L81-L84

[2]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp_oauth/views/whatsapp_account_views.xml#L61-L63

7534862409

Forward-Port-Of: odoo/enterprise#130003

Problem:
In Calendar, dragging a slot opens the quick create dialog. Typing a
subject and clicking the expand button in the dialog header creates the
event, but the form that opens is empty, and saving it creates a second
event for the same slot.

Cause:
`FormViewDialog` stores the id of the record it saved in `currentResId`,
which `onExpand` passes as `res_id`. `saveRecord` sets it only in the
branch that runs when no `onRecordSave` prop is given.
`AttendeeCalendarController` passes one since 30478fe855cd
(odoo/odoo#239435), so `currentResId` stays false and the action opens a
new record.

Solution:
Set `currentResId` in the shared branch of `saveRecord`. It is private to
`FormViewDialog`, so a consumer passing `onRecordSave` cannot set it.

Steps to reproduce:
- Open Calendar.
- Drag a slot in the week view to open the quick create dialog.
- Type a meeting subject.
- Click the expand button in the dialog header.
- Observe that the form opens on a new record while the event is created.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6476930)

opw-6476930

Forward-Port-Of: odoo/odoo#285899

### Issue before this commit:
When a CFDI invoice was sent through a mass action (Send & Print executed by OdooBot), the unit of measure in the generated CFDI appeared in English instead of the configured language (e.g. Spanish.

### Steps to reproduce the issue:
1.Download Accounting, Contacts and l10n_mx
2. Switch to Spanish (MX) language
3. Set the language of "Inmoviliaria CVA" and "XENON INDUSTRIAL ARTICLES" to Spanish (MX)
4. In contacts select Archived in filters and switch OdooBot language to Spanish (MX)
5. Create and confirm two invoices in the database, one for each customer but don't send these invoices
6. Go to the list view and select these two invoices, and click on "Send and print" and select CFDI
7. Check any of the XML files generated in any of the invoices (in the CFDI tab of the invoice)
8. See that the UoM in the XML file, will be set in english rather than Spanish (MX)

### Cause of the issue:
The context under which the batch action runs does not contain the lang key. As a result, translated fields (such as product_uom_id.name) were read in the source language (English) instead of the executing user's language, because nothing in the CFDI generation chain explicitly forced the correct lang into the context.

### Reason to introduce the fix:
A CFDI must always report translated fields in the correct language. The fix ensures the invoice is read with the executing user's language when the context doesn't already specify one, so translated fields are consistently correct across both flows.

opw-6399860

Forward-Port-Of: odoo/enterprise#129916
Forward-Port-Of: odoo/enterprise#125698

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

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

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