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

Here, when we try to open a report that is not linked to view, a traceback appears.

**Steps to reproduce:**
- Install the `stock` and `web_studio` modules.
- Navigate to `Settings > Technical > Actions > Reports`.
- Create a new report (e.g; **Model Name** = product.template, **Template Name** = product.report_test).
- Open the report in the web editor.

**Error:**
`ValueError: External ID not found in the system: studio_customization.studio_report_docume_product_label`

In this case, if no view is defined for the report, the system attempts to retrieve the related view from [1]. However, since the view does not exist, it raises a **ValueError**.

[1] - https://github.com/odoo/odoo/blob/924aa8aa2abe7765d2d605dc7643d1102e056fd6/odoo/addons/base/models/ir_ui_view.py#L2151

This behavior is already handled in **version 16.0** by [2] with a controlled exception. This commit adopts the same approach by raising **UserError** when no view is defined for a report, preventing an unhandled exception.

[2] - https://github.com/odoo/enterprise/blob/511781a6bfb52c88892a54e43133b90ddfddbe22/web_studio/controllers/report.py#L137-L143

Related Community PR: https://github.com/odoo/odoo/pull/208806

Sentry - 5715762959, 6303192517, 6577830303, 6577830303, 6577830303, 6303950186

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

Steps to reproduce:
1. install website, add a link into an editing area in Todo app
2. at the url input, we don't have the internal link suggestion (fuzzy search)
when typing

The PR target to 18.0 because fuzzy page search is considered as a basic
function when website is installed. It's a functional fix for the html_editor

In this PR, we've updated the linkpopover component of the html_editor
to add a fuzzy page search feature to the URL input. Before 18.0, we
created another OWL app to load the page anchors. Here we do it by using
autocomplete component, users can now see and select from a dropdown of
relevant Odoo page anchors as they type in the URL input field.

To achieve this, we modified the popover template to include an
autocomplete field specifically designed for the link popover. In the
AutoCompleteInLinkpopover component, two new props were introduced:

1. inputClass: Allows customization of the input field's styling.
2. updateValue: Enables updating of the link popover's URL state when an
option is selected from the autocomplete dropdown.

We also remove the redundant linkpreview reload when clicking on apply,
cause the loadAsyncLinkPreview is already called at onMounted.

A unit test using hoot is added for testing the fuzzy page search in the
linkpopover.

task-4222657


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

Currently, an error is encountered when clicking on the publish button in the 
profile page in the website view.

**Steps to Reproduce:**
- Install `website_profile` module.
- Navigate to the user's profile page.`(/profile/user/2)`
- Click on the publish button in the editor view.

**Note:**
- The error is generic and could be generated via different website modules as 
  well (e.g, website_forum).

**Error:**
AttributeError: The method `res.users.website_publish_button` does not exist.

**Root Cause:**
- since [1] we are using `website_publish_button` method to publish/unpublish
  records, however, `res.users` model **inherits** the publishing fields from its 
  `res.partner`, but not its related publishing methods

[1]- https://github.com/odoo/odoo/commit/97d00377de0c32e919587a98210679376e27ecc4

**Solution:**
- This commit ensures that the `res.users` model can handle publish/unpublish
  calls by adding the `website_publish_button` method to `res.users`.

sentry-6356507720

Steps to Reproduce:

1. Insert a video using the /video command.
2. Place the cursor on the new line below the video.
3. Press Backspace to delete the video.
4. Press Ctrl + Z to undo the deletion.
5. Observe that the `Type / for commands` hint and the magic buttons appear misaligned on different lines.

Current behavior before PR:

- After undoing video removal, the video block is remounted and at that time powerButtons position updates but iframe loads after that.
- PowerButtons update runs too early when video height is zero, causing misalignment.

Desired behavior after PR is merged:

- Introduce `post_mount_component_handlers` dispatched after each component mount completes.
- PowerButtonsPlugin uses this to update positions after the video and iframe are fully ready.
- Ensures powerButtons and hint paragraph stay correctly aligned after undo restores video.

task-4832484

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

**Issue**
When viewing an invoice in Spanish, the "Outstanding credits" section may overflow or be cut off on the right side.

**Steps to Reproduce**
1. Install the Accounting module.
2. Switch the user language to Spanish.
3. Navigate to Contabilidad > Clientes > Facturas.
4. Open an invoice that has outstanding credits.
5. Set the browser zoom to 125%.
6. Observe that the outstanding credits widget content is truncated or overflows its container.

**Root Cause**
The field `invoice_outstanding_credits_debits_widget` was placed directly in the form without a layout container, causing it to misalign and overflow in cases where translated text or zoom scaling increased its width. The lack of a proper responsive layout prevented it from adapting gracefully.

**Fix**
Wrapped the field inside a `<group>` element with class `oe_subtotal_footer px-4` to ensure it inherits consistent padding and alignment with other form elements. This provides a flexible layout that handles longer text and browser zoom correctly, maintaining readability and visual consistency.

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

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 
However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37
But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Enterprise: https://github.com/odoo/enterprise/pull/86394

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

Forward-Port-Of: odoo/odoo#211616

Currently in MX localization we allow updating existing bills when users upload a CFDI XML [1]
However, we might change the bill source PO with a wrong one in case we have similar records

Steps to reproduce:
- With an MX Company setup
- Create a PO [PO1] with [Partner] and a line and confirm it
- Create an identical PO [PO2], confirm it, receive and create bill (Note: the bill is currently associated with PO2)
- In the bill upload the corresponding xml bill

Issue: After uploading the document, the bill will be associated to PO1

This occurs because in case of CFDI xml bills we process the attachment and update the bill even if some lines already exists. The system tries to find a PO not yet invoiced to associate with the bill, and finds PO1 which is identical to PO2 but not invoiced yet

A solution would be to avoid changing the source purchase order when we want to just extend the bill with an attachment

[1] https://github.com/odoo/odoo/commit/e05457c51e7a03115ba37a196e88a199b7682501

opw-4521106

Forward-Port-Of: odoo/odoo#211252

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

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:**
- Install account_accountant and l10n_es_edi_tbai
- Create 2 companies with 2 different currencies having different rounding factors:
  * a Spanish company with EUR (rounding factor: 0.01)
  * another company with another currency (rounding factor: 1.0)
- For the other company, select "Round Globally" in Accounting settings

- Switch to the Spanish company
- Create an invoice:
  * Customer: [a Spanish customer]
  * Lines: [any with a tax generating a tax amount with a decimal part]
- Save the invoice

- In the company selector, select both companies with the other one as the main one
- Confirm the invoice
- Send it to "TicketBAI (ES)"
- Download the electronic invoice and check it

**Issue:**
In the XML, the value of "CuotaImpuesto" is the tax amount but it has been rounded with the decimal precision of the currency of the main selected company instead of tthe currency of the invoice.

**Cause:**
In "_prepare_invoice_aggregated_taxes" method, "_aggregate_taxes" is called in which some rounding are done using the currency of "self.env.company".
But in this case, "self.env.company" is not the company of the invoice and the currency used for the rounding isn't the one set on the invoice.

opw-4724945




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

Forward-Port-Of: odoo/odoo#211841

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Community: https://github.com/odoo/odoo/pull/211616

opw-4798349

Forward-Port-Of: odoo/enterprise#86394

**Problem:**
When internal transfer operation type has a manadatory destination
in barcode, the transfer can still be validated without destination
location scanned if it's a package

**Steps to reproduce:**
- In settings, enable the "packages" settings
- Navigate to Inventory/Configuration/Warehouse Management/
Operations Types
- Select "Internal Transfers", in the "Barcode App" page for Source
Location, select Mandatory Scan
- for "Destination Location" select "after each product"
- create a new storable product
- Navigate to Inventory/Operations/Physical Inventory
- Create a new line and select stock as the location
- Select your product
- In the package column, create a package and give it a name
- Set a quantity > Apply
- Open the barcode app, select operations and then internal
transfers
- Click on New and then Scan WH-Stock and the package name: PACK

**Current behavior:**
 The validate button is higlighted in green and clickable

**Expected behavior:**
Because we didn't scan a destination location it shouldn't be 
green and clickabel

**Cause of the issue:**

When a package barcode is scanned, when _processBarcode calls
_processPackage 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007
Inside _processPackage 
barcodeData.stopped is set to true (1)
and this.selectedLineVirtualId is set to false (2) 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533
Because of (1) _processBarcode returns here 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011
and doesn't reach the part of the method where _selectLine is called  
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182
(Inside _selectLine the value of selectedLineVirtualId is defined
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274
)

So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is 
false when a package is scanned

When the validate method is called when the user clicks on validate,
the method uses the value of this.selectedLine
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779
Because this.selectedLineVirtualID is false, get selectedLine returns false
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309
So the if condition is false, the method is allowed to run and 
the error notification is not triggered


**Fix:**
After scanning a package there is no selectedLine so we need another
condition


opw-4590345

Forward-Port-Of: odoo/enterprise#83710

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