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

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

### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes)

This commit cleans up several utility files relating to string-parsing
and translations. Main changes are:

- fixed `sprintf` and related functions: before this commmit, string
substitutions were incorrectly inserted in the template string, and it
was actually reflected in a test (template : `"<p>%s</p>%s"` => test
incorrectly asserted that both strings were inserted in the first "%s"
and "undefined" was inserted in the second);

- to replicate the Python homonymous behaviour: "%s" characters can now
be escaped in "sprintf-ed" strings by adding an additional "%" sign
before the expression;

- unification of translations via a TranslatedString class (which will
also simplify external overrides);

- unified API for some utility functions sharing the same purpose
(typically: accepting an iterable instead of a list, etc.);

- filling missing docstring, re-ordering functions and constants for
clarity;

- added "headless" tag to some utility functions' tests, when UI is not
needed.

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

Forward-Port-Of: odoo/odoo#244588
Forward-Port-Of: odoo/odoo#241068

**Steps to reproduce:**
* Install `l10n_co_dian` and `accounting` modules.
* Go to **Accounting → Configuration → Settings** and enable DIAN demo mode under `Colombian Electronic Invoicing` by disabling `test mode`.
* Create an Invoice.
* Select a Colombian customer and add products.
* Fill in the **Terms and Conditions** field (e.g., “Payment due in 30 days”).
* Confirm the invoice and generate the electronic invoice XML.

**Observed behavior:**
* The `<cbc:Note>` tag only contains **CUFE calculation data**.
* The **Terms and Conditions** text is missing from the XML.

**Cause:**
* The `'cbc:Note': None` ovrride the value of Note tag which has value of
  invoice.narration. 
ref : https://github.com/odoo/enterprise/pull/87598/changes#diff-2548895191bf05af735ebfc332b3f3f2db9d039630101720ee72feb7b65fa8fcR532

**Fix:**
* removed the `'cbc:Note': None` which overrides the value of the note tag.

opw-5488663

Forward-Port-Of: odoo/enterprise#105093
Forward-Port-Of: odoo/enterprise#104559

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.

Forward-Port-Of: odoo/enterprise#105030

**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#245134
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#245222
Forward-Port-Of: odoo/odoo#243517

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

The high-priority maintenance request count (todo_request_count_high_priority) 
was not calculated correctly.

Steps to Reproduce:
=========================
- Install the maintenance module.
- Create a maintenance request and set the Priority to High (3-starred) in the form view.
- Open the dashboard.
- Observe that the high-priority request count is not displayed.
- The count always remains 0, even when high-priority requests exist.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. 
The priority field is defined as a Selection field, but while computing the count, the comparison 
was done against an integer(3, not '3') instead of the actual string value. Since the stored 
value is '3' (string), the condition is always evaluated to False, resulting in a count of 0.

With This Commit:
=========================
Ensure that high-priority maintenance requests are correctly counted and displayed on 
the dashboard when they exist. This provides better visibility of critical requests and
helps users prioritise maintenance work effectively.

Forward-Port-Of: odoo/odoo#244987

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#245116
Forward-Port-Of: odoo/odoo#243623

**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard

1) - On "Bank" journal card, select "Import File" option in dropdown menu
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button
2) - Open "Bank" journal
    - Select "Import records" in the cog menu
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button
3) - Open "Bank" journal
    - Click on "Upload" button
    - Upload a file containing a lot of statements (e.g. more than 170)
    - Test the import with "Test" button

**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.

**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.

**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).

opw-5436937

Forward-Port-Of: odoo/enterprise#104954

### Issue:
When having a template with a company but no department, it's not selected by new appraisal.

### Steps to reproduce:
- Have an employee whose appraisal date is today.
- Have only one template, with the company of the employee but no department
- Run the cron "Appraisal: Run employee appraisal"
- Open the Appraisals app
- Click on the newly created appraisal
- It doesn't have the template

### Cause:
- In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template.
But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal.
So `appraisal.department_id` is `False` and the template from the department is ignored. 

- Another issue is if the employee has no department, then the appraisal also has no department.
Then no template is selected by the search domain. 

### Solution:
- Include `department_id` in `appraisal_values`
- Modify the search domain to include the case where the appraisal has no department

opw-5477450

Forward-Port-Of: odoo/enterprise#104470

In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation.

Steps to reproduce:
- activate Ukrainian (or Polish) language
- Preview (i.e. the website view) of any appointment
- Change the preview into Ukrainian (or Polish)

Expected result:
Calendar month at top of calendar is shown in the nominative case:
e.g. January 2026 = січень 2026 (in Ukrainian)

Actual result:
Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January):
e.g. January 2026 = січня 2026 (in Ukrainian)

Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month

Note that for most languages this won't make a difference since there is usually only 1 way of writing a month.

opw-5474705

picture diff (for January 2026):

before fix:
<img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" />


after fix:
<img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" />

Forward-Port-Of: odoo/enterprise#104942

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#245121
Forward-Port-Of: odoo/odoo#239003

Issue Before This Commit:
================================
Previously, the delivery carrier was only propagated between pickings when it
was set from the sale order. If the carrier was manually set on a picking
(e.g., during the packing step in a multi-step delivery flow), it was not
propagated to the consequent pickings, even when the stock rules had
`Propagation of carrier` enabled.

Steps to reproduce:
================================
1. Activate Multi-Step Routes and Delivery Methods.
2. Configure a 3-step delivery route in the warehouse and enable Propagate
   Carrier on all rules.
3. Create a sale order with a product but without setting a delivery carrier.
4. Confirm the sale order to generate picking.
5. On the first picking (i.e., pick), manually set a delivery carrier
   (e.g., Local Delivery) and validate.
6. On the next transfer (i.e., pack), observe that the delivery carrier is not
   propagated.

After this commit:
================================
The delivery carrier set on any picking is propagated to subsequent transfers
when the corresponding stock rule has `Propagation of carrier` enabled and no
carrier is already configured on the next picking.

This ensures consistent carrier propagation across all routing configurations
(all pull rules, all push rules, and mixed push/pull flows), even when the
carrier is configured at the picking level rather than on the sale order.
This behavior is required because, in many business scenarios, carrier selection
is managed by the logistics team rather than the sales team.

task-4454313

Forward-Port-Of: odoo/odoo#243597
Forward-Port-Of: odoo/odoo#202700

Steps to reproduce:
===================
1. Enable the Cookies Bar in website settings.
2. Go to the website and enter Edit mode.
3. Select the Cookie Bar and change the button "I agree" style shape to "Default"  (this applies the `.btn-primary` class). & Save
4. Accept the cookies & refresh

-> The cookie bar appears again because the consent was not saved.

Cause:
======
The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup.

By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written.

Solution:
=========
Override the event to avoid side effects on hide.

opw-5484578

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

Forward-Port-Of: odoo/odoo#244875
Forward-Port-Of: odoo/odoo#243562

Currently, an exception is generated when the user tries to select
`Auto-Complete` without selecting `Vendor`.

Steps to produce an error
- Go to Invoicing > Vendors > Bills > Click New
- Try selecting `Auto-Complete` >>> Error occurs

Error `AssertionError: Invalid falsy real id`

This error occurs because, after the recent refactoring in commit [1], falsy
ids are no longer allowed in domains. In the `Account Entry` view
`[partner_id]` (see [2]) is passed as part of the domain. When the user has
not selected a vendor (partner_id) it evaluates to False, which results in
[False] being passed and triggers the error introduced by commit [1].

This commit will fix the above issue by hiding the `Auto-Complete`
field when `Vendor` is not selected.

[1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f
[2]: https://github.com/odoo/odoo/blob/7b288aa436f669d8c8e2ddac5277bb98321a390e/addons/account/views/account_move_views.xml#L1067

Sentry-7201563878

Forward-Port-Of: odoo/odoo#244729

On the iot box we check the number of printers connected rarely to avoid spamming the network.
This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface.
The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box.

However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds.
Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects.
The user in pos can then press "retry" which will lead to a double printing.


This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups.
Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed.
The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected

Forward-Port-Of: odoo/odoo#244759
Forward-Port-Of: odoo/odoo#244076