Scenario:

- create a page with url "가" (\N{HANGUL SYLLABLE GA})

then in safari: copy the url to open it in a new tab => a 404 error is shown
in all browser: go to /가 writing it manually => a 404 error is shown

Cause:

We decompose the unicode combination to remove diacritics, but never
recompose them, so we save the slug
\N{HANGUL CHOSEONG KIYEOK}\N{HANGUL JUNGSEONG A} (NFD normalization)
instead of \N{HANGUL SYLLABLE GA} (NFC normalization). Those appear
exactly the same, but when typing you would usually use the NFC one.

Comparing other software, they usually convert NFD to NFC but not the
other way.

When you use the address bar in safari, the URL is normalized with NFC
so you can't type or copy paste a NFKD path to get to it (and can only
get to it by link).

But the issue still exists for other browser where you will usually
manually type NFC and not NFKD.

This is not reproduced, but this could also have effect with search motor
that would normalize link content.

Fix:

When creating slug, normalize to NFC after the removal of diacritics.

opw-5184532

__pr note:__

the original ticket also reported about removal of diacritical mark in Vietnamese and Japanese, but this seems a more of a feature for master change since we have had "éléphant" becomes "elephant" since forever.

other services that allow unicode in path (such as wordpress, wix) seems to just keep the diacritics and normalize to NFC even if the input was in NFD.

for NFD / NFC explanation: https://docs.python.org/3/library/unicodedata.html#unicodedata.normalize

Forward-Port-Of: odoo/odoo#234416

Versions
--------
- 18.0+

Steps
-----
1. Have a product with multiple variants;
2. go to one of its attributes;
3. in the form, change the default extra price on multiple lines;
4. click on "Update extra prices";
5. add the updated variants to a sale order.

Issue
-----
Only the line on which "Update extra prices" was clicked has been updated, even though the button disappeared on all lines after clicking it.

Cause
-----
The `_compute_default_extra_price_changed` method only compares the `default_extra_price` of the current record to its `_origin` value. Consequently, after saving the form, it will return `False`, even though only one attribute has been updated.

Solution
--------
Aside from checking whether the value changed on the form, also check whether any product template attribute value has a `price_extra` that's different from the product attribute value's `default_extra_price`.

This way, clicking on "Update extra prices" once won't make the other update buttons disappear.

opw-5240236

Forward-Port-Of: odoo/odoo#235088

**Steps to reproduce:**
- Create some activities which should not be accessible to a specific user (according to the `_search` filtering of `mail.activity`)
- Go to Activity Menu > View all activities as the given user
- Ensure that the limit (default: 80) is lower than the total number of activities which should be returned and that the new activities are in the returned elements
- On `web_search_read` some records are removed by the `_search` override
- The pagination navigation buttons are disabled as the returned number of records is lower than the limit
- This means that some activities are not accessible to the user (everything above the given limit)

**Issue:**
The issue comes from the `_search` override which checks the records available to the user. As it's done after fetching with the limit, the resulting number of records can be lower than expected and this breaks the `_format_web_search_read_results` which considers that we have all the possible records and doesn't try to fetch the total count of records.

**Fix:**
The main issue can't be directly fixed without modifying the way the access are checked in the `_search` override.

This could be mitigated by changing the search limit, making the search as superuser, or adding specific filtering but each has its own limitations.

Adding `force_search_count` should allow the user to navigate between pages anyway and see all the available activities. But the number displayed in the pagination will often be incorrect for the current and total count. (e.g. we can have 75 records but 1-80/150 is displayed out of 140 actually readable records)

opw-5046389

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

Forward-Port-Of: odoo/odoo#233585

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99592
Forward-Port-Of: odoo/enterprise#99232

Currently, an error occurs when the user immediately removes a catalog product after adding it.

Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)):
 - Install the `sale_management` module.
 - Go to `Sales Orders` and create a new `sale order`.
 - In the order line, click on the `Catalog` button.
 - `Add` a product and then immediately `remove` it.

`ValueError: Expected singleton: sale.order.line()`

After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4].

This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist.

[this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8

[1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19

[2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202

[3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219

[4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603

sentry-7019831319

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

Forward-Port-Of: odoo/odoo#235470

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

Currently, an error occurs when the user immediately removes a catalog product after adding it.

Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)):
 - Install the `sale_management` module.
 - Go to `Sales Orders` and create a new `sale order`.
 - In the order line, click on the `Catalog` button.
 - `Add` a product and then immediately `remove` it.

`ValueError: Expected singleton: sale.order.line()`

After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4].

This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist.

[this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8

[1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19

[2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202

[3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219

[4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603

sentry-7019831319

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

Forward-Port-Of: odoo/odoo#235470

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

### State of the art:

Control point for the manufacturing operation type are not expected to create QC when they refer to components.

### Steps to reproduce:

- Create a BOM for a final product FP:
    - 1 X COMP (consumable)
- Create a Quality Control Point:
    - Control: Quanity
    - Operations: Manufacturing
    - Product: COMP
- Create and confirm an MO for 1 unit of FP
#### > A QC is created for the component

### Cause of the issue:

Quantity quality checks related to MOs are expected to be created by `_create_quality_checks_for_mo`, which ensures that only moves referring to the production are considered:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move.py#L23-L29
However, each time a `stock.move.line` is created, it triggers the related "quantity" control points if it is not filtered out of the applicable lines:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L28-L35
The issue is that move lines related to `move_raw_ids` are always considered applicable:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L31-L34
and that the `_create_check` triggers "quantity" control points that directly refer to the `product_id` of the move line:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L79-L88

Note, however, that `_create_check` ignores control points of move lines related to a raw move if they do not refer to any product_ids, due to `_get_quality_points_all_products` (which is only called to find control points without a set `product_ids`):
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L20-L24
This explains why the test `test_04_quality_check_on_quantity` did not trigger the creation of quality checks for components.

### opw-5137594

Forward-Port-Of: odoo/enterprise#97217

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99592
Forward-Port-Of: odoo/enterprise#99232

This fix a traceback:
- Create a report "A" with Period Comparison set to True
- Create a report "B" with Period Comparison set to False
- Create a composite report with report "B" inside.
- Use the variant filter to switch from report "A" to the composite report

This happens because of a UI refresh in `loadReportOptions` trigged by:
- delete this.reportOptionsMap[cacheKey];
- delete this.loadingCallNumberByCacheKey[cacheKey];

When refreshing the UI, it will start with the cachedOption set to the value of the displayed report (report "A"), and is able to pass the condition inside `filters.xml`: `<t t-if="controller.filters.show_period_comparison">`.

While this is happening, the loading of the new report "composite" reaches `this.cachedFilterOptions = options;`. However, the UI refresh is still ongoing, and when it reaches `<t t-if="controller.cachedFilterOptions.comparison.string">` in `filter_comparaison.xml`. If the new report doesn't have the comparaison filter enabled, cachedFilterOptions.comparison will be undefined triggering the traceback.

This is fixed by marking the objects, that would trigger this useless refresh, as raw preventing them from triggering a refresh.

This only happened on composite reports since the cacheKey used to load them is different from the one received by the call to get_options due to the sections.

task-5085985

Forward-Port-Of: odoo/enterprise#99780

Before this commit:
- The `.dat` export adjusted its date based on the selected export type’s periodicity (quarterly or annually) using the report filter's date_to.
- This caused mismatches where the `.dat` file showed a different period than the report data.
- The adjustment only changed the date in header of `.dat` file but did not restrict data accordingly, leading to inconsistencies when exporting reports with different filter and periodicity types.
- Example: If the report filter is set to 'October 2025' month and the export type's periodicity is 'Annual', the `.dat` file would show 12/31/2025 even though the data in `.dat` file only covers 'October 2025'. Similar mismatch occurs for 'month & quarter' and 'annual & quarter' combinations.

After this commit:
- The `.dat` export date now fully depends on the report’s date filter, keeping report data and export date consistent.
- A non blocking warning is added in the `.dat` export wizard when the report period type is different from the export type's periodicity, helping users select the correct period type while still allowing export if intended.

task-5172259

Forward-Port-Of: odoo/enterprise#99241

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

Purpose
=======
Fix various interface issues related to the appointment app following the Testing Days for v19.

Specification
===========
- Placing add guests button after registration questions on front-end.
Following the addition of a phone question type (odoo/enterprise#82973),
the user phone input at registration is in the list of questions
and not at the top of the form in the base user information section anymore.
The Add Guests feature can thus be displayed before the phone number
which seems a bit odd.
Fixing the issue by moving the Add Guests feature at the end of the form,
after the list of questions.

- Fix the "Add Closing Day(s)" button visibility.
The button should be visible on every resource views (gantt, calendar, list),
and should be invisible on every staff booking views (gantt, calendar, list).
Currently, the button is visible on the list view for staff bookings, it should not.
The button is also not present on the calendar view for resource bookings, it should be.

Task-5079021

Forward-Port-Of: odoo/enterprise#96027

#### Steps to Reproduce
- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
- Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.
- Update controller logic to prevent public users from accessing an offer link if the offer's employee has a linked user.

task-5051394

Forward-Port-Of: odoo/enterprise#98856

**Steps to reproduce:**
1. Install the `Accounting` and `l10n_ph_reports` modules.
2. Create a contact with the company flag enabled.
3. Create an invoice using that contact.
4. Go to `Reporting → Summary Lists of Sales and Purchases → Sales`.

**Observed behavior:**
* The `Registered Name` column in the report is blank for companies.

**Cause:**
* The query logic was incorrectly showing the registered name only when a last name was present. This issue arose due to the change in how company/individual differentiation is handled.

**Fix:**
* Update the query logic for the Odoo report:
  - **Always display the registered name in the Odoo report**:
    - If individual: show `First Name`, `Middle Name`, `Last Name`.
    - If company: show `commercial_partner_id.name`.
  - **For the export file**:
    - If company: only show the registered name.
    - If individual: show `First Name`, `Middle Name`, `Last Name`.

The fix ensures that **Registered Name** is always displayed in the report, and the export behaves as expected for both individuals and companies.

Note: spec provided by po -> 
<img width="1662" height="431" alt="image" src="https://github.com/user-attachments/assets/a7a58a9e-b769-4815-ad0a-cef9c8e2eff7" />


opw-5143677

Forward-Port-Of: odoo/enterprise#99075

Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content.

This happens because message actions can condition overridden by some other modules, and the way overrides of action condition work is to have boolean value taking precedence over the local condition of action.

This architecture is meant to provide exhaustive list of actions to allow, which is quite useful to control what livechat visitors can have.

However this architecture requires overrides to properly return `undefined` when the local condition should apply, which was not the case for an override by `ai` module. So when `ai` module is installed, the "copy to clipboard" feature as not available.

This commit fixes the issue by adapting the condition in `ai` module to return `undefined` on non-AI conversations, and add test coverage for both `@mail` discuss suite and all overrides of discuss in `@test_discuss_full_enterprise`.

opw-5240768

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

Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content.

This happens because message actions can condition overridden by some other modules, and the way overrides of action condition work is to have boolean value taking precedence over the local condition of action.

This architecture is meant to provide exhaustive list of actions to allow, which is quite useful to control what livechat visitors can have.

However this architecture requires overrides to properly return `undefined` when the local condition should apply, which was not the case for an override by `ai` module. So when `ai` module is installed, the "copy to clipboard" feature as not available.

This commit fixes the issue by adapting the condition in `ai` module to return `undefined` on non-AI conversations, and add test coverage for both `@mail` discuss suite and all overrides of discuss in `@test_discuss_full_enterprise`.

opw-5240768

https://github.com/odoo/odoo/pull/236295

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289

Forward-Port-Of: odoo/odoo#234850
Forward-Port-Of: odoo/odoo#234521

Versions
--------
- 18.0+

Steps
-----
1. Have a product with multiple variants;
2. go to one of its attributes;
3. in the form, change the default extra price on multiple lines;
4. click on "Update extra prices";
5. add the updated variants to a sale order.

Issue
-----
Only the line on which "Update extra prices" was clicked has been updated, even though the button disappeared on all lines after clicking it.

Cause
-----
The `_compute_default_extra_price_changed` method only compares the `default_extra_price` of the current record to its `_origin` value. Consequently, after saving the form, it will return `False`, even though only one attribute has been updated.

Solution
--------
Aside from checking whether the value changed on the form, also check whether any product template attribute value has a `price_extra` that's different from the product attribute value's `default_extra_price`.

This way, clicking on "Update extra prices" once won't make the other update buttons disappear.

opw-5240236

Forward-Port-Of: odoo/odoo#235088

**Steps to reproduce:**
- Create some activities which should not be accessible to a specific user (according to the `_search` filtering of `mail.activity`)
- Go to Activity Menu > View all activities as the given user
- Ensure that the limit (default: 80) is lower than the total number of activities which should be returned and that the new activities are in the returned elements
- On `web_search_read` some records are removed by the `_search` override
- The pagination navigation buttons are disabled as the returned number of records is lower than the limit
- This means that some activities are not accessible to the user (everything above the given limit)

**Issue:**
The issue comes from the `_search` override which checks the records available to the user. As it's done after fetching with the limit, the resulting number of records can be lower than expected and this breaks the `_format_web_search_read_results` which considers that we have all the possible records and doesn't try to fetch the total count of records.

**Fix:**
The main issue can't be directly fixed without modifying the way the access are checked in the `_search` override.

This could be mitigated by changing the search limit, making the search as superuser, or adding specific filtering but each has its own limitations.

Adding `force_search_count` should allow the user to navigate between pages anyway and see all the available activities. But the number displayed in the pagination will often be incorrect for the current and total count. (e.g. we can have 75 records but 1-80/150 is displayed out of 140 actually readable records)

opw-5046389

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

Forward-Port-Of: odoo/odoo#233585

Currently, an error occurs when the user immediately removes a catalog product after adding it.

Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)):
 - Install the `sale_management` module.
 - Go to `Sales Orders` and create a new `sale order`.
 - In the order line, click on the `Catalog` button.
 - `Add` a product and then immediately `remove` it.

`ValueError: Expected singleton: sale.order.line()`

After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4].

This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist.

[this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8

[1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19

[2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202

[3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219

[4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603

sentry-7019831319

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

Forward-Port-Of: odoo/odoo#235470

#### Steps to Reproduce
1- Create a fresh database on Odoo 19.0.
2 - Install both the Appointments and Website modules.
3 - Go to the website appointment page generated by the module.
4 - Click Edit in the website builder.
5 - The website editor crashes with the SelectionPlaceholderPlugin error.
#### Issue
After Odoo 19 introduced the new [SelectionPlaceholderPlugin](https://github.com/odoo/odoo/blob/19.0/addons/html_editor/static/src/main/selection_placeholder_plugin.js) in the HTML editor, the appointment progress bar view began to crash, specifically when clicking the “Edit” button of the website editor on the appointment page.

This issue did not occur in earlier versions because the plugin did not exist. And the old editor never scanned or validated raw text nodes.

The appointment progress bar template contained a `li` node using d-flex directly on the `li` element.
In Odoo 19, the HTML Editor’s selectionPlaceholder plugin inspects the DOM after every render to determine where the selection placeholder blocks must be inserted.

Because d-flex changes the internal layout of the `li`, Owl and the HTML editor produces intermediate text nodes / inline nodes inside the flex container. During placeholder evaluation, the editor scans siblings before/after each block using:

```python 
selection_blocker_predicates(blocker)
```

This logic expects HTML elements, as it calls:
```python
blocker.hasAttribute(...)
```
However, the flex layout caused the plugin to receive a non-element node (e.g. a TextNode) as blocker.

Since TextNodes do not implement .hasAttribute(), the editor raised:
 ```python
TypeError: blocker.hasAttribute is not a function
```
This error propagated into:
 ```python
OwlError: An error occurred in the Owl lifecycle
```
which broke the entire website editor.

#### Traceback
```python
UncaughtPromiseError > OwlError

Uncaught Promise > An error occurred in the Owl lifecycle (see this Error's "cause" property)

Occurred on localhost:8069 on 2025-11-11 13:57:55 GMT

OwlError: An error occurred in the Owl lifecycle (see this Error's "cause" property)
    Error: An error occurred in the Owl lifecycle (see this Error's "cause" property)
        at handleError (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:762:101)
        at App.handleError (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:1420:29)
        at ComponentNode.initiateRender (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:854:19)

Caused by: TypeError: blocker.hasAttribute is not a function
    at selection_blocker_predicates (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14305:1708)
    at http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:115
    at Array.map (<anonymous>)
    at checkPredicate (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:106)
    at isSelectionBlocker (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14306:243)
    at SelectionPlaceholderPlugin.updatePlaceholders (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:14307:272)
    at http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12434:52
    at Array.forEach (<anonymous>)
    at Editor.startPlugins (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12434:38)
    at Editor.attachTo (http://localhost:8069/web/assets/1/d4f733d/web.assets_web.min.js:12425:6)
```
#### Fix

To avoid creating confusing DOM structures for the editor, the template was updated to:
- Wrap the inner content to keep the same UI layout without affecting the parent `li` block semantics.

##### This insure
- The items stay a clean block-level element.
- The HTML editor correctly identifies block boundaries.
- The selection placeholder plugin no longer receives invalid nodes.

OPW - [5226904](https://www.odoo.com/odoo/project/70/tasks/5226904)

Currently an error occurs when user change the move line quantity.

Steps to Reproduce [video](https://drive.google.com/file/d/12r0DxsKZkvuVjoCsRgXlHJ23NpaqciV7/view?usp=drive_link):

 - Install the `purchase_stock` module.
 - Create a `product` with category: `Costing Method: FIFO`.
 - Create a `purchase order` and add the newly created product to it.
 - Click `Confirm Order`, then click on `Receipt` and `validate` it.
 - Click on `Moves`, open the record, set the `Quantity to zero`, and `save`.

`ZeroDivisionError: float division by zero`

This error occurs when a user confirms a purchase order, validates its picking, and changes the move line quantity to zero. It then tries to update the move line value and the product's standard price due to the FIFO costing method, but the valued quantity becomes zero from [1], which raises an error at [2].

This commit ensures that if the move line has a zero quantity, the product's standard price remains unchanged.

[1]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/stock_move.py#L333-L343

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/product.py#L218

sentry-6993648057

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

- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.

#### Additional
- Mark the field `access_token` as readonly.

task-5051394

Forward-Port-Of: odoo/enterprise#93561

## Issue:
When adding landed costs to stock moves, the resulting move value was increased regardless of the quantity remaining in stock
As a result, moves with no remaining quantity could still receive additional value, incorrectly affecting products that are no longer in stock

## Cause:
The valuation is determine using the `move._get_value()` function, which uses the standard price when there is no linked PO, Bill, or Credit Note
However, it distributed the landed cost share based on the move itself, without considering whether the move’s quantity was still available in stock

## Steps to reproduce:
- Create a product (Tracking: Quantity, category: AVCO)
- Receive 2 units of the product.
- Deliver 1 unit
- Create a Landed Cost for the receipt with an additional cost of 100 $
- Open Inventory > Reporting > Move Analysis
- Add Value in Measures
- Look for the current month (add a product filter if needed)
- You should have Quantity: 2 and Value: 50$ after the fix

opw-5128570

Forward-Port-Of: odoo/odoo#232857
Forward-Port-Of: odoo/odoo#231936

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

**Steps to reproduce:**
1. Install the `Accounting` and `l10n_ph_reports` modules.
2. Create a contact with the company flag enabled.
3. Create an invoice using that contact.
4. Go to `Reporting → Summary Lists of Sales and Purchases → Sales`.

**Observed behavior:**
* The `Registered Name` column in the report is blank for companies.

**Cause:**
* The query logic was incorrectly showing the registered name only when a last name was present. This issue arose due to the change in how company/individual differentiation is handled.

**Fix:**
* Update the query logic for the Odoo report:
  - **Always display the registered name in the Odoo report**:
    - If individual: show `First Name`, `Middle Name`, `Last Name`.
    - If company: show `commercial_partner_id.name`.
  - **For the export file**:
    - If company: only show the registered name.
    - If individual: show `First Name`, `Middle Name`, `Last Name`.

The fix ensures that **Registered Name** is always displayed in the report, and the export behaves as expected for both individuals and companies.

Note: spec provided by po -> 
<img width="1662" height="431" alt="image" src="https://github.com/user-attachments/assets/a7a58a9e-b769-4815-ad0a-cef9c8e2eff7" />


opw-5143677

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Version:
- 18.0

Steps to reproduce:
1. create a subscription with a mixed invoice_policy (order + delivered)
2. pay through the portal
3. on the next_invoice_date of the subscription:
   - set qty_delivered = 1 for the delivered-policy product.
   - run _cron_recurring_create_invoice to generate a new invoice.

Issue:
When cron generates the invoice for the delivered product, the system links two
payment transactions to this invoice

Cause
- On portal confirmation, only order-policy products are invoiced.
- Because the delivered products are not invoiced upfront, the initial payment
  transaction gets linked only to part of the subscription.
- Later, when 2nd invoice is generated by cron, the system reuses the original
  payment token and tries to apply payment for both (delivered + ordered) again.

Solution
- When confirming a subscription with portal payment, create the invoice for all
  products (order + delivered).
- This way, the first payment covers the whole subscription and later invoices
  won’t get duplicate payments.

Taskid-4250892

Versions
--------
- 18.0+

Steps
-----
1. Have a product with multiple variants;
2. go to one of its attributes;
3. in the form, change the default extra price on multiple lines;
4. click on "Update extra prices";
5. add the updated variants to a sale order.

Issue
-----
Only the line on which "Update extra prices" was clicked has been updated, even though the button disappeared on all lines after clicking it.

Cause
-----
The `_compute_default_extra_price_changed` method only compares the `default_extra_price` of the current record to its `_origin` value. Consequently, after saving the form, it will return `False`, even though only one attribute has been updated.

Solution
--------
Aside from checking whether the value changed on the form, also check whether any product template attribute value has a `price_extra` that's different from the product attribute value's `default_extra_price`.

This way, clicking on "Update extra prices" once won't make the other update buttons disappear.

opw-5240236

### Steps to reproduce the issue:

(Easier to reproduce client side with CRM installed)

0. Install crm
1. Create Second Company
2. Create New User with Current Company as Default Company and Second Company in Allowed Companies
3. Create CRM Team belonging to Second Company
4. Add New User to Members of CRM Team
5. Receive error:

>     [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company.

### Explanation:

`crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it.

### Fix reasoning:

Removing restriction, as we want to avoid other multi-company issues by changing the behaviour.

opw-4214192

---

@nd-dew note:
Situation recap
![image](https://github.com/user-attachments/assets/9377ec70-0a57-4a48-b071-de588cde06a6)

So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). 

However looking at the tests it seems like this is desired limitation.

Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority.

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#225014

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

In the POS of a Mexican company, when requesting an invoice, the user
is asked to set the invoice to public or not. If the customer does not
have a recognized ZIP code or country, setting the invoice to public
**should not** raise an error, but it does. This is because the
`l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM,
which leads to the UserError below being triggered, as
`l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not
updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a *compute field*.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: \[[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)\]

To minimize behavioral changes, the required field
(`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not
longer raised when the *Invoice to Public* field is set to "Yes"
in the POS.

### Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"*
and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#98983