Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids.

This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings.

Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the
`purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s).

Benchmarks:

| No. move lines in delivery | Before  | After |
| -------------------------- | ------- | ----- |
| 7579                       | Timeout | < 200 s   |

opw-5826905

Forward-Port-Of: odoo/enterprise#110587
Forward-Port-Of: odoo/enterprise#110153

Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow.

Moreover, the method is ordering on `LOWER(name)` which is not indexed, and another query is done to count the total results, which slows down the process even more.

This PR fixes those issues by:
- Removing the `LOWER` ordering. Ordering in a case sensitive fashion is not that big of a deal anyway.
- Removing the count query, fetching one more partner in the search is enough to know if there are more results, executing the same query twice is overkill.
- Reducing the number of partner returned: currently 30, but there isn't enough space to display them anyway.

task-4526176

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

When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

Forward-Port-Of: odoo/odoo#259975
Forward-Port-Of: odoo/odoo#259267

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Create a non-storable product P
- Go to the barcode app > Operations > Delivery Order > New
- Click on "Add Product" > select P as product > Confirm
#### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there?

### Expected behavior:

Since the product is not storable it should not trigger the dialog

### Cause of the issue:

The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant.

opw-6110655

Forward-Port-Of: odoo/enterprise#114173

Steps to reproduce:
====================
1. Install Arabic and set it as a website language
2. Log in as a user whose UI language is English
3. Edit a page / article in Arabic and type some text

=> Text rendered left-to-right in the editor

Cause:
=======
this was introduced after this change [1]
When editing a website/article in a language whose direction differs from the logged-in user's UI language, text entered in the builder appeared in the wrong direction (e.g. writing in Arabic showed the caret/text aligned to the left instead of the right). Saving reverted the content to the correct direction, but the authoring experience was broken.

The builder was initializing the editor's `direction` config from `localization.direction`, i.e. the *user's* UI locale, instead of the direction of the document being edited. As a result, an LTR admin editing an RTL site (or the reverse) got an editable whose `dir` attribute did not match the site.

Solution:
=========
Use the editable itself as the source of truth: if it carries the `.o_rtl` class (already used to set `isEditableRTL`), set `direction = "rtl"`, otherwise `"ltr"`.

=> Text now renders right-to-left, matching the site

[1]:https://github.com/odoo/odoo/pull/256045/changes/0490b2229dba7e0cb4a58e5cf4d68772e5640697

opw-6109987

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

Forward-Port-Of: odoo/odoo#259541

When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

Forward-Port-Of: odoo/odoo#259975
Forward-Port-Of: odoo/odoo#259267

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Create a non-storable product P
- Go to the barcode app > Operations > Delivery Order > New
- Click on "Add Product" > select P as product > Confirm
#### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there?

### Expected behavior:

Since the product is not storable it should not trigger the dialog

### Cause of the issue:

The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant.

opw-6110655

Forward-Port-Of: odoo/enterprise#114173

Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids.

This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings.

Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the
`purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s).

Benchmarks:

| No. move lines in delivery | Before  | After |
| -------------------------- | ------- | ----- |
| 7579                       | Timeout | < 200 s   |

opw-5826905

Forward-Port-Of: odoo/enterprise#110587
Forward-Port-Of: odoo/enterprise#110153

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids.

This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings.

Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the
`purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s).

Benchmarks:

| No. move lines in delivery | Before  | After |
| -------------------------- | ------- | ----- |
| 7579                       | Timeout | < 200 s   |

opw-5826905

Forward-Port-Of: odoo/enterprise#110587
Forward-Port-Of: odoo/enterprise#110153

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

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#260099
Forward-Port-Of: odoo/odoo#256357

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

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

Backport of: https://github.com/odoo/odoo/pull/258938

Forward-Port-Of: odoo/odoo#259717
Forward-Port-Of: odoo/odoo#259585

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/enterprise#112837

Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids.

This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings.

Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the
`purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s).

Benchmarks:

| No. move lines in delivery | Before  | After |
| -------------------------- | ------- | ----- |
| 7579                       | Timeout | < 200 s   |

opw-5826905

Forward-Port-Of: odoo/enterprise#110587
Forward-Port-Of: odoo/enterprise#110153

purpose: Since 2024, if you are unable to take a paid time off (your legal rights to time off), you can have them back for next year.

- added fields for postponed paid time off in the paid time off allocation wizard and allowed to generate them along with the main time off type
- made postponed paid time off types unpaid in all belgian salary structures
- added postponed paid time off (N-1, N-2) to the salary inputs in the holiday attest and added coresponding values in the report
- made `alloc_employee_ids` stored in the paid time off allocation wizard so the values of time off to allocate and to postpone presist when changed.
- added fields for postponed paid time off (N-1, N-2) to the holiday attests tab to be changed manually for new employees when they sign a new contract
- moved the paid time off wizard to be accessible from the payrun of december (and made the reference period readonly that takes it's value from the year of the current payrun)
- made the paid time off wizard consider allocations already existing and not fully create them again
- added a salary rule to pay the allocated postponed N-1 time off in the december payslip

task-id: 5429948

This commit adds support for generating SAT (Mexican tax authority) trial balance reports in supplementary (complementary) format, as required by SAT specifications.

Changes:
- Add default value for submit_type in SAT XML generation to fix tests that call the method directly without going through the wizard
- Add new tests for normal (TipoEnvio=N) and supplementary (TipoEnvio=C) formats
- Verify that FechaModBal attribute is correctly included only for supplementary reports
- Verify that filenames correctly use BN (normal) or BC (complementary) suffixes

The SAT technical specification requires:
- TipoEnvio="C" (complementary) for supplementary balance sheets
- FechaModBal attribute (date of last accounting modification) when tipo is C
- File naming convention: RFC+Year+Month+BN (normal) or BC (complementary)

SAT technical specification:
https://wwwmat.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173762094&ssbinary=true

In reference of PR https://github.com/odoo/enterprise/pull/111775
Ticket : https://www.odoo.com/es_ES/my/tasks/6025590

@mial-odoo @fmvt-odoo 

@moduon MT-14181

Steps to Reproduce
---
- Define an aw.rule with a project set without a task (false)
- The rule regex matches a desktop app event (e.g. Discord window)
- Open the Timesheets Assistant for the current day

Current Behavior
---
- The matched event has _res_model set to "project.task" and _res_id set to undefined, despite no task being configured on the rule
- The suggestion appears as "Unmatched" in the assistant even though a project was correctly defined on the rule

Expected Behavior
---
- The matched event should have _res_model set to "project.project" and _res_id set to the rule's project_id
- The suggestion should appear under the configured project

Issue
---
- In extractWatcherActivity(), both project_id and task_id blocks used != null as the guard condition
- When task_id is false, false[0] is undefined, overwriting the correctly set _res_model i.e. "project.project" and _res_id from the project_id block with "project.task" and undefined _res_id

Fix
---
- Replace with a truthy check

task - 6089410

Forward-Port-Of: odoo/enterprise#114172

- The renderAndSaveMedia function was only a wrapper around 2 function calls renderMedia and saveFunction which made it not very useful. So, renderAndSaveMedia function is removed and renderMedia and saveFunction are used directly.

- In the original image generation PR, a closeParams dict was introduced to store the closeReason of the MediaDialog such as "save", "discard" or "ai" and the id of the ai chat channel opened from the MediaDialog if any. This was mainly introduced to handle the following case:
  1. Go to the website.
  2. Insert an 'Image' snippet from the 'Inner Content' section.
  3. Click on the AI button from the media dialog.
  4. The media dialog will be closed and the snippet placeholder will be removed. Clicking on 'UseThis' button under AI generated images will do nothing because the snippet placeholder was removed.

Extra logic was introduced when the closeReason is "ai" to keep the snippet placeholder. However, this complicated the close logic because the logic needs to take into account the newly introduced "ai" state in addition to the other 2 states of "save" and "discard". This commit removes the closeParams dict and introduces aiBeforeCloseHandler logic that will replace the snippet placeholder by a dummy image before closing the media dialog and which can then be replaced by the AI.

See also:

Community PR: https://github.com/odoo/odoo/pull/259148

Image generation original commits:
- Enterprise commit 99f76c1c
- Community commit 63c0b17e

Image generation original PRs:
- Enterprise https://github.com/odoo/enterprise/pull/104712
- Community https://github.com/odoo/odoo/pull/244419

**Steps To Reproduce**
- Go to Documents app
- Upload a Peppol XML file containing an embedded PDF (e.g., invoice with attached PDF)
- Open the document

**Issue**
Opening a Peppol XML document with an embedded PDF causes: `UserError: Only PDF files can have a thumbnail`

The kanban view also shows raw XML code instead of the PDF preview.

**Cause**
Since this commit:
https://github.com/odoo/odoo/commit/37e38b8cd34e

The mail module's `mail_attachement_update_thumbnail` route has a strict mimetype check that rejects thumbnail updates for XML files:

https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L146-L147

Additionally, the documents thumbnail service only generates thumbnails for files where `isPdf()` returns true:

https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L27-L35

**Solution**
Add `_allow_thumbnail()` hook to allow overriding the mimetype check

And from this PR, I see that a proper thumbnail is the proper behavior:
https://github.com/odoo/enterprise/pull/49111

Which required the thumbnail generation flow multiple overrides:
1. **`isPdf()` check**: The documents thumbnail service only generates thumbnails for files where `isPdf()` returns true. XML files return false, so thumbnail generation is never triggered: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/static/src/views/helper/documents_client_thumbnail_service.js#L28-L35

2. **`pdf_first_page`**: When thumbnail generation runs, it fetches the first page of the PDF via these routes. For XML with embedded PDFs, the routes must extract and return the embedded PDF bytes instead of the raw XML content: https://github.com/odoo/odoo/blob/c350592b85001b5f36ea6aaf803ee3974e5ebfc1/addons/mail/controllers/attachment.py#L120-L127 https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/controllers/documents.py#L515-L528

3. **`isTextualDocument` in kanban**: XML files are treated as textual documents and displayed showing raw XML code, even when they contain an embedded PDF that should be previewed instead: https://github.com/odoo/enterprise/blob/60881b65991cbd2594492b25900ab4bb8c166250/documents/views/documents_document_views.xml#L106

opw-5252946

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

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

on a MO when we have a component tracked by lot and reservation methode set as manual, when we start an operation, the component is automatically reserved.

**Steps to reproduce**
* Set Manufacturing operation type reservation methode to "Manually"
* Create a bom with a component tracked by "lot"
* Add an operation to this bom
* Create an MO with this bom and confirm it
* Start the operation
-> the component get reserved.

**Observation**
When starting the operation it will call button_start, where we will set the ```qty_producing```:
https://github.com/odoo/odoo/blob/6aa9147eef3212b5a4ebf374e617caba198ad7b5/addons/mrp/models/mrp_workorder.py#L617-L618
When setting ```qty_producing```, we will write it and from the inverse, it will call ```_set_qty_producing``` to synchronizes the value of the linked mo.
https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/models/mrp_workorder.py#L52-L53
https://github.com/odoo/odoo/blob/6aa9147eef3212b5a4ebf374e617caba198ad7b5/addons/mrp/models/mrp_workorder.py#L237-L238
In the ```_set_qty_producing``` in the mo, the system assumes that because production has started, the linked stock moves must be updated to reflect consumption:
https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/mrp/models/mrp_production.py#L1338-L1346
When these stock moves are updated, the stock.move logic prepares values by reserving available quants and generating new move lines:
https://github.com/odoo/odoo/blob/67df9b5cf4bc277c17b49ef70782a76f5ca6d760/addons/stock/models/stock_move.py#L2328-L2331
https://github.com/odoo/odoo/blob/67df9b5cf4bc277c17b49ef70782a76f5ca6d760/addons/stock/models/stock_move.py#L2337

opw-5938176

## Issue
In the Sign app, the list of tags of a template can overlap with the *Template Properties* button when using a language that makes those components slightly wider than expected (e.g. German).

## Steps to reproduce
1. Install Sign (`sign`)
2. Set the language to German
3. Open a template
4. **In the header, the list of tags overlap the _Template Properties_ button**

## Cause
The list of tags uses `col-lg-12`, which is design for Bootstrap's grid system and prevents the div from shrinking properly.

```css
.col-lg-12 {
    flex: 0 0 auto;  /* flex-shrink set to 0 */
    width: 100%;
}
```

## Before
<img width="726" height="67" alt="6023834-1" src="https://github.com/user-attachments/assets/fd49c8d5-4ca0-4de4-8f0c-f03f78f4b7ab" />

<img width="432" height="75" alt="6023834-2" src="https://github.com/user-attachments/assets/d595e8a3-c3ab-4ae2-89dd-652371de9604" />

## After

https://github.com/user-attachments/assets/3a00fc5f-260d-465d-8e12-96d8e6e1aa4c

opw-6023834

Forward-Port-Of: odoo/enterprise#113116

Issue
-----
When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages.

Steps to reproduce
-----
- Enable packages
- Create a product with one package in stock
- Operation Types > Delivery Orders, set Move Entire Packages to true
- Create a delivery for a package
- Scan the package barcode
- Exit the delivery
- Re-enter the delivery

> Quantity for the line is 1/false

Cause
-----
The line is picked, so it is considered as not reserved

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289

when doing

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813

This leads to `qtyDemand` returning false instead of 1

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18

-----
Ticket:
opw-5960629

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

Related Enterprise PR: https://github.com/odoo/enterprise/pull/112857

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070