**Steps to reproduce:**
* Install the **l10n_ch** module for a Swiss company.
* Create a vendor bill for a **foreign vendor**.
* Apply a reverse charge tax:
  * **8.1% R C** (figure **383a**), or
  * **7.7% R C** (figure **382a**).
* Confirm the vendor bill.
* Go to **Accounting → Reporting → Tax Report**.
* Generate the VAT report for the relevant period.

**Observed behavior:**
* Figure **383a** (8.1% reverse charge) is reported as **negative**.
* Figure **382a** (7.7% reverse charge) is reported as **negative**.
* This results in incorrect VAT reporting.

**Cause:**
* Reverse charge taxes use **negative tax rates** to model the reverse mechanism.
* The base amounts were tagged with **positive** signs, leading to negative values in the report.

**Fix:**
* Invert the base tax tag signs for reverse charge taxes:
  * **382a**: change base tag from `-382a` to `+382a`.
  * **383a**: change base tag from `-383a` to `+383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445

Forward-Port-Of: odoo/odoo#244934
Forward-Port-Of: odoo/odoo#244452

Handle `carryover_origin_report_line_id` for report line having `code = 'VP14b`, since the line does not exist in the new monthly VAT report after this commit: odoo/odoo@51a72ab42d118d6fb0eb3e3545a09e10019b9140

As the line is not present in the monthy vat report while mapping it will raise keyerror:

```py
File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 52, in migrate
    data_to_insert = [
  File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 53, in <listcomp>
    (code2expression_id[report_line_code], old2new_origin[carryover_origin_report_line_id], *other_external_vals)
KeyError: 80
```

```sql
apan_3806634=> select id,carryover_origin_report_line_id,target_report_expression_id from account_report_external_value;
 id | carryover_origin_report_line_id | target_report_expression_id
----+---------------------------------+-----------------------------
  3 |                              80 |                         102
  4 |                              80 |                         105
  7 |                              80 |                         102
  8 |                              80 |                         102
  9 |                              80 |                         102
 10 |                              80 |                         102
 11 |                              80 |                         102
(7 rows)

apan_3806634=> select id,name->>'en_US',code from account_report_line where id=80;
 id |           ?column?           | code
----+------------------------------+-------
 80 | VP14b - VAT payable (credit) | VP14b
(1 row)
```

Note this error will only appears in the dbs without this commit: odoo/odoo@a220a28595dbfacce2d8322222d1961547bb4b07

opw-5494959
upg-3806634
tbg-2272


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

Forward-Port-Of: odoo/odoo#244685

### Issue:
The `hb-row-label` class shows inconsistent behavior in the builder
sidebar. The 'Option List' label appears centered rather than following
the standard alignment. In addition, the alignment of nested options
within the builder sidebar is marginally misaligned.

### Steps to Reproduce:
- Open the website and switch to edit mode.
- Drop a Form snippet onto the page.
- Add a new field and set its type to 'Multiple Checkbox'.
- In the builder sidebar, notice that the 'Option List' label is
  centered.

### Reason:
This [commit](https://github.com/odoo/odoo/commit/2c90e135a30b5810be0e2796154d85a918fbe303) changed the `align-self` property of the `hb-row-label`
class from `baseline` to `center`. That change was intended to fix
alignment issues for nested options inside popovers. However, since
`hb-row-label` is also used globally, this caused misalignment in the
builder sidebar.

### Fix:
Apply a separate alignment rule for popover usage while keeping the
default `hb-row-label` alignment set to baseline. This restores the
correct label positioning in the builder sidebar (refer img 1) and
preserves the improved alignment inside popover (refer img 2).

### Visual Changes:
<img width="1866" height="622" alt="image" src="https://github.com/user-attachments/assets/b243fbf3-2f7f-4942-b1e4-7de7c5eafe0f" />

<img width="1843" height="688" alt="image" src="https://github.com/user-attachments/assets/562dfc33-43f9-45cd-b3ce-efec32e3cf45" />

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

Forward-Port-Of: odoo/odoo#242756

Currently, an error occurs when exporting an accounting report to 
PDF if any of the selected contacts do not have a name.

**Steps to reproduce:**
- Install the `account_reports` and `contacts` modules.
- Go to Contacts and open any contact (e.g., Azure Interior).
- Click `Add` > `Save & Close`, then `save` the contact.
- Navigate to Accounting > Reporting > Aged Receivable.
- Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`).
- Click `PDF` to export the report.

**Error:**
`TypeError: sequence item 0: expected str instance, bool found`

**Root Cause:**
At [1], `options['selected_partner_ids']` is built using `partner.name`, which may 
be `False` for unnamed contacts. At [2], the `partner_value` list may therefore 
contain `False` entries coming from `options['selected_partner_ids']`. When 
calling `', '.join(partner_value)`, an error is raised because the list contains 
`non-string` (`bool`) values.

**Fix:**
This commit prevents errors when exporting reports to PDF and ensures 
that partner names are displayed in the report the same way as in the 
partner selection widget.

[1]:
https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745

[2]:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93

opw-5467321

Forward-Port-Of: odoo/enterprise#105025
Forward-Port-Of: odoo/enterprise#103828

Issue before this commit:
=========================

When creating a maintenance request from a work order in the Shop Floor module, a traceback was raised.

Steps to Reproduce:
=========================
- Install the mrp_maintenance module.
- Create a Manufacturing Order with at least one operation.
- Open the Shop Floor module.
- From a work order, click on the three-dot (extra) menu.
- Click on Request Maintenance.
- A traceback occurs: ValueError: External ID not found in the system: mrp_maintenance.maintenance_request_view_form_inherit_mrp_workorder

Cause of the issue:
=========================
The above XML ID was previously used to add a custom JS widget that displays a notification when creating a maintenance request from the Shop Floor.

During a recent refactoring in this [PR](https://github.com/odoo/enterprise/pull/100326), this XML record was removed (while the notification functionality remained intact). However, the Python code was still referencing this XML ID, which has now been reintroduced in this [PR](https://github.com/odoo/enterprise/pull/100348), and this mismatch resulted in the traceback.

With This Commit:
=========================
Ensure that creating a maintenance request from the Shop Floor no longer raises a missing external ID error, while keeping the expected behaviour unchanged.

***Behavior:***
In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route,
and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components.

When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount.

***Steps to reproduce:***
- Create a second warehouse.
- Check Resuply From 'First Warehouse' (this will unarchive a route)
- Create a product that uses that route for reordering.
- Create a second product
- Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1
- In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route.
- Add any amount to reorder in 'Replenishment' then click the Order button.
- If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount.

opw-5351460

Forward-Port-Of: odoo/enterprise#101462

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

Forward-Port-Of: odoo/enterprise#104914
Forward-Port-Of: odoo/enterprise#103944

Steps to reproduce:
- Activate the GS1 nomenclature
- Create a product with barcode: 15099590483921
- Scan the product from the Barcode app main menu

Problem:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined
rules.
For example, a GS1 product barcode should start with the Application
Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first
matching rule. In this case, the barcode 15099590483921 is interpreted
as a date because it starts with "15", which corresponds to a GS1
Application Identifier for a date. As a result, the parser attempts to
convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in main_menu
and explicitly reset parsed_results to False, allowing the normal main
menu resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product, picking, or
location detection still works as expected.

opw-5357611

Forward-Port-Of: odoo/enterprise#104832
Forward-Port-Of: odoo/enterprise#104641

When a preparation printer is configured to print only specific product categories (e.g., drinks only), adding items from other categories (e.g., food) would cause the printer to reprint the previous order with a "NEW (DUPLICATE!)" label.

Steps to reproduce:
-------------------
* Configure a restaurant/bar POS with a preparation printer set to print only drinks
* On a table, order a drink item → printer correctly prints "NEW" ticket with the drink
* On the same table, add a food item (not in printer categories)
* Trigger sending to preparation (e.g., validate order or send to kitchen)

> Observation: The printer prints a duplicate of the previous drink order showing "NEW (DUPLICATE!)" instead of staying silent.

Why the fix:
------------
The `sendOrderInPreparation` method was automatically reusing `order.uiState.lastPrint` when no preparation category changes were detected, causing an implicit reprint. This behavior is incorrect when the order only contains items outside preparation printer categories - the printer should simply not print anything.

The fix:
- Prevents automatic reprint when there are no prep category changes
- Still calls `updateLastOrderChange()` to mark the order as "sent" and prevent the restaurant popup warning about unsent orders
- Only allows explicit reprints via `opts.explicitReprint` flag for future use cases

Forward-Port-Of: odoo/odoo#244756
Forward-Port-Of: odoo/odoo#239003

It is possible to run a cron via the "Run Manually" button of the ir.cron form view. In 18.4 and before, in case the cron failed due to an exception, that exception would appear in the web client. Since 19.0 and commit 78c00d2, the exception no longer bubbles-up to the web client. It is only logged in the server logs.

Many system admins and also the Odoo support use on the "Run Manually" to quickly test a cron and make sure it works. The change done in 19.0 is considered as a nasty surprise. They want their exceptions back!

When running a cron manually, we now track the logs that are emitted on the cron logger and search for an error with an exception. May we find one, we raise it with a proper traceback chain, which bubbles up to the web client and is shown in the "An error occured" modal.

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

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

Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time.

Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events.

**Current behavior before PR:**

Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer:
	•	the synchronization fails,
	•	and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo.

**Desired behavior after PR is merged:**

The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`.

If the parameter is not set, the behavior remains unchanged (default 3 seconds).
Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs.


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

Forward-Port-Of: odoo/odoo#245022
Forward-Port-Of: odoo/odoo#241921

Modules containing valid Markdown in their description or README.md could cause Odoo to crash during startup or module updates if the content confused the reStructuredText (RST) parser.

### Steps to reproduce

1. Create a module with a manifest like this:

    ```py
    {
        'name': 'base',
        'description': """
        ....
    """,
    }
    ```

2. Start the Odoo server or attempt to install or update update the module.
3. The server crashes:

    ```
    docutils.utils.SystemMessage: (SEVERE/4) Unexpected section title or transition.
    ```

### Cause

The crash occurs during the execution of the `_get_desc` method in the `ir.module.module` model, which computes the `description_html` field.

When Odoo processes a module, it checks for a pre-rendered HTML description at `static/description/index.html`. If this file is missing, the `_get_desc` method attempts to generate HTML from the module's `description` field (often populated from the `README.md` file) by calling the `docutils.core.publish_string` function.

The **docutils** library is designed specifically for **reStructuredText (RST)**. If the input text contains structural patterns that violate RST rules—such as inconsistent header levels or "transitions" in invalid contexts—docutils flags a severe error and raises a `docutils.utils.SystemMessage` exception.

### Fix

This commit handles these exceptions and falls back to a raw text rendering. It also improves the logic by removing the restriction that prevented non-application modules from rendering their description via RST.

opw-5424131

Forward-Port-Of: odoo/odoo#243517

Scenario:

- Setup Unsplash and install website
- Set a user as "Website: Editor and Designer"
- Login as that user and go to any website page with a qweb view
- Go to edit mode and drop Text-Image in a view
- Replace the image with an unsplash image and then save

Result: the save fails without any message shown, and there is a
security access WARNING in the logs.

Note: a similar scenario can be done for a restricted editor that is
editing a HTML field it has write access to.

Issue: to save a model with res_id 0, we need to either be admin
(base.group_system) or the record creator. Since
9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype
neutering of happening, we create the attachment as SUPERUSER.

Then when we modify the attachment url (for unsplash images), we have no
access right to the attachment since we are not the creator.

Fix: create the attachment with the current user, and only use
SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't
have write access right to ir.ui.view, which in normal use case should
only happen for "Restricted Editor"). This way the image is created by
the user that uploaded it and not SUPERUSER.

opw-4850611
opw-5387258
opw-5489219

Forward-Port-Of: odoo/odoo#245085
Forward-Port-Of: odoo/odoo#219472