### 1) Refresh Token & Cron

Intervat API's provide use both access & refresh tokens. As long as
we keep a valid refresh token, we can keep the connection opened by
requesting a new refresh token.

Currently, we force the connection to close after 4 hours, but it's
too short.

This commit goes to the opposite way, and keep the connection opened
as long as the user wants.

As we need to keep a valid refresh token, we add a cron who execute once each 2 days
to fetch new refresh tokens.

Also, to prevent being stuck, add a new button in res settings to
manually close the connection.

### 2) Accounting firm

When submitting vat return to Intervat API, we have 2 situations:
1. The user submit his own declaration
2. An accounting firm submit the declaration for the client

The current implementation works nicely with situation 1, but not 2. The problem is
when starting the authentication proccess, we give Intervat a company number, the current
company number. But when an accounting firm is set on the company, we should use the
VAT number of the firm instead of the current company, as it will be an accountant from
the accounting firm who will submit the return.

So this commit try to find the accounting firm VAT before the current company VAT for
the authentication proccess. Also, add a new settings in Intervat settings to change the
accounting firm from there.

### 3) Small fixes

Small fixes done for corner cases, see commits messages.

task-5420287,5500052,5495079

Forward-Port-Of: odoo/enterprise#104572

Previously, the confirmation dialog shown when leaving a livechat session was too generic and did not provide enough context to help agents ensure they were closing the correct conversation. As a result, agents could accidentally leave the wrong chat, especially when the livechat list is reordered due to new incoming messages.

This PR improves the dialog to make the action clearer and safer:
- Displays the visitor’s name in the confirmation title.
- Shows the most recent message from the conversation in the dialog body.
- Helps agents verify they are leaving the intended conversation.

task-5355106

Before this PR: 
<img width="593" height="138" alt="image" src="https://github.com/user-attachments/assets/363eeab9-0306-47cc-8f4f-4035862f7e29" />

After this PR:
<img width="1135" height="277" alt="image" src="https://github.com/user-attachments/assets/6a7b7aea-d3bf-4b52-be39-001448ba7afc" />

Before vs After (Chat Window)
<table> <tr> <td> <img width="256" height="422" src="https://github.com/user-attachments/assets/b895b831-e11d-4aee-8f35-cd79f5c77aaf" /> </td> <td> <img width="256" height="422" src="https://github.com/user-attachments/assets/d31c061d-6a6e-42cb-ae60-12a5329cd4d4" /> </td> </tr> </table>


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

Forward-Port-Of: odoo/odoo#238105

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

**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

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

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