## Summary

Minimal alternative: make the "Inventory at Date" wizard open the same rich stock report view instead of the basic one.

### Problem
The wizard opens `stock.view_stock_product_tree` (basic product list) instead of `stock.product_product_stock_tree` (full stock report with action buttons and search panel).

### Solution
Change the wizard's `open_at_date()` to use the stock report view and its associated search view. The wizard flow is preserved — this is purely a view swap.

### Changes
- `stock_quantity_history.py`: Changed `tree_view_id` from `view_stock_product_tree` to `product_product_stock_tree`, added `search_view_id` for the stock report search view

### Alternative
See #263507 for a more integrated approach that replaces the wizard entirely with a date picker in the search panel.

[Task #6152466](https://www.odoo.com/odoo/rd-fun-logistics-966/6152466)

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

Forward-Port-Of: odoo/odoo#263509

### Description of the issue/feature this PR addresses:

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

### Commit 1:

We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake

1. The cron gets stuck trying to fetch the problematic bill.
2. Users have no clue that there is a bill on KSeF that they have to fetch manually.

---

1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others
2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching.

---

task-6310321

---

### Commit 2:

Issues:

1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number),
company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number.
2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation
https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post

Fixes:

1. Change the unique constraint and the domain to allow same KSeF number per different companies.
2. Minimize the `to` parameter with `from` + 2 months.
3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small.

task-6260645

---

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

Forward-Port-Of: odoo/odoo#272689
Forward-Port-Of: odoo/odoo#270511

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272350
Forward-Port-Of: odoo/odoo#268273

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#272832
Forward-Port-Of: odoo/odoo#248985

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

The full composer builds default_partner_ids by doing recipient.persona.id over allRecipients. When a recipient is not linked to a partner, the chatter input inserts it with persona: false here:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/static/src/core/web/recipients_input.js#L151

false.id is undefined, so the wizard gets a bad id and clicking the recipient tag crashes with `Invalid ids list: false`.

The persona is false because /mail/partner/from_email returns no partner for unresolved emails when the user does not have base.group_partner_manager. That matches the gate _prepare_post_data already uses for the simple post flow:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/controllers/thread.py#L153,L155

The full composer just was not handling that case.

Filter out persona-less recipients from default_partner_ids so the wizard only sees real partner ids. The full composer now drops them the same way the simple post path already does.

Steps to reproduce:
1. As Administrator, create a user with the Sales group only (no Contact Creation).
2. Log in as that user.
3. Open a CRM lead whose Email is set but Customer is empty.
4. Click Send message.
5. Click the expand icon to open the full composer.
6. Click the recipient tag in the To field.

=> Recipient shows as Unnamed and clicking it raises an RPC error.

Ticket [link](https://www.odoo.com/odoo/project.task/5974081)
opw-5974081


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

Forward-Port-Of: odoo/odoo#271422
Forward-Port-Of: odoo/odoo#251780

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

Ticket [link](https://www.odoo.com/odoo/project.task/6140191)
opw-6140191

Forward-Port-Of: odoo/enterprise#115444

Issue:
------
`l10n_pe.address_form_fields` inherits from `portal.address_form_fields` but targets a `<div>` element that has been moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while rendering the template:
    ValueError: Element '<div id="div_city_id">' cannot be located in parent view (view: l10n_pe.address_form_fields)
    Template: website_sale.address
    Reference: 1973
    Path: /t/t/div/div/form/div/t
    Element: <t t-call="website_sale.address_form_fields"/>
```

Steps to reproduce:
-------------------
1. Install `l10n_pe` and `website` in v19
2. Upgrade to v19.2
3. Go to the website and add a product to the cart
4. Go to checkout → Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_pe.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6302145]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73#diff-83bb066f4477532b76aadd957ae736d0c0b67bc66b48d6f47c035e8cfb4773deR7-R21
[6302145]: https://www.odoo.com/odoo/70/tasks/6302145?debug=1

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#271246

Problem:
Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns.

Cause:
Portal users are restricted to their own res.users record. Reading create_uid and last_edition_uid of internal users raises an AccessError. This was not raised in 19.0.
Specifically, the `many2one_avatar_user` field widget defines `write_date` in `relatedFields`, which forces the RPC to read the `write_date` field of the target user. Since portal users cannot read other users' records, it raises an AccessError.

Solution:
Only include `write_date` in the field widget's `relatedFields` if the current user is an internal user. For portal users, `relatedFields` will be empty, avoiding the AccessError.

Steps to reproduce:
1. Create a Knowledge article.
2. Add an "Item list" element.
3. Add some items to the list.
4. Share the article with a portal user.
5. Open the article as the portal user.
6. Observe that only the list header is visible and the items are not displayed.

opw-6199714

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

Forward-Port-Of: odoo/odoo#269479

Before this commit, if we select "Properties" in the field to update in a server action, without selecting a property, there was a traceback. We couldn't set a value for a selection property because the selections wasn't stored in the DB like a typical selection. But are store in the property definition with un-guessable values.
The reference properties couldn't be set either.
The x2many properties wasn't corretly handle either.

Now, we don't return a traceback and let the already existing warning hint the user that the field chain is invalid.
There is a widget to set selection property by giving field name, property name and model name.
The reference properties can bet set now.
The x2many properties are now handle. And for that a new value_type_show has been created: "x2many". With this, in later improvements, the field shown for x2many in action server will be a tags selector. The action server also handle the Commands for x2many properties for now.

TASK-4672497




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

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#121849
Forward-Port-Of: odoo/enterprise#116890

Overview
------

When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X.

How to reproduce
------

1. Create a new mailing for a target model X (e.g. `mailing.contact`)
2. Set a content for that mailing (you can choose from the existing themes)
3. Set that mailing as a favorite (using the favorite star button)
4. Create a new mailing for another target model Y.
5. Redo steps 2. and 3.
6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview)
7. Change the target model to Y.

Expected Behavior
------

Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y.

Current Behavior
------

The title of the template is changed into the one of Y however the preview remains the one of mailing X.

Cause of The Issue
------

After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value.

Task-6332946



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

Forward-Port-Of: odoo/odoo#272244
Forward-Port-Of: odoo/odoo#272065

## [FIX] website_sale_renting_planning: prepare payment if demo is installed

Before this commit, the demo  `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup.

After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared.

https://runbot.odoo.com/odoo/runbot.build.error/940273

## [FIX] website_sale_renting_planning: unforbid weekend in tests
Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday.

This commit fixes that but setting  `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week.

https://runbot.odoo.com/odoo/runbot.build.error/940312

## [FIX] website_sale_renting_planning: search for product in shop page

Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page.

After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page.

https://runbot.odoo.com/odoo/runbot.build.error/940275

Forward-Port-Of: odoo/enterprise#121342

- Description of the issue/feature this PR addresses:
- The mandatory product_id field required by the many2one_uom widget was omitted from the list view, causing the issue.
- The issue occurred when the customized 'Extend Order' button was clicked, opening the wizard with all sales order lines loaded into its one2many field.
- Error message: UncaughtPromiseError > OwlError

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

Occured on apollohomecare-migration-v19-33341368.dev.odoo.com on 2026-06-26 10:18:38 GMT

OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
    Error: An error occured in the owl lifecycle (see this Error's "cause" property)

Caused by: Error: The widget 'Many2OneUomField' (field 'product_uom_id') needs a 'product.product' or 'product.template' field. 'product_id' is used but is related to 'undefined' model.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#272417

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

**Current behavior before PR,**
Computing `main_user_id` of a partner involved filtering active users within a
loop. To avoid losing the prefetching, we manually forced all partner users to
be kept in the prefetch during each iteration. This caused performance issues as
the recordset grew large (e.g., during auto-subscription).

**Desired behavior after PR is merged,**
All partner users are prefetched and filtered once, removing the need for a
repetitive manual prefetch.

**Benchmark,**
The following observations were recorded when auto-subscribing users to a
discuss channel at different scales.
The _Before_ and _After_ results represent the max values from three consecutive
tests.

|  Records |   Before |      After |
| :--------| -------: | ---------: |
|    3k    |   ~2.3s  |    <90ms   |
|    5k    |   ~3.8s  |    <160ms   |
|    10k   |   ~7.6s  |    <300ms  |

part of task-6116079



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

Forward-Port-Of: odoo/odoo#271549

#### Description of the issue this PR addresses:
- When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening.
- Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position.
- Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line.

#### Desired behavior after PR is merged:
- Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox.
- Emoji shortcuts now works when used with a preceding space anywhere in the paragraph.

Enterprise PR-https://github.com/odoo/enterprise/pull/118310
task-6243724

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

- Description of the issue/feature this PR addresses:
- The mandatory product_id field required by the many2one_uom widget was omitted from the list view, causing the issue.
- The issue occurred when the customized 'Extend Order' button was clicked, opening the wizard with all sales order lines loaded into its one2many field.
- Error message: UncaughtPromiseError > OwlError

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

Occured on apollohomecare-migration-v19-33341368.dev.odoo.com on 2026-06-26 10:18:38 GMT

OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
    Error: An error occured in the owl lifecycle (see this Error's "cause" property)

Caused by: Error: The widget 'Many2OneUomField' (field 'product_uom_id') needs a 'product.product' or 'product.template' field. 'product_id' is used but is related to 'undefined' model.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#272417

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 1 x COMP (lot tracked)
- Create and confirm an MO for 1 units of FP
- Set the quantity producing on the MO to 1
> The consumed qty was updated to 1 unit
- Set a lot on the pre-production pikcing and validate
#### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less

### Cause of the issue:

The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand:
https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426
In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been.

Issue 2:

Steps to reproduce:

- In the settings Enable Multi-Steps Routes
- Unarchive MTO
- Create 3 products: 
  - Final Product: Tracked by SN with a BOM: 1 X Super Component
  - Super Component: Tracked by SN, MTO with a BOM: 1 X Component
  - Basic Component: Put 10 units in stock
- Create and confirm an MO for 3 units of Final Product
> This should create an MO for 3 units of Super Component
- Go to the Child MO > Cogs wheel > Split in 3 MO's
- Click "Generate serial" on each Child MO and validate the first one
- On the MO for Final Product > Cogs wheel > Split in 3 MO's
- On the first MO, click "Generate Serial"
> Error: Reserving a negative quantity is not allowed.

### Cause of the issue:

The `action_generate_serial` calls in turn the `set_qty_producing`:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601
However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426
But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470

opw-6128575
opw-6317083

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

Forward-Port-Of: odoo/odoo#271123

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

**Current behavior before PR,**
Computing `main_user_id` of a partner involved filtering active users within a
loop. To avoid losing the prefetching, we manually forced all partner users to
be kept in the prefetch during each iteration. This caused performance issues as
the recordset grew large (e.g., during auto-subscription).

**Desired behavior after PR is merged,**
All partner users are prefetched and filtered once, removing the need for a
repetitive manual prefetch.

**Benchmark,**
The following observations were recorded when auto-subscribing users to a
discuss channel at different scales.
The _Before_ and _After_ results represent the max values from three consecutive
tests.

|  Records |   Before |      After |
| :--------| -------: | ---------: |
|    3k    |   ~2.3s  |    <90ms   |
|    5k    |   ~3.8s  |    <160ms   |
|    10k   |   ~7.6s  |    <300ms  |

part of task-6116079



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

Forward-Port-Of: odoo/odoo#271549

[FIX] stock,*: properly compute forecast availability after PO resupply scrap
* : mrp_subcontracting_purchase

# How to reproduce
- Enable Subcontracting in the settings
- Create Product A with :
	- Quantity : > 0
	- Routes : Buy & Resupply Subcontractor on Order
- Create Product B
- Create BOM for that Product with
	- BOM Type : Subcontracting
	- Subcontractors : any
	- Component : Product A
- Create a PO for Product B
- Confirm the PO Order
- Use the Resupply smart button
- Click on the gear icons > Scrap
- Scrap Product A

# The problem
A traceback will appear.

# Cause
There are two main ways to get the picking type's code of a move. Either :

- `product_code` which is a related field to `picking_id.picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L174

- `picking_type_id.code` where `picking_type_id` is a computed field :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L283-L287

When we scrap the products, we call the `do_scrap()` function that creates a new
scrap move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L158

When we do so, the create move's `picking_code` wil be the code of the picking type
of the current picking (The subcontractor resupply) :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L151

But `picking_type_id.code` will be different because there is a
`default_picking_type_id` value set in the context by :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/purchase_stock/models/purchase_order.py#L223

In our case, theses values end up not being the same. Later, when we compute the forecast
information of the move, we prefetch virtual available keys and put the moves in a dict
based on those keys.
The computation of the virtual available key is based on the `picking_code` of the move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L488-L490
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L496-L499

When later we try to fetch back the move, we compute the virtual available key based on
`picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L529-L536

But since `picking_code` and `picking_type_id.code` are different, the output
`key_virtual_available` is also different. Essentially, we add the move in the
dict with key A and then try to fetch it back using key B, which gives us a KeyError.

opw-6145887

Forward-Port-Of: odoo/odoo#272171
Forward-Port-Of: odoo/odoo#263799

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#114876

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d00e4b62c5 [REL] 18.3.54 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/722416eaf1 [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5c888b116c [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Description of the issue/feature this PR addresses:
The rating module does not correctly extend the mail modules onClick for NotificationItem

Current behavior before PR:
* mail NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread, message)`
* rating NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread)`
  * causing the [if in onClickThread](https://github.com/odoo/odoo/blob/18.0/addons/mail/static/src/core/public_web/messaging_menu.js#L39C17-L39C24) to be missed and falling backup to opening the thread
     ```javascript
            if (message?.needaction && message.message_type === "user_notification") {
                this.store.inbox.highlightMessage = message;
                this.openDiscussion(this.store.inbox);
                return;
            }
            this.openDiscussion(thread);
            return;
     ```

Desired behavior after PR is merged:
* rating should not change the fallback behaviour for messages without a rating_id and still allow opening the user_notification in inbox instead of switching to the thread

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

Info @wt-io-it

Forward-Port-Of: odoo/odoo#244521

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#120035

In POS Restaurant with Germany Fiskaly enabled, splitting and paying from a table works once, but repeating the same flow from the Orders tab lets the parent order show lines that were already paid in previous splits. Functionally, the cashier can keep splitting and paying the same line again and again because the parent draft order is not updated consistently in that path.

Steps to reproduce:
-------------------
* Enable POS Restaurant with l10n_de Fiskaly
* Create a table order (e.g. 3 meals + 3 drinks)
* Open Split Bill, move 1 meal + 1 drink, and pay
* From Orders tab, open the remaining parent order and repeat split + pay
* Reopen the parent order from Orders tab

> Observation:
The parent order still contains quantities that were already split/paid, so the same items can be paid multiple times from the Orders tab.

Why the fix:
------------
The Fiskaly `syncAllOrders` override diverged from core sync behavior in the split flow: it ignored explicit `options.orders` and did not await transaction creation for inactive transactions. In the split-bill path this could skip or desynchronize parent-order updates, leaving stale quantities on the parent order.
The fix restores expected sync semantics by honoring `options.orders` and awaiting transaction creation before deciding sync eligibility.

opw-6175880

Forward-Port-Of: odoo/enterprise#117206

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and `path@test.com`)
3) Generate offer and sign with all the required signer(applicant and Marc Demo). 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as `john@example.com`).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as `path@test.com`)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

opw-6280170

Forward-Port-Of: odoo/enterprise#120566

**Steps to reproduce:**
- Install the `l10n_mx_reports` module and switch to a Mexican company.
- Navigate to Accounting > Reporting > Trial Balance.
- From the dropdown menu, click `SAT (XML)`.
- Open the generated XML file and inspect the `<BCE:Ctas>` nodes.

**Observation:**
- The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni`
- However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin`

**Root Cause:**
At [1], the attributes of the `<BCE:Ctas>` node are defined in an order 
that differs from the SAT-recommended structure. While the XML remains 
valid, the generated report does not match the layout recommended by the 
Mexican government specification.

**Fix:**
This commit reorders the `<BCE:Ctas>` attributes to follow the 
SAT-recommended structure, aligning the generated XML with 
the behavior introduced at [2] for `saas-19.3`.

backport-of: https://github.com/odoo/enterprise/pull/115374

[1]:
https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20

[2]:
https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22

opw-6297711

Forward-Port-Of: odoo/enterprise#121440

When uploading a font file "FontName 123 Light.otf" the baseFontName needs to be quoted in the font-face CSS to be valid.

Single font files parsing for the shortestNamedFont now also correctly keeps the weight for the targetFonts.

Description of the issue/feature this PR addresses:
Uploaded fonts with spaces in the name are not working.

Current behavior before PR:
When uploading a font with a space in the filename like  "FontName 123 Light.otf" the css declaration in the attachement is wrong and not working:
```css
@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: FontName 123 Light;
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Desired behavior after PR is merged:
The font name is now correctly quoted and the font attributes are no longer overwritten for the shortestNameFont:
```css
@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 400;
	src: url("/web/content/1057/FontName 123 Light.otf");
}@font-face {
	font-family: "FontName 123 Light";
	font-style: normal;
	font-weight: 300;
	src: url("/web/content/1057/FontName 123 Light.otf");
}
```

Info @wt-io-it

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

# Introduction
This PR fixes broken mention links linked to the fact that we replace strings
without paying attention to the fact that some strings may contain others
that we want to replace later. This affects both id's and names of records.
See commit messages for more details.

# How to reproduce
- Create Contact A and then Contact B and either :
   - Contact B's id need to contain Contact A's id (e.g. Contact B id = 12; Contact A id = 1)
   - Contact B's name need to contain Contact A's name (e.g. Contact B name = ABC; Contact A name = AB)
- In a chatter create a message mentionning first Contact B and then Contact A
> Depending on the version, you might need to reload the page here

- Edit the message and save

# The issue
We see a broken mention in the chatter

# Cause
When saving an edited message, we give the raw body of the message (without the mention links) and the mentionend partners to `generateMentionsLinks` : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L152

This method's purpose is to replace the text links ("@Contact A") with actual html links. It does so by enumerating each partner given as an argument and replace the text mention with a placeholder :
https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L158

It will then replace the placeholders with actual links : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L208-L218

The issue is that in both of those steps, we can try to replace a string that is contained
in another string we want to replace. 

For exemple : 
"string123 some text string12"
If we try to replace "string12" first, then we will select the wrong string : 
"[string12]3 some text string12".

opw-6313748