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

**Current behavior:**
The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report.

**Expected behavior:**
Same values

**Steps to reproduce:**
1. Make a workcenter and a BoM with an operation performed at the workcenter

2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration)
* example: 0:20 expected, 1:01 actual

3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different

**Cause of the issue:**
the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values.

**Fix:**
Don't use the rounded intermediary values in computing `oee`.

Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value).

opw-4795463

Forward-Port-Of: odoo/odoo#232730
Forward-Port-Of: odoo/odoo#218310

**Steps to reproduce:**
- Set handle notifications in Odoo for one user
- Go to `Sign` app with another user
- Create a signature request for the first user
- The first user is properly notified of the signature request, as the counter badge is updated.
- When clicking on the badge, no new message is shown.

**Issue:**
Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users.

In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent.

Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu.

**Fix:**
Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages.

We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues.

Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened.

Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it.

related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda

opw-4969005

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

Forward-Port-Of: odoo/odoo#235052
Forward-Port-Of: odoo/odoo#228740

Currently, an error occurs when trying to add an attachment after saving an
invoice email as a template in the `Send wizard`.

**Steps to produce:**
- Install the `account` module.
- Create a new invoice, fill in all required details, then `confirm` and click `Send`.
- Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name,
  and save the template.
- Try to add an attachment.

**Error:**
`AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'`
`AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'`

Root **cause:**
At [1], the code sets a new `template_id` when the template is saved. This
triggers `_compute_model()` at [2], which updates the model field to
`account.move.send.wizard` instead of `account.move`, using the `active_model`
context, causing the `error`.

**Fix:**
This commit ensures that after saving a mail template, the wizard retains the
correct model, same as [3], and prevents the attachment upload error.

[1]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296

[2]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248

[3]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389

sentry-6987172677

Forward-Port-Of: odoo/odoo#234268

### 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#99458
Forward-Port-Of: odoo/enterprise#98454