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

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

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

Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.

### Steps to reproduce:
- Create a kit product with a kit BOM:
    - 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation

### Cause of the issue:

Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does,  the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921

### Fix:

In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.

opw-5100026

Forward-Port-Of: odoo/enterprise#99739
Forward-Port-Of: odoo/enterprise#98589

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Forward-Port-Of: odoo/odoo#234908