Fixes a typo in the Romanian electronic invoicing workflow so failed invoice sending is recorded with the correct status. This helps ensure failed submissions are detected and handled consistently instead of being missed due to an invalid status name.

It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D

(for more info see `ciusro_document.py`, the `state` selection field)

task-None

Fixes a document layout issue where invoice titles could wrap onto two lines when using the Bubble template for Indian companies. This keeps printed invoices cleaner and more professional-looking without changing invoice content.

### Steps to reproduce:
- Install "l10n_in" and switch to an Indian company
- Settings > Document Layout > Configure Document Layout and select the "Bubble" layout
- Create a customer invoice and print it
- The title is on two lines

### Cause:
Adding a `t-field` for the journal name seems to break the layout.

### Solution:
Add `text-nowrap` on the layout_document_title to force the display on one line.

opw-4496715

Spanish TicketBAI identification now correctly treats NIE numbers starting with X, Y, or Z as freelancer IDs. This helps avoid misclassifying freelancers as companies when processing Spanish electronic invoicing data.

In order to determine if the vat provided is for an autonomo (freelancer) or a juridical person (company), we checked 8 digits and a letter for the freelancer, but NIEs that start with X/Y/Z are also freelancers, so we added that option in the regex.

opw-4616635

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

Users without Time Off management rights can now search by leave name in the Time Off overview without encountering an access error. This fixes a permission issue that blocked normal overview searches for regular employees.

Before this commit, making a search on name in the overview of the Time Off application without Time Off rights would give an access error.

To reproduce:
- Connect with a user without Time Off rights (Marc Demo for example)
- Go on Time Off > Overview
- Make a search on the name
- An access error is raised while it shouldn't

This commit changes the _search_name method by removing the explicit call to `leave_id` in the domain part not restricted to officers.

This fixes a small typo that could prevent the phone validation fallback from working when the preferred import is unavailable. It helps keep phone number region detection reliable in edge cases without changing normal user workflows.

Before this commit, since the introduction of the
`phone_get_region_data_for_number` function (2d027ad), there was a fallback in case the import failed.

However, the fallback method had an incorrect name.

The barcode app no longer shows the Sign button when working with batch delivery orders, because batch pickings cannot be signed. This prevents users from hitting an error during validation and keeps the workflow clear.

Steps to reproduce the bug:
- Enable “Signature” option in inventory settings
- Go to barcode → delivery orders > batch:
 	- select any batch: - settings: - Operations > sign: - Sign and validate

Problem:
A traceback is triggered:
“ValueError: Invalid field 'signature' on model 'stock.picking.batch'”

Solution:
It is not possible to sign a batch picking, so the button should not displayed.

opw-4610471

The Colombian reports now correctly expand all report lines when users choose the unfold all option. This prevents missing detail in reports and makes it easier for users to review complete Colombian reporting data.

The unfold all options wasn't working correctly in the colombian reports since we added the line, and we only checked if the line was unfolded manually. Now we also check if the unfold all options is activated

opw-4621274

The signing workflow now waits for document pages using the correct page area, preventing an automated HR contract signing check from crashing. This improves reliability for sign-related HR contract processes without changing user-facing functionality.

In this commit, we fix the following error that can occurs in tour hr_contract_salary_tour_hr_sign.

```
AssertionError: The test code "odoo.startTour('hr_contract_salary_tour_
hr_sign', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false,
"startUrl": "/", "delayToCheckUndeterminisms": 0})" failed
UncaughtTypeError: Cannot read properties of null
(reading 'querySelector')
```

During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount. Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201774

During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount.

Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name.




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

Forward-Port-Of: odoo/odoo#201774

Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201591

Previously, the auto_install flag was set on both
account and l10n_fr, preventing proper installation of the fiscal localization package.

Now, the fiscal localization package is correctly
installed when a French company is created and the account module is installed.

opw-4630911


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

Forward-Port-Of: odoo/odoo#201591

## Versions: 16.0+ ## Issue: When changing the website language from the cart page, the product description is not translated while all other elements of the page are. ## Steps to reproduce: Install at least 2 languages available on website; From the shop, add a product (e.g. "Customizable Desk") to cart; Move to the cart and change language. ## Cause: Description is retrieved without being recomputed with selected language. opw-4485686 Forward-Port-Of: odoo/odoo#201250 Forwar

## Versions:
16.0+

## Issue:
When changing the website language from the cart page, the product description is not translated while all other elements of the page are.

## Steps to reproduce:
Install at least 2 languages available on website; From the shop, add a product (e.g. "Customizable Desk") to cart; Move to the cart and change language.

## Cause:
Description is retrieved without being recomputed with selected language.


opw-4485686

Forward-Port-Of: odoo/odoo#201250
Forward-Port-Of: odoo/odoo#198073

Scenario: - create marketing email in 17.0 or above - use the Cover widget - change the cover image to get a base64 endoded image - send the mail Result: no image is sent Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue when parsing the CSS because of having inside a CSS value eg. url("data:image/webp;base64,..."), then when the CSS was modified, the background image would be broken (with a :undefined after the value). Fix: instead of replacing all the style to change t

Scenario:
- create marketing email in 17.0 or above
- use the Cover widget
- change the cover image to get a base64 endoded image
- send the mail

Result: no image is sent

Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue
when parsing the CSS because of having inside a CSS value eg.
url("data:image/webp;base64,..."), then when the CSS was modified, the
background image would be broken (with a :undefined after the value).

Fix: instead of replacing all the style to change the border-style,
update it with regex.

opw-4613524

Forward-Port-Of: odoo/odoo#201685
Forward-Port-Of: odoo/odoo#201394

Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201683 Forward-Port-Of: odoo/odoo#195395

Allow to limit to max failures or errors in odoo test suite
when environment variable ODOO_TEST_MAX_FAILED_TESTS is set.
Above that limit, skip all following tests

ODOO_TEST_MAX_FAILED_TESTS must be a non zero int

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

Forward-Port-Of: odoo/odoo#201683
Forward-Port-Of: odoo/odoo#195395

Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacu

Description of the issue/feature this PR addresses:
After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP.

Current behavior before PR:
Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long.
In particular, many asset files will be regenerated, and old assets immediately become garbage.

Desired behavior after PR is merged:
After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP.
Ideally, it shouldn't be run before old assets are discarded.  So maybe the cron should be triggered after some little delay.

task-3970360

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

Forward-Port-Of: odoo/odoo#197128

As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law. source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/ opw-4531928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201214

As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law.

source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/

opw-4531928


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

Forward-Port-Of: odoo/odoo#201214

### Steps to reproduce: - In the settings enable purchase > dropshipping - Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its password. - Create a product FP tracked by SN, "BOB" as vendor and a bom of type subcontracting: 1 x COMP (tracked by SN), subcontracted by "BOB" - On COMP, check the routes "Buy" and "Dropship Subcontractor on Order" and set a vendor price list. - Create and confirm a purchase order for 2 units of

### Steps to reproduce:

- In the settings enable purchase > dropshipping
- Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its password.
- Create a product FP tracked by SN, "BOB" as vendor and a bom of type subcontracting: 1 x COMP (tracked by SN), subcontracted by "BOB"
- On COMP, check the routes "Buy" and "Dropship Subcontractor on Order" and set a vendor price list.
- Create and confirm a purchase order for 2 units of FP for BOB
- A dropship Purchase Order is created for 2 units of COMP > confirm it
- In the Portal view, as BOB, return to the MO related to FP
- Click on the "burger" icon of the move and try to change the qty_producing or set a SN for the finished product.
#### > you trigger and access right error.

### Cause of the issue:

Changing the qty_producing or the serial number of the finished product triggers a call of the `_set_qty_producting`:
https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L793-L796 During this call, the pickings linked to the MO will be fetchded to determine if the MO is waiting for components to arrive or if the reservation can already be done.
https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L1223-L1224 However, the portal user does not have the access right to read this record and you are not saved by the `Stock Pickings Subcontractor`, `ir.rule` as this is a dropdhip.

### Note:
It was not possible to trigger the issue in 17.0 because prior to: https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L466 The dropshipping picking was not linked to the MO and hence we didn't try to access the values of any record we didn't have access to.

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

Forward-Port-Of: odoo/odoo#198814

Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on an empty recordset returns False. This PR fixes that by first searching on the categories before filtering using the domain --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201542

Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on
an empty recordset returns False.

This PR fixes that by first searching on the categories before filtering using the domain

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

Forward-Port-Of: odoo/odoo#201542

If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset. When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible. task-4643664 Forward-Port-Of: odoo/odoo#201586

If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset.

When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible.

task-4643664

Forward-Port-Of: odoo/odoo#201586

Steps to reproduce: ------------------- - Install 'Project' module - Create a new project - Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default) - Open the Odoo instance in a new incognito browser (or erase cache) - Login and open the created tasks in kanban view Issue: ------ Kanban view is slow to load. Cause: ------ Retrie

Steps to reproduce:
-------------------

- Install 'Project' module
- Create a new project
- Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default)
- Open the Odoo instance in a new incognito browser (or erase cache)
- Login and open the created tasks in kanban view

Issue:
------

Kanban view is slow to load.

Cause:
------

Retrieving the covers in their original quality/size.

Solution:
---------

Hardcode the image height and width in the call of the route so that the retrieved image is cropped/resized.

opw-4438965

Forward-Port-Of: odoo/odoo#199395

**Issue** Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation. **Cause** The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail. **Solution** Ensure the table is empty after uninstall. **Steps

**Issue**
Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation.

**Cause**
The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail.

**Solution**
Ensure the table is empty after uninstall.

**Steps to reproduce**
- Project Kanban View > 3 dots > Share
- Add a recipient and Send: this should add a row to the `project_share_wizard_res_partner_rel` table.
- Uninstall Project shortly after (before the row is deleted by the auto-vacuum).
- Try to re-install Project:
```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Unknown (unknown)
Constraint: project_share_wizard_res_partner_r_project_share_wizard_id_fkey
```

opw-4593125

Forward-Port-Of: odoo/odoo#200984
Forward-Port-Of: odoo/odoo#200555

Add some logic to check the partner fields of models when formatting numbers based on a specific record. This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess. task-4199766 Forward-Port-Of: odoo/odoo#200245 Forward-Port-Of: odoo/odoo#195686

Add some logic to check the partner fields of models when formatting numbers based on a specific record.

This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess.

task-4199766

Forward-Port-Of: odoo/odoo#200245
Forward-Port-Of: odoo/odoo#195686

Before this commit, the field matching of the pivots was changed in place instead of using `this.history`, which caused issues with the undo/redo. Task: 4646822 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#201599

Before this commit, the field matching of the pivots was changed in place instead of using `this.history`, which caused issues with the undo/redo.

Task: 4646822

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

When importing an xml invoice, we display a generic error in case of Exception. This is useful from a technical point of view but this is obscur for the user. With this commit, in case of a UserError, we add the error message in the chatter. Let's assume a wrong configuration and steps like this: - Belgian demo company, `account_peppol` installed and activated - Make sure there are no moves in `Vendor Bills` journal - On the account 600000, set `Allowed Journals` to be any journal different

When importing an xml invoice, we display a generic
error in case of Exception. This is useful from a technical point
of view but this is obscur for the user.
With this commit, in case of a UserError, we add the
error message in the chatter.

Let's assume a wrong configuration and steps like this:

- Belgian demo company, `account_peppol` installed and activated
- Make sure there are no moves in `Vendor Bills` journal
- On the account 600000, set `Allowed Journals` to be any journal
  different from `Vendor Bills`
- From the journal dashboard, vendor bills journal, click on
  `Fetch from peppol`, then go to the bil that has been created
-> In the chatter you will see the error message:
	"Error importing attachment '2_demo_vendor_bill' as invoice (decoder=_import_invoice_ubl_cii)"

This is because we raise the constrains
`account_move_line._check_constrains_account_id_journal_id`, but the
user will never know until we display the UserRrror message in the
chatter.

opw-4513344

Forward-Port-Of: odoo/odoo#201566
Forward-Port-Of: odoo/odoo#200694

To reproduce: - Install delivery_fedex (for example) and sale_management. - Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example). - New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO. Current behaviour: Estimated cost on SO line description is not rounded according to the currency conventions. Expected behaviour: Estimated cost on SO line description is rounded, according to the curre

To reproduce:
- Install delivery_fedex (for example) and sale_management.
- Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example).
- New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO.

Current behaviour:
Estimated cost on SO line description is not rounded according to the currency conventions.

Expected behaviour:
Estimated cost on SO line description is rounded, according to the currency conventions.

opw-4543605

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

Forward-Port-Of: odoo/odoo#201572
Forward-Port-Of: odoo/odoo#201510

This commit fixes a malformed CSS rule (introduced in commit [1]) trying to define the `font-size` of the mentions. In a nutshell, the `rfs()` Bootstrap's mixin has two arguments: - the first is the base size - the second is the property to apply the calculated size to In this case, it generated the following malformed rule: `0.8125rem: 0.8125rem;`. As this rule isn't applied anyway and the visual result is OK, this commit simply removes it. [1]: https://github.com/odoo/odoo/pull/1

This commit fixes a malformed CSS rule (introduced in commit [1]) trying to define the `font-size` of the mentions.

In a nutshell, the `rfs()` Bootstrap's mixin has two arguments:
- the first is the base size
- the second is the property to apply the calculated size to

In this case, it generated the following malformed rule: `0.8125rem: 0.8125rem;`.

As this rule isn't applied anyway and the visual result is OK, this commit simply removes it.

[1]: https://github.com/odoo/odoo/pull/170765

Forward-Port-Of: odoo/odoo#201517

Versions -------- - 16.0+ Steps ----- 1. Have a product with a "No variant" or customer attribute; 2. add product to a sales order. Issue ----- There is a blank line between the product name & attribute descriptor. Cause ----- The `_get_sale_order_line_multiline_description_variants` method returns either an empty string, or a string that starts with 2 newlines. Solution -------- Start with only 1 newline. opw-4585174 Forward-Port-Of: odoo/odoo#201486 Forward-Port-Of:

Versions
--------
- 16.0+

Steps
-----
1. Have a product with a "No variant" or customer attribute;
2. add product to a sales order.

Issue
-----
There is a blank line between the product name & attribute descriptor.

Cause
-----
The `_get_sale_order_line_multiline_description_variants` method returns either an empty string, or a string that starts with 2 newlines.

Solution
--------
Start with only 1 newline.

opw-4585174

Forward-Port-Of: odoo/odoo#201486
Forward-Port-Of: odoo/odoo#201011

…CIG or CUP is present **Issue:** When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete. **Steps to Reproduce:** 1. Install the Accounting app 2. Install the l10n_it_edi module 3. Navigate to Accounting > Customers > Invoices 4. Select or create an invoice 5. Choose a customer with a PA index 6. Open the Electronic Inv

…CIG or CUP is present

**Issue:**
When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete.

**Steps to Reproduce:**
1. Install the Accounting app
2. Install the l10n_it_edi module
3. Navigate to Accounting > Customers > Invoices
4. Select or create an invoice
5. Choose a customer with a PA index
6. Open the Electronic Invoicing tab
7. Fill in either the CIG or CUP field, but leave the Origin Document Type empty
8. Click Send & Print
9. No error is displayed and the e-invoice XML can be sent

Expected Behavior: An error should be triggered, preventing the e-invoice from being sent if the Origin Document Type is missing, even when only one of CIG or CUP is present.

Actual Behavior: The system allows sending the e-invoice despite missing critical information, leading to incomplete data submission.

**Root Cause**

The existing validation only checks if both CIG and CUP are missing, but it does not account for cases where only one is filled while the Origin Document is still absent.

**Fix**
The condition has been updated to trigger an error whenever the Origin Document Type is missing, even if only one of CIG or CUP is present.

Opw-4590205

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

Forward-Port-Of: odoo/odoo#198758

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Description of the issue/feature t

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount.

To improve clarity:
- Negative values are now displayed instead of being forced to 0.
- The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed.

Task-4589150

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

- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510

- Fetch photo from `hr.employee.public` to be avail for users without no hr rights

Task: 4626795



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

Forward-Port-Of: odoo/odoo#200510

We faced a [warning](https://github.com/odoo/odoo/pull/186467/files#diff-f4c0e9f9d6736a6c5313479e63a48eee140d0e3249932cdcf82d69d0bb7865b1R144) because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 Regarding the changes in this PR related to Registry: https://github.com/odoo/odoo/pull/186467 see: https://gi

We faced a [warning](https://github.com/odoo/odoo/pull/186467/files#diff-f4c0e9f9d6736a6c5313479e63a48eee140d0e3249932cdcf82d69d0bb7865b1R144) because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded).
All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359

Regarding the changes in this PR related to Registry: https://github.com/odoo/odoo/pull/186467

see: https://github.com/odoo/odoo/pull/191749
upg-2436225

**Reference Image**
![image](https://github.com/user-attachments/assets/627b824f-a8d2-4491-b94c-82e731da215c)



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

Forward-Port-Of: odoo/odoo#201096

### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:

### Issue:

You can not print label for an mo is the qty_producing is at 0.

### Steps to reproduce:

- Create a storable product FP tracked by LOT.
- Create a bom for that product with 1 operation containing an instruction of type: "print label"
- Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0).
- Process the operation in the shopfloor and print label
#### > The printed label is empty.

### Cause of the issue:

The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced.
https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332

opw-4583573

Forward-Port-Of: odoo/enterprise#81285
Forward-Port-Of: odoo/enterprise#80802

- Fix access rights (again) on employee view for wage statements - Fix condition on ACC rule that prevents manual edition of payslip lines Forward-Port-Of: odoo/enterprise#81317

- Fix access rights (again) on employee view for wage statements
- Fix condition on ACC rule that prevents manual edition of payslip lines

Forward-Port-Of: odoo/enterprise#81317

Steps fo reproduce : - create a product (in the inventory tab, the route should be 'Manufacture') - click on the smart button 'bill of materials' - create a BOM for this product with at least one operation - in the quality app navigate to Quality Control/Control Points - create a new control point - in the field product select the product that you created - in the operations field select "YourCompany: Manufacturing" - in the work order operation field select the operation that you wrote

Steps fo reproduce :
- create a product (in the inventory tab, the route should be 'Manufacture')
- click on the smart button 'bill of materials'
- create a BOM for this product with at least one operation
- in the quality app navigate to Quality Control/Control Points
- create a new control point
- in the field product select the product that you created
- in the operations field select "YourCompany: Manufacturing"
- in the work order operation field select the operation that you wrote in the BOM you created (if multiple operations with the same name make sure that you selected the one linked with the BOM)
- in the type field select "Measure"
- in the norm field enter a unit of measure with at least an upper case
- create a manufacturing order for this product
- open the shop floor app and on the manufacturing order you created select the quality check point

Current Behavior:
The unit of measure appears in lower case. This could change its meaning for instance form MW (mega-watt) to mw (mili-watt)

Expected Behavior:
The unit of measure string should respect the letter case wrote by the user

Cause of the issue:
In the xml file, inside the <span> tag the class was "text-lowercase"

Fix:
I removed this class from the span

https://github.com/odoo/enterprise/blob/43e7aec36ddee8a3ff3de8793427a183dfd29b30/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.xml#L47

opw-4584509

Forward-Port-Of: odoo/enterprise#81274

Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone f

Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record

This is because most records do not allow public users from reading them.

This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user.

Additional:
The phone formatter should be able to guess the country of a record based on the country of its partner

task-4199766

Forward-Port-Of: odoo/enterprise#80704
Forward-Port-Of: odoo/enterprise#70608

If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318

If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token.

https://firebase.google.com/docs/cloud-messaging/manage-tokens

Forward-Port-Of: odoo/enterprise#81318

Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test). This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user. Forward-Port-Of: odoo/enterprise#

Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test).

This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user.

Forward-Port-Of: odoo/enterprise#81309

**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1

**Issue**
The project's Gantt view doesn't work if the "Project Stages"
setting is not enabled.

**Steps to reproduce**
- Install `project_enterprise` and Studio.
- Have project stages disabled.
- Open Projects app.
- Click on Studio button > Views > Try to activate Gantt view.
-> `AccessError for read on stage_id`

**Cause**
The `stage_id` field used on the project gantt view is only readable if
the project stages feature is enabled.
https://github.com/odoo/enterprise/blob/b911ed1e857e1534c86495cd4934c1adb8ae9597/project_enterprise/views/project_views.xml#L12

**Solution**
A hack is to add in the model metadata the `colorField` key used by the
gantt renderer to color the pills:
https://github.com/odoo/enterprise/blob/28f2fba988b1b225c97d15729020962ed4dee73b/web_gantt/static/src/gantt_renderer.js#L778
It is normally set when parsing the view here:
https://github.com/odoo/enterprise/blob/dfe2795b820527a8226d8cf1afa5bf7ac8fcb53d/web_gantt/static/src/gantt_arch_parser.js#L194
This avoids trying to read the field if the user doesn't have the
necessary `project.group_project_stages` group.

Note: some missing views are also added in this commit, they were missing
when the project stage feature wasn't enabled.

opw-4592110

Forward-Port-Of: odoo/enterprise#81179
Forward-Port-Of: odoo/enterprise#79968

### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the pr

### Steps to reproduce:

- Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance.
- Create and confirm an MO for 1 unit of FP
- Process the MO from the barcode app.
- Click on "Add Component" select COMP as a product and set 1 unit
- Confirm the additional move line
#### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category."

### Cause of the issue:

When processing an MO from the barcode app and adding a component the method `_getNewLineDefaultContext` will be called to set the default context of that new line before creation:
https://github.com/odoo/enterprise/blob/83268aa3a5a7afdc8c09b0ac9bbee2b673fd25e9/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L367-L372 However, in this flow, `this.record` is an `mrp.production` and its `product_uom_id` is the product_uom_id of FP. In particular, the `default_product_uom_id` key will be used to alter the vals_list used in the create of our stock move line and an error will be raised since the unit category of COMP2 is Weight and is not compatible with the default product uom set by the context.

opw-4527706

Forward-Port-Of: odoo/enterprise#80987
Forward-Port-Of: odoo/enterprise#79266

**Steps to reproduce:** 1.Go to Documents > Configuration > Settings: -Enable Accounting (Centralize accounting files and documents) -Open Journals and synchronize a chosen journal with a workspace 2.Create a new activity type with: `action`: `Upload Document` `folder_id`: The same workspace we set in the settings 3.Create a journal entry in the journal you chose 4.Add the new activity to the journal entry. 5.Upload a document. **Issue:** The attachment is up

**Steps to reproduce:**

1.Go to Documents > Configuration > Settings:
  -Enable Accounting (Centralize accounting files and documents)
  -Open Journals and synchronize a chosen journal with a workspace 
2.Create a new activity type with:
        `action`: `Upload Document`
        `folder_id`: The same workspace we set in the settings 
3.Create a journal entry in the journal you chose
4.Add the new activity to the journal entry.
5.Upload a document.

**Issue:**
The attachment is uploaded, but we get a Missing Record error for an `ir.attachment` record, and the activity isn't set to done

**Cause:**
This commit was meant to prevent this issue: https://github.com/odoo/enterprise/commit/6c4bbf2fe0577fe1f4fc9f6a408c5904eb1cf92b

What it is meant to do is to add a `no_document` flag to prevent the creation of two documents when an attachment is uploaded to an activity, since the second one will by unlinked, along with the attachment. See:
https://github.com/odoo/enterprise/blob/a46594b2d3529d86a40a1567e0e4e0207399a3a8/documents/models/mail_activity.py#L41

But a particular case was not included:
  - if the attachment fits at least one of these criteria:
        - attachment of a misc operation
        - first attachment of an invoice
        - xml file after it has been succesfully registered as move attachment
  - if the journal in which the entry was created is synchronized with the activity's workspace

In this case, a second document is created, since we don't check for the flag `no_document` in this flow.

see:
https://github.com/odoo/enterprise/blob/28b6a5d30274f4265c978433b8d02b758d9a032e/documents_account/models/ir_attachment.py#L24

and:
https://github.com/odoo/enterprise/blob/85c139237015a7c3f1233eb9d977ead126b7d7d6/documents_account/models/account_move.py#L87

**Solution:**
Added a check for the `no_document` flag before calling `_update_or_create_document`

opw-4547561

Forward-Port-Of: odoo/enterprise#80662

Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company Task: 4625747 Forward-Port-Of: odoo/enterprise#81428 Forward-Port-Of: odoo/enterprise#80740

Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error

Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company

Task: 4625747

Forward-Port-Of: odoo/enterprise#81428
Forward-Port-Of: odoo/enterprise#80740

To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour:

To reproduce:
- Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation.
- Enable packages in inventory settings.
- New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg).
- Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg).
- Validate the picking.

Current behaviour:
Crashes when trying to create the return label with nondescript error coming from FedEx.

Expected behaviour:
Ideally, a correctly validated picking with generated return labels. However, this appears to currently not be supported by the FedEx REST API... (multi-package single-shot return shipments of print label type)
We compromise and will create the outgoing shipment as usual, but not the return shipment in case of multi-package shipments. A helpful message informing the user of this limitation will be put in the chatter of the picking instead of the generated return label in this specific case.

opw-4556415

Forward-Port-Of: odoo/enterprise#81326

When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation. Forward-Port-Of: odoo/enterprise#81203

When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation.

Forward-Port-Of: odoo/enterprise#81203

Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710'). However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions. This commit proposes to use sanitized_acc_number from mandate partner bank account. opw-4536189 Forward-Port-Of: odoo/enterprise#81238

Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710').

However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions.

This commit proposes to use sanitized_acc_number from mandate partner bank account.

opw-4536189

Forward-Port-Of: odoo/enterprise#81238