Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469

Forward-Port-Of: odoo/odoo#233967
Forward-Port-Of: odoo/odoo#224002

The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect).

Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted.

Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case.

This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario.

[1]: https://runbot.odoo.com/odoo/runbot.build.error/223185

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

Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com>

THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17
ORIGINAL PR: https://github.com/odoo/odoo/pull/205430

Description of the issue/feature this PR addresses: 
- In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice.

Steps to reproduce the error.
- Install the Argentine localization
- Create an invoice and post it
- From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. 
On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value.

Current behavior before PR:
When creating a debit note from a credit note get an error.

Desired behavior after PR is merged:
We can create a debit memo from a credit note.

opw-4304256

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#233875
Forward-Port-Of: odoo/odoo#225501

**Issue**
When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error.

**Steps to Reproduce**
1. Navigate to Accounting > Configuration > Journals.
2. Create a new journal.
3. Set the Type to Sales before entering the Name.
4. Save the journal.
5. Repeat the process to create another journal of the same type.
6. Observe that an error occurs: alias name is already used.

**Root Cause**
The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly.

**Fix**
Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured.

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

Forward-Port-Of: odoo/odoo#233101
Forward-Port-Of: odoo/odoo#225537

Note:

>The `WorkIntervals` class has been removed, and the
`keep_distinct` flag has been introduced in `18.4` to simplify its logic.
For the following explanation, we will refer to an `Intervals`
class with `keep_distinct = False` as 'Intervals', and to one
with `keep_distinct = True` as 'WorkIntervals'.

## The issue

Prior to this commit, the `other` parameter in the `_merge`
method could belong to a different class, not necessarily an
instance of `Intervals`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165

The comment indicates that normalization should be enforced; however, there
is no corresponding reference to it within the  `_boundaries` method.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53

That normalization just happens in the `__init__`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132

## Example

For example, in Planning module, we perform operations between
`Intervals` and `WorkIntervals`.

The `WorkIntervals` class behaves differently from `Intervals`:
while `Intervals` uses disjoint closed intervals, `WorkIntervals`
uses disjoint semi-closed intervals.

## Side effects

During these operations, the `_merge` method was not normalizing
the `_items`, which caused inconsistencies and errors (when we are
merging two unormalized intervals `([0, 10], [10, 20])` with an empty
`others`).

## The fix

This commit ensures that the `other` parameter is normalized before
processing the `_merge` operation. The fix ensures that normalized
intervals are always produced after `_merge`, even when unnormalized
intervals are provided as input.

## Real case

That issue has been found in that ticket: 5184291

Forward-Port-Of: odoo/odoo#235133
Forward-Port-Of: odoo/odoo#234352

**Steps to reproduce**
- With Studio, create a many2one field in relation to the Employee
model.
- Have a user with no "Employees" rights.
- With this user and in mobile view, click on the field to select
an employee.
-> No records found.

Note: the many2one_avatar_employee widget used in HR apps avoid this problem.

**Cause**
Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374
The `web_search_read` on the private employee model returns no
records when an `image_*` or `avatar_*` field is part of the requested
fields.
This is because we try to fetch these fields
https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240
but they are not stored on the public employee model, and will not be
put in cache.

When performing a read after that, these fields are missing from cache.
We try to fetch them from the db
https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185
but this fetch is again done using the public employee.

This results in missing values and is interpreted as an access error, no
data is returned in `web_search_read`.

**Solution**
Read the problematic fields to make them present in cache when the cache
of the public employee is copied to the one of the private employee.

opw-4297115

Forward-Port-Of: odoo/odoo#234456
Forward-Port-Of: odoo/odoo#197575

This commit contains 2 things:
- an helper to extract any tax_data and move it to another base_line
- the usage of this helper in UBL to turn emptying taxes into additional base_lines

== Add helpers to turn tax_data into new base_lines easily ==

With this helper, you can now exclude any tax from any base line and turn
them into new base lines.

Also, I changed a bit the smooth distribution of rounding because the math.ceil
is sometimes too greedy and make the whole results to be less accurate.

== Make a different behavior between recycling contribution taxes / emptying taxes ==

In UBL, all fixed taxes are treated as allowances/charges.
In this commit, we make a clear distinction between recycling contribution taxes
that are treated as allowances/charges and emptying taxes that are exempted of tax
and are treated as addition invoice lines in the document.

== Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function ==

The aggregator wasn't called when setting the 'target_base_line' at the very first time.

task_id: 5182783

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

Forward-Port-Of: odoo/odoo#234489

_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Forward-Port-Of: odoo/enterprise#98771

Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered.

**Steps to Reproduce:**
- Install Sales module
- Create a Quotation
- Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**.

**Error:**
`TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()`
 `missing 1 required positional argument: 'product_template_id'`

**Root Cause:**
When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered.

[1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13

**Solution:**
This commit prevents the error by correcting `depends` on the field
`is_configurable_product`, which will ensure that edit button will be only
present if the configurable product is selected.

Sentry-5741581459, 6925770690

Forward-Port-Of: odoo/odoo#217464

The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect).

Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted.

Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case.

This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario.

[1]: https://runbot.odoo.com/odoo/runbot.build.error/223185

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

Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com>

THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17
ORIGINAL PR: https://github.com/odoo/odoo/pull/205430

Description of the issue/feature this PR addresses: 
- In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice.

Steps to reproduce the error.
- Install the Argentine localization
- Create an invoice and post it
- From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. 
On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value.

Current behavior before PR:
When creating a debit note from a credit note get an error.

Desired behavior after PR is merged:
We can create a debit memo from a credit note.

opw-4304256

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#233875
Forward-Port-Of: odoo/odoo#225501

### Issue:
We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups.

### Steps to reproduce:
- Go to the "Payment reminder" email template
- Under the page "Content", add an attachment by clicking the "Attachments" button
- Under the page "Settings", add a dynamic report
- Create an overdue invoice for a partner
- Go on the form view of the partner, "Accounting" page
- Click "Send", make sure the template used is the one with the attachments
- Send
- The attachments on the template and the dynamic report are not sent

### Cause:
The mail template to send the follow-ups is only used to prefill the wizard.

### Solution:
Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments.

This commit also refactors how the attachments are computed:
The previous code was adding the invoices PDFs then removing them. The whole process was confusing.
Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments
depending on the options.

opw-5147736

Forward-Port-Of: odoo/enterprise#98454

1) Update l10n_uy_edi translations.
2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed.
3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 
4) Create xml attachment in the edi document if it is created by drag and drop xml file. 
5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 
6) Cron is run by batches (size=10).
7) Add tests.

The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes.

Task Adhoc side: 43467
Task latam side: 1355

Forward-Port-Of: odoo/enterprise#86829

_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Forward-Port-Of: odoo/enterprise#98771

**Issue**
When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity.

**Steps to Reproduce**
1. Create a subscription with a quantity of 50.
2. Confirm the subscription and generate an invoice.
3. Create a credit note (reversal) for the invoice.
4. Change the credited quantity to 30.
5. Post the credit note.
6. The subscription order line shows qty_invoiced = 0 instead of the expected 20.

**Root Cause**
The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced`

**Fix**
Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity

Opw-4908760

Forward-Port-Of: odoo/enterprise#99326
Forward-Port-Of: odoo/enterprise#91344

Versions
--------
- saas-18.4+

Steps
-----
1. Create a branch company B;
2. create a branch C for the branch company B;
3. change to branch C;
4. create a warehouse;
5. enable dropshipping;
6. add a vendor to a stored product with the Dropship route enabled;
7. log in as a sales user with access to branch C only;
8. add product to a sales order & confirm.

Issue
-----
> Access Error
> Uh-oh! Looks like you have stumbled upon some top-secret records.
> Sorry, Marc Demo (id=5) doesn't have 'read' access to:
> - Companies, YourBranch (res.company: 3)

Cause
-----
The error gets thrown during the `_prepare_purchase_order_line` method, specifically on the line which filters `supplier_taxes_id` using `lambda x: x.company_id in company_id.parent_ids`.

This passes via the field's `convert_to_record` method, which attempts to access the `active` field of the companies to filter out any that are archived[^1].

[^1]: https://github.com/odoo/odoo/blob/5b911a97a3885283d2f21ac30abb96cb10fe39d9/odoo/orm/fields_relational.py#L608-L612

In previous versions, this wasn't an issue, because the `active` field was still present in cache from the `_compute_parent_ids` which is called with `sudo`, but as of saas-18.4, it attempts to refetch these values, leading to the error.

Solution
--------
Instead of using `filtered`, use `filtered_domain` using the result of `account.tax._get_company_domain`.

opw-5112625

Forward-Port-Of: odoo/odoo#231743

This [commit] introduced 2 issues in `mass_mailing`:
- when creating a mailing with the basic editor, it adds an empty paragraph above the `o_layout` block, even thought the entire mailing content should be enclosed inside the `o_layout` block.
- when sending such an email (with the wrong paragraph) and consulting the readonly value in the `mass_mailing` Form view, the view started growing indefinitely.

How to reproduce:
- create a mailing using the basic editor and send the email
- open the mailing in readonly

Issues:
- there is a paragraph outside the `o_layout` element in the DOM
- the page scrolls indefinitely because `o_layout` has `min-height: 100%`.

Resolution:
- don't force `o_layout` to have a `min-height`, which will prevent the infinite scrolling for mailing that were sent with a wrongly placed paragraph.
- configure the mailing so that the editable element has `contenteditable="false"`, and the element with `o_mail_no_options` coming from the basic template gets `contenteditable="true"` so that the editor is informed that the user is only allowed to edit the content of that node, not the outside of it, which will prevent the empty paragraph insertion.

[commit]: https://github.com/odoo/odoo/commit/edf7f7bb0c62978640c181eccb4934855d5d872d

task-5263045

By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.

When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.

A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:

On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.

    You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.

    Operation: read
    User: 5
    Groups: allowed for groups 'Role / Administrator'

The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect).

Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted.

Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case.

This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario.

[1]: https://runbot.odoo.com/odoo/runbot.build.error/223185

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

Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com>

THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17
ORIGINAL PR: https://github.com/odoo/odoo/pull/205430

Description of the issue/feature this PR addresses: 
- In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice.

Steps to reproduce the error.
- Install the Argentine localization
- Create an invoice and post it
- From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. 
On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value.

Current behavior before PR:
When creating a debit note from a credit note get an error.

Desired behavior after PR is merged:
We can create a debit memo from a credit note.

opw-4304256

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#233875
Forward-Port-Of: odoo/odoo#225501

**Issue**
When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error.

**Steps to Reproduce**
1. Navigate to Accounting > Configuration > Journals.
2. Create a new journal.
3. Set the Type to Sales before entering the Name.
4. Save the journal.
5. Repeat the process to create another journal of the same type.
6. Observe that an error occurs: alias name is already used.

**Root Cause**
The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly.

**Fix**
Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured.

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

Forward-Port-Of: odoo/odoo#233101
Forward-Port-Of: odoo/odoo#225537

_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered.

**Steps to Reproduce:**
- Install Sales module
- Create a Quotation
- Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**.

**Error:**
`TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()`
 `missing 1 required positional argument: 'product_template_id'`

**Root Cause:**
When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered.

[1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13

**Solution:**
This commit prevents the error by correcting `depends` on the field
`is_configurable_product`, which will ensure that edit button will be only
present if the configurable product is selected.

Sentry-5741581459, 6925770690

\* : website, web_editor, html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

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

**Issue**
When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch.
Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view

**Steps to Reproduce**
1. Create and confirm a subscription with a recurring product (e.g., Car Leasing)
2. Generate and post the invoice for the subscription
3. Add a new product line to the subscription (e.g., Office Cleaning Service)
4. Delete the original invoiced line (Car Leasing)
5. Attempt to create an invoice for the new product line
→ Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category."
(https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view)

**Root Cause**
Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation.

**Fix**
Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation.

This commit fixes various issues when using Viva Wallet, including the following:
- When two Viva Wallet terminals had a payment in process at the same time in the same POS, one of the payments would fail on Odoo even when it succeeded on the terminal.
- When a previous Viva Wallet payment was stuck (never completed or failed), trying to make a new payment would mistakenly affect that previous order instead of the new order.
- When refreshing the page during a payment, it becomes stuck and never confirms or fails.

To fix these issues, there are two main changes:
1. Stop using the `getPendingPaymentLine` method to retrieve the Viva Wallet payment line. This method is flawed as it assumes there is only one pending payment at a time.
2. Store the Viva session ID for a payment in the payment line's UI state, instead of on the plain JS object. This allows it to persist after a refresh.

opw-5226966
opw-5248178

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

This error occurs while entering the barcode number.

Steps to reproduce:
---
- Install `stock_barcode` module(without demo)
- Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`
- Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply

Traceback:
---
`KeyError: 'rule'` (with GS1 Nomenclature)
`AttributeError: 'list' object has no attribute 'get'`  (without GS1 Nomenclature)

At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that.

This commit ensures that the correct keys are passed in the result dictionary.

[1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189

[commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60

sentry-6992944243

While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:

As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.

This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.

Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.

### Before this bug:

Sending a mail using `charset=cp-850` would generate a traceback.

Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"

This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable

Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```

Would generate:
```
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
    msg_dict = self.message_parse(message, save_original=save_original)
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
    msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
    content = part.get_content()
  File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
    return content_manager.get_content(self, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
    return self.get_handlers[maintype](msg, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
    return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```

### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias

OPW-5171501
OPW-5247486


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

Issue
-----
Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored.

E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.

Steps to reproduce
-----
- Have 2 products
- Create a MO for product 1 with a WO at work center 1, plan it
- Create a MO for product 2 with a WO at work center 2, plan it
- Got to Manufacturing, Planning, Planning by Work Center
- Add a custom group (by product)
- Drag the WO of WC2 and drop it on top of the other WO

> Both the WC and the product of the second WO change

Cause
-----
The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored.

https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34

While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored.

More broadly, gantt views should not ignore the `readonly` attribute of fields.

Solution
-----
Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly.

When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop.

-----
Ticket:
opw-4875366