Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to
reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process
is not properly batched. There is a single record
creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`.

This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is straightforward. Batching the write might seem useless at first as UPDATE queries are already batched on the ORM level. But actually the performance bottleneck comes from the post-processing done after writing a new `planning_slot.allocated_hours` value. By grouping the slots by allocated_hours we can speed up this post-processing.

#### speedup

Trying to import 72 new Public Holidays that lead to writing allocated hours on 85 planning slots

 - 2min -> 4.76s

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

Forward-Port-Of: odoo/odoo#209846

…compute

**PROBLEM**
When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one.

**STEPS TO REPRODUCE**
1. On a fresh database, install stock with drop shipping and storage locations enabled.
2. Create a new operation type and set the type to Delivery.
3. You will receive the following warning, despite an existing warehouse:

```
Please create a warehouse for company <company>
```

**CAUSE**
https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316

https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74

When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed.

Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False.

**FIX**
In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`.

opw-4603495

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

Forward-Port-Of: odoo/odoo#199676

Description of the issue/feature this PR addresses:
- This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. 
- This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So `l10n_it_document_type` field is set as non-copy. A `debit_note` key is added in the mapping of invoice features to document features if the invoice is a debit note.

- The tag in the XML template with the invoice linked to the debit note was changed based on requirements. Also, reference invoice name and date were added in XML if invoice is debit note.

tasks-4744444

Current behavior before PR:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note.
- When creating a debit note from a customer invoice, the new invoice has TD01 document type

Desired behavior after PR is merged:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Bill.
- When creating a debit note from a customer invoice, the new invoice has TD05 document type

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

Forward-Port-Of: odoo/odoo#212221
Forward-Port-Of: odoo/odoo#209072

A series of recent commits were aiming at allowing to change the partner of some journal entries in batch to allow de-duplicating the database, in the context of the EC Saleslist report[^1]

There are a few residual issues:
1. the lock dates can prevent any change on the lines. However in this specific case, the partner is not really changing and we want to allow it. This issue is solved by adding a context key, using a sentinel to avoid any users bypassing it.
2. if the lines are reconciled, it was also impossible to update the lines. Since all the lines are changing the partner at the same time, there is no need to block changing it as the reconciliation keeps its meaning.
3. After the second commit, we were actually not checking that the VAT was indeed the same on the partner getting a `parent_id` assigned
4. We don't check that the user has a specific accounting group anymore to allow invoicing users to set the main partner. It should not be an issue since the accounting values stay the same (same VAT)

[^1]: https://github.com/odoo/odoo/commit/38d43360781250415c63aba36eadcdce586fcbc0
https://github.com/odoo/odoo/commit/3941972dc7bba3e9a3d4497b312ff7f86a497157

Forward-Port-Of: odoo/odoo#212869
Forward-Port-Of: odoo/odoo#212784

Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel.

This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float.

To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing.

Failing in Distro Build , python version >=3.10  raises a `TypeError`
build_error-110207

Forward-Port-Of: odoo/odoo#211954
Forward-Port-Of: odoo/odoo#210551

To be able to merge moves, the 'price_unit' fields needs to be equal. However, if the product price decimal accuracy is higher than the currency decimal accuracy, then price_unit that looks the same are actually not, and prevent the merge.

It can happen in 2 situations:
- Python rounding precision: 55.55 != 55.5500000000001
- Tax involvement: If a tax is present on the Purchase Order, then the price unit will be recomputed to check the tax, with something similar to `CURRENCY_ROUND(price_unit * qty) / qty`, and because the currency rounding is less precise, the resulting price_unit will vary depending on the quantity.

A similar issue was already fixed in this commit: a7f08f0b4c87aeb60315d07c2e0a5fc4c7a21e50 ,but only for decrease of quantity.

This fix attempts to fix the increase of quantity. The main issue when fixing this problem is that we can't simply use float_compare, this is because the move values are fetched with _itemgetter_, and are 'compared' when _groupby_ is using these values as dictionary key.

The idea is to create a custom _itemgetter_, that will cast the price_unit as a string using the correct precision.

So, the list of values used in the group by will now look like this:
```
(product.product(84,), 'make_to_stock', ..., '25.67')
```
While it previously looked like this:
```
(product.product(84,), 'make_to_stock', ...,  25.668000000000003)
```

---

## How to reproduce
- Create a Storable product.
- Change the decimal accuracy of product price to 5.
- Create a purchase order for 10 units of P, and a price unit of 25.66803.
- Ensure a tax is set on the PO
- Confirm the order
- Edit the PO line quantity to 13 => The receipt has 2 lines of P, one for the first 10 units and the other for the added 3 units

https://github.com/user-attachments/assets/d93f697f-126a-44e5-b134-5bfc8f3ccc68

---

Test results without fix:
```
2021-01-14 09:12:15,000 21884 ERROR oes_17_test odoo.addons.purchase_stock.tests.test_purchase_order: FAIL: TestPurchaseOrder.test_05_po_update_qty_stock_move_merge
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/purchase_stock/tests/test_purchase_order.py", line 442, in test_05_po_update_qty_stock_move_merge
    self.assertEqual(len(purchase_order.picking_ids.move_line_ids), 1)
AssertionError: 2 != 1
```

---
OPW-4675425

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

Forward-Port-Of: odoo/odoo#210077

When creating an inter-wh transfer, the replenish order was showing the product's supplier in the Received From (partner_id) field and not the correct wh.

Steps to reproduce:
-------------------
* In Inventory, activate Multi-step Routes
* Create a new WH that can be Resupplied From another WH
* On a product, in the Inventory tab, activate the Route 'ABC: Supply Product from XYZ'
* On the forecast of that product, click on Replenish
* Match fields: Warehouse = ABC, Preferred Route = 'ABC: Supply Product from XYZ'
* Confirm
* Open the generated order

> Observation:
> The field Receive From contains the supplier of the product instead of the supplying WH.

Why the fix:
------------
The supplier_id was automatically set with the product's supplier_id. It's not correct for every routes. It's now updated accordingly to the route used and if we need the vendor.

opw-4717654


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

Forward-Port-Of: odoo/odoo#212645
Forward-Port-Of: odoo/odoo#210336

Currently, an exception is raised when validating a new receipt transfer where both the stock move and the push rule have the same destination location.

Steps to Reproduce:

1. Install `stock`  module
2. Enable Multi-Step Routes in Inventory
3. Routes -> Enable Warehouses and ensure they are linked to `YourCompany`.
4. Create a new rule for that route.
5. Set action to 'Push To' with same source and destination (e.g., WH/Stock) and Automatic Move to 'Automatic No Step Added'.
6. Go to Inventory -> Operations-> Receipts
7. Create a new receipt with the same destination location as defined in the rule.
8. Click on Validate

TypeError:
```TypeError
unsupported operand types in: stock.move() - None
```

This issue[1] occurs when the rule and stock have the same destination location. It does not execute and returns None, resulting in new_move being None. When `move.move_dest_ids - new_move` is executed, it raises an error.

[1]- https://github.com/odoo/odoo/blob/5c182227514af87659ee48360c63f33487de71bf/addons/stock/models/stock_move.py#L1048

sentry-6551676919

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

Forward-Port-Of: odoo/odoo#206850

### Steps to reproduce:

- In the settings enable Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second Warehouse WH2
- Inventory > Reporting > Stock
- Click on the "Warehouse 2" of the left panel
> This updates the results
- Click on the wheel icon of the control panel > export All
#### > the values are exported for the commutative value of all warehouses

### Cause of the issue:

Click on a specific warehouse on the left panel actually updates the warehouse_id key of the context (on the listController). And this context is used to determine the values returned by the `web_search_read` performed on the `product.product` model. For instance the computed quantity fields are warehouse dependent:
https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/stock/models/product.py#L131-L135 Now, the issue is that eventBus added by the list controller to export data's (and which needs to be initialised in the setup of the component as it setup hooks) is relying on the value of the context in the setup of the of the listController:
https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/web/static/src/views/list/list_controller.js#L186-L188 https://github.com/odoo/odoo/blob/dba8ec896cc4d3cc93fc10f40c809a1ab863d46d/addons/web/static/src/views/view_hook.js#L126-L130 In particular, the parameter of the method will not be re-evaluated as `this.props.context` where this is the controller at the time of the callback the values of the export.

### Fix:

While the `env` provided at the initialization of the enventBus is a in the setup of the Controller is an immutable object, `env.resModel.root` correspond to the representation of the present record/records and hence carries the context of the current representation. It is therefore a valid object to rely on at callback time.

### Note:

The issue is not reproducible prior to saas-18.2 since the refactoring of the export system has been done in commit 1e4e40cf78fe8151dffdcb19df2688787084732c

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

Forward-Port-Of: odoo/odoo#210105

Before this **PR**:
When creating a new partner for the first time, the compute method for the invoice EDI format is triggered as expected. However, if a country is set while creating the partner, compute method is not triggered again.

This breaks the intended flow where a default edi_format should be automatically set based on the country (using _get_suggested_invoice_edi_format). Since the compute method doesn’t re-trigger upon changing the country during record creation, the inverse method ends up setting invoice_edi_format_store to 'none'. This prevents subsequent calls to _get_suggested_invoice_edi_format from resolving the appropriate format, requiring users to manually set it — defeating the purpose of automatic localization-based assignment.

After this **PR**:
The dependency for the compute method has been changed from commercial_partner_id.country_code to country_code. This ensures the compute method reacts to changes in the country field during record creation. The logic still utilizes commercial_partner_id internally, so the intended behavior and correctness should be preserved, while ensuring the default format is set appropriately.

Forward-Port-Of: odoo/odoo#212742

In version 18.0, a traceback occurs when editing the 'Appointment:
Attendee Invitation' email template and then signing up for an
appointment.

**Steps to reproduce:**
1. Go to **Appointments**.
2. Click the **"Action"** gear icon next to an appointment, then select **Edit**.
3. Navigate to the **Options** tab.
4. Hover over the **Booking Email** template and click the **arrow icon** to open
    it.
6. In the Content tab, add some text near "Hello", then click **Save**.
7. Return to the **Appointment form**
8. Click the "**Go to Website**" smart button at the top
9. Select a date and time.
10. Confirm the appointment.

This raises a traceback

**In saas-18.3**, editing the `Appointment: Attendee Invitation` email
template throws an error when saving, making the template uneditable.


**Issue:**

The issue originates from this [commit](https://github.com/odoo/enterprise/commit/8b9a1a4462453bf64e7bc1307ededd0d127a27fa), which introduced a
`<div>` inside a `<p>` — a structure that violates the HTML specification.
Editing anything near the word 'Hello' in the template causes the
`<p>` tag to close prematurely during rendering. This pushes the `<div>`
outside of the `<p>`, breaking the directive chain and resulting in
the following error:
     

> SyntaxError: t-elif directive must be preceded by t-if or t-elif directive

    
Previously, the `<div>` was also pushed outside the `<p>`, but only after
evaluating all `t-if, t-elif, and t-else` conditions. Hence, it worked
correctly without editing the template.


**Solution:**

Placed the `<span>` as a child of the `<p>` tag to resolve the issue.
    
This fix also resolves the issue of being unable to edit the template
"Appointment: Attendee Invitation" in the UI **on saas-18.3**.

[Task-4624645](https://www.odoo.com/odoo/project.task/project.task/4624645)

Forward-Port-Of: odoo/enterprise#85669

If one uploads a vendor bill from the list view using the "Upload" button, a banner is then shown on the form view of the created move to reload the data that were extracted via IAP.

However, this banner is not shown if one creates an empty move, then uploads via the attachments, then the banner is never shown.

This is because when we arrive in the `onWillStart` of the `StatusHeader`, we subscribe to a channel using the `extract_document_uuid` which does not exist upon creating a new empty move. Then, when we upload our document, the move record is saved, and is sent to the backend. At this point, the move exists, and a `extract_document_uuid` is set. Then we get the OCR results (in `_check_ocr_status`) and we have a new status, we send this status on the bus but on a channel named `f"extract.mixin.status#{self.extract_document_uuid}"` where the `extract_document_uuid` is set. However, in the JS part, it was empty because it was created in the `onWillStart`.

To resolve this, we create a new channel to detect newly created documents. We send the new `extract_document_uuid` in this channel from the backend to the frontend. The JS can now subscribe to the correct channel using an existing `extract_document_uuid`.

Now, correctly the JS receives the updates of the Python via the bus, and can update the view accordingly.

opw-4566944

Forward-Port-Of: odoo/enterprise#83522

Currently, when a user sends an article to the trash, the system triggers a notification email to relevant members informing them that the article has been trashed and will be permanently deleted in 30 days (see: `knowledge_article_trash_notification`).

This email includes a link to the trashed article (see: `article_url`). However, when a user clicks the link, they are taken to a 403 error page and cannot access the article to review or restore it.

Steps to reproduce the issue:
1. Open an article
2. Send the article to the trash
3. Open the notification email and click on the article link

=> The user is redirected to a 403 error page

When an article is trashed (see: `action_send_to_trash`), it is marked as inactive. As a result, it is excluded from ORM search results by default.

The `/knowledge/article/<id>` route uses the ORM to retrieve the article by its ID. Since trashed articles are inactive, the ORM does not return the article, leading the route to assume the article does not exist and redirect the user to a 403 error page.

To resolve this issue, we will modify the context of the search method to include the key `active_test=False`. This will allow the ORM to return inactive (trashed) articles. As a result, users who follow the link from the email will be correctly redirected to the trashed article page, where they can view its content and choose to restore it using the banner interface.

Task-4636494

Forward-Port-Of: odoo/enterprise#86065

The `action_timer_start` method caused infinite recursion when the user's timezone differed from the timesheet's timezone. The comparison between `fields.Date.today()` and `self.date` failed, creating a new timesheet.  That new timesheet triggered `action_timer_start` again, repeating the loop. 

**Steps to Produce:-**
1. Install the `Timesheets` application.
2. Navigate to `Settings > Users & Companies > User`.
3. Select your current user and, under `Preferences`, set the timezone to one that does not reflect today’s date.
4. Open the Timesheets application, and for any record, click on the `Search icon` in the column for today’s date.
5. Start the time tracking by clicking the `Play button`.
6. Wait for a moment; an error will generate.

**Error:-**
`RecursionError: maximum recursion depth exceeded.`

**Solution:-**
   - When action_timer_start() is invoked, it first checks for the _from_action_timer flag in the context.
   - If not set, it sets _from_action_timer=True.
   - The next time action_timer_start() is triggered, the presence of _from_action_timer in the context causes it to exit early, 
     preventing recursion.

**Sentry - 6592348827**

Forward-Port-Of: odoo/enterprise#85105

Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code.

**Steps to Reproduce:**
1) Install `l10n_ar_edi module`.
2) Select Company having Argentina code (e.g **(AR)Exento**) 
3) Navigate to `Invoicing->Configuration->settings`, under Argentina localization,
   set `Verify Vendor Bills validity in AFIP` to **required**.
4) Create a new Vendor Bill, select Vendor Name (e.g **ADHOC SA**).
5) Click on confirm.

**Error:**
UserError('Please set AFIP Authorization Mode and Code to continue!')

**Root Cause:**
- The code  calls `_logger.error(repr(error))` on any exception at [1] during the AFIP verification attempt, causing an ERROR‐level log entry.

[1]- https://github.com/odoo/enterprise/blob/ca16c89c6f53b1c0adb0a1a061d985bdf3439e5e/l10n_ar_edi/models/account_move.py#L500

**Solution:**
- This commit handles `UserError` exceptions separately using a warning log to prevent error-level entries.

Sentry-6576006813

Forward-Port-Of: odoo/enterprise#85261

Currently, an error occurs when updating data for payroll if a referenced partner record has been deleted by the user.

**Steps to produce:**
- Install the `contacts` and `l10n_ma_hr_payroll` module.
- Delete the partner **National Social Security Fund**.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.

**Error:**
`ValueError: ParseError('while parsing /home/odoo/src/enterprise/saas-18.3/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml:169 ...`

The error occurs because the method at [1] tries to load the `hr_salary_rule_data.xml` file, which references a deleted `partner_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/models/hr_payslip.py#L9
[2] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml#L169

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6617089492

Forward-Port-Of: odoo/enterprise#85979

When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
  Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button

Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
    return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```

https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.

sentry-6620429585

Forward-Port-Of: odoo/enterprise#86098