**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#201712
Forward-Port-Of: odoo/odoo#200555

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

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

Previously, the epigrafe validation error was only triggered for non-'is_sale' documents. As a result, invoices without a defined epigrafe failed silently until submission to TicketBAI, causing an unclear TicketBAI error. This fix ensures that the user error appears for invoices as well, preventing the misleading "El XML no cumple el esquema" error. Steps to reproduce: - Set up a Spanish freelance company - Change tax agency to Bizkaia - Try to send an invoice The TicketBAi error `B4

Previously, the epigrafe validation error was only triggered for non-'is_sale' documents. As a result, invoices without a defined epigrafe failed silently until submission to TicketBAI, causing an unclear TicketBAI error.

This fix ensures that the user error appears for invoices as well, preventing the misleading "El XML no cumple el esquema" error.

Steps to reproduce:
- Set up a Spanish freelance company
- Change tax agency to Bizkaia
- Try to send an invoice

The TicketBAi error `B4_1000001: El XML no cumple el esquema.[Linea:17 Columna:5] Error:cvc-complex-type.2.4.b: The content of element 'Ingreso' is not complete. One of '{Renta}' is expected.`

opw-4559069

Forward-Port-Of: odoo/odoo#200012

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

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#201686 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#201686
Forward-Port-Of: odoo/odoo#201011

- Activate wave transfers and group by product or any other, easy to see it by product. - Create a sales order with two different products in the sales order lines - Changed the delivery date in the other info tab. - When confirming the sales order, two transfers will be created, each will have one product. Current behavior: - One picking will respect the scheduled date and the other one will have it for today. Expected: - Both picking have the sale order schedule date. It happens

- Activate wave transfers and group by product or any other, easy to see it by product.
- Create a sales order with two different products in the sales order lines
- Changed the delivery date in the other info tab.
- When confirming the sales order, two transfers will be created, each will have one product.

Current behavior:
- One picking will respect the scheduled date and the other one will have it for today.

Expected:
- Both picking have the sale order schedule date.

It happens because the picking copy miss some data

opw-4571808

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

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

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.

Forward-Port-Of: odoo/odoo#200311

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. Forward-Port-Of: odoo/odoo#201700

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.

Forward-Port-Of: odoo/odoo#201700

Until now, the after_sub are only sent after the start of the event Forward-Port-Of: odoo/odoo#201701

Until now, the after_sub are only sent after the start of the event

Forward-Port-Of: odoo/odoo#201701

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

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

This commit fixes an undeterministic behavior error in POS. Changing the number of products with "⌫", "8" does not recalculate the number of free products. To recalculate, you must type "⌫", "⌫", "1", "8". 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#201603

This commit fixes an undeterministic behavior error in POS. Changing the number of products with "⌫", "8" does not recalculate the number of free products. To recalculate, you must type "⌫", "⌫", "1", "8".

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

This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201487 Forward-Port-Of: odoo/odoo#200961

This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small

task-4633869

Forward-Port-Of: odoo/odoo#201487
Forward-Port-Of: odoo/odoo#200961

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

### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date. ### Current behavior before PR: 1. Make e-commerce sales after 9 PM local time AR in

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

If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date.

### Current behavior before PR:

1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal)
2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it.
3. We will receive ARCA (ex-AFIP) error telling us that we can not generate the invoice with today's date, we can only validate invoices with a date equal to or greater than tomorrow. 

### Desired behavior after PR is merged:

1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal)
2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it.
3. Manual invoice will be generated and validated in AFIP with today's date as the invoice date.


NOTE: We took the same approach that was used in the [POS module](https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/models/pos_order.py#L615-L631) to set the date, in this case, always forcing the Argentina timezone

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

Forward-Port-Of: odoo/odoo#197179
Forward-Port-Of: odoo/odoo#192808

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

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

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

Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201457 Forward-Port-Of: odoo/odoo#201321

Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session.

task-4637836

https://github.com/odoo/upgrade/pull/7372

Forward-Port-Of: odoo/odoo#201457
Forward-Port-Of: odoo/odoo#201321

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

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

- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. - addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient. - addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue. - addons/website/tests/test

- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures.
- addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient.
- addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue.
- addons/website/tests/test_ui.py Add a step_delay to ensure tour works each time (undeterminisms)
- addons/web_tour/static/src/tour_service/tour_helpers.js Harmonize usage of async / await. Wait the dom is stable before to click on a link.
- addons/web_tour/static/src/tour_service/tour_automatic.js Set a large timeout when step is paused.

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

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

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

…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

*: portal, website, web_editor Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. **Global** - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach. - Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend` **Dropdowns** - Adjusted active state colors to prevent conflicts

*: portal, website, web_editor

Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. 

**Global**
 - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach.
- Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend`

**Dropdowns**
- Adjusted active state colors to prevent conflicts between the primary active color and dropdown item text color.
- Differentiate two active states: 
  - Active menu entries (current page) ➡️  Primary color
  - Active feedback on click ➡️  color-contrast of background color
- Updated the `o_extra_menu_items` dropdown to adapt the borders to the user theme settings, removing the hardcoded `gray-200` value.

**Search & Misc**
 - Replaced `-webkit-search-cancel-button` with Bootstrap's `btn-close` design introducing a mixin for contextual color adjustments to match the input color.
- Changed portal search input type from `text` to `search` ensuring proper styling and semantic.

task-3969685

| Before | After |
| --- | --- | 
| ![image](https://github.com/odoo/odoo/assets/118886338/aae9ce72-62e9-44a9-87de-8914bd06bb7a) |  ![image](https://github.com/user-attachments/assets/1bb428b9-1d22-4607-9d2d-9abfb87ba311) |
|![image](https://github.com/odoo/odoo/assets/118886338/ed891c37-11bd-4f69-82a2-45d4a235abd1) | ![image](https://github.com/odoo/odoo/assets/118886338/89db4343-9042-43c8-a338-e2f1f50e7b54) |
| ![image](https://github.com/odoo/odoo/assets/118886338/ae95a96c-8243-46f7-981e-dcc0b1f63e43) | ![image](https://github.com/odoo/odoo/assets/118886338/c8c24097-8e6b-47d5-a0bc-aff3c3841a73) |




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

Forward-Port-Of: odoo/odoo#201351
Forward-Port-Of: odoo/odoo#170922

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

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

Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was al

Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems.

First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network.

Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags.

The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same.

opw-4596936

Forward-Port-Of: odoo/odoo#201415
Forward-Port-Of: odoo/odoo#201164

Problem --------- When the certificate or the key is created through SQL INSERT, the compute functions are not triggered. This lead to the 'loading_error' field to remain FALSE. Since the condition that checked whether or not to display the loading error message was "loading_error == ''", it meant that the message would be display when it was equal to FALSE. Instead, we now just check if there is a loading error message with 'not loading_error' which solves the issue and makes it more ro

Problem
---------
When the certificate or the key is created through SQL INSERT, the compute functions are not triggered. This lead to the 'loading_error' field to remain FALSE.

Since the condition that checked whether or not to display the loading error message was "loading_error == ''", it meant that the message would be display when it was equal to FALSE.

Instead, we now just check if there is a loading error message with 'not loading_error' which solves the issue and makes it more robust.

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

Forward-Port-Of: odoo/odoo#201574

The email domain eim.ae is associated with Etisalat, a major telecommunications provider in the United Arab Emirates. Addresses ending with @eim.ae are commonly used by individuals and businesses in the UAE, similar to how @gmail.com addresses are used globally. That's why we should not use it for detect it similar leads. Reproduce --- - Install crm - Create a lead - Add email with @eim.ae as domain - BUG: Similar lead identified based on the email domain opw-4506179 Forward-Port-

The email domain eim.ae is associated with Etisalat, a major telecommunications provider in the United Arab Emirates. Addresses ending with @eim.ae are commonly used by individuals and businesses in the UAE, similar to how @gmail.com addresses are used globally.

That's why we should not use it for detect it similar leads.

Reproduce
---
- Install crm
- Create a lead
- Add email with @eim.ae as domain
- BUG: Similar lead identified based on the email domain

opw-4506179

Forward-Port-Of: odoo/odoo#198963

Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Kg - Create a delivery order: - product: P1 - qty: 100 g - Mark the delivery as "To Do" - Set the quantity to 100 g - Go to the product form of P1 → Update quantity Problem: The reserved quantity is set to 100 kg instead of 0.1 kg opw-4638315 Forward-Port-Of: odoo/odoo#201237

Steps to reproduce the bug:
- Create a storable product “P1”:
    - UoM: Kg

- Create a delivery order:
    - product: P1
    - qty: 100 g
- Mark the delivery as "To Do"
- Set the quantity to 100 g
- Go to the product form of P1 → Update quantity

Problem:
The reserved quantity is set to 100 kg instead of 0.1 kg

opw-4638315

Forward-Port-Of: odoo/odoo#201237

Before this commit, we could get events for a RtcSession that is not yet available. This can happen when network information (SFU/p2p) races Odoo server information (bus). As RtcSessions' source of truth is the Odoo server, information obtained from the call network are only acknowledged if we have the record from Odoo. This commit fixes this issue by awaiting sessions for which events are obtained. Fetching should not be necessary as: - if the event is for a session that exists, the

Before this commit, we could get events for a RtcSession that is
not yet available. This can happen when network information (SFU/p2p)
races Odoo server information (bus). As RtcSessions' source of truth
is the Odoo server, information obtained from the call network are
only acknowledged if we have the record from Odoo.

This commit fixes this issue by awaiting sessions
for which events are obtained.

Fetching should not be necessary as:
- if the event is for a session that exists, the client will eventually
obtain it (from the bus message that is sent when a new is created,
or by the `rtc_service.ping()` which periodically fetches sessions).
- if the event is for a session that does not exist, fetching does not
make sense.

Forward-Port-Of: odoo/odoo#200981

- Fix issue where the price was displayed on every product card (like in product screen). To fix this we want to only display the price of the card in combo choice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201437

- Fix issue where the price was displayed on every product card (like in product screen). To fix this we want to only display the price of the card in combo choice.



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

Forward-Port-Of: odoo/odoo#201437

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

When we have more than 100 users, we send e-mails in an endless loop because we always process the same records. After this change, we send all e-mails in one call. Backport of odoo/odoo#199091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199661

When we have more than 100 users, we send e-mails in an endless loop because we always process the same records.
After this change, we send all e-mails in one call.

Backport of odoo/odoo#199091



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

Forward-Port-Of: odoo/odoo#199661

### Steps to reproduce: - install "l10n_uk_bacs" - Go to Accounting > Customers > BACS Direct Debit Instruction and create a new one - Fill necessary values and validate - Traceback ### Cause: This [commit](https://github.com/odoo/enterprise/commit/54965c8d62301ba1fa8409709a1a1fd77150f722#diff-e00ec661d761679265d152ef44c96f9f1bb896e7dc148ea8ad7ce94cd3c28e11) changed the field `bacs_ddi_id` in `account.move` to a computed field and moved the storage to `account.payment`. But it did not ch

### Steps to reproduce:
- install "l10n_uk_bacs"
- Go to Accounting > Customers > BACS Direct Debit Instruction and create a new one
- Fill necessary values and validate
- Traceback

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/54965c8d62301ba1fa8409709a1a1fd77150f722#diff-e00ec661d761679265d152ef44c96f9f1bb896e7dc148ea8ad7ce94cd3c28e11) changed the field `bacs_ddi_id` in `account.move` to a computed field and moved the storage to `account.payment`. But it did not change `_compute_from_moves` which was using SQL queries with `move.bacs_ddi_id`. So the method crashes because the table account_move does not have a column named bacs_ddi_id anymore.

### Solution:
Adapt the SQL queries to use `payment.bacs_ddi_id`.

opw-4593098

Forward-Port-Of: odoo/enterprise#80893

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') ``` Forward-Port-Of: odoo/enterprise#81366

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')
```

Forward-Port-Of: odoo/enterprise#81366

- 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

When printing an invoice in the l10n_mx_edi module, a traceback occurs if the client's language is empty. This happens because the system previously defaulted to es_ES, which may not be activated. Steps to Reproduce: 1. Install the l10n_mx_edi module and switch to a Mexican company. 2. Enable multiple languages in the system. 3. Create an invoice and leave the customer's language empty (no language set). 4. Print the invoice. 5. Issue: A traceback occurs due to the missing es_ES langua

When printing an invoice in the l10n_mx_edi module, a traceback occurs if the
client's language is empty. This happens because the system previously
defaulted to es_ES, which may not be activated.

Steps to Reproduce:
1. Install the l10n_mx_edi module and switch to a Mexican company.
2. Enable multiple languages in the system.
3. Create an invoice and leave the customer's language empty (no language set).
4. Print the invoice.
5. Issue: A traceback occurs due to the missing es_ES language.

Now, there is no fallback to es_ES when the client's language is empty.
The amount-to-text conversion strictly relies on `self.partner_id.lang.
If no language is set, the conversion translates to the user's language.

opw-4572245

Forward-Port-Of: odoo/enterprise#80879

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

The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This

The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO).

Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place.

This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision.

Task-4506832

Forward-Port-Of: odoo/enterprise#81302
Forward-Port-Of: odoo/enterprise#77667

Steps: - Sales app > Configuration > Quotation Templates. - Create a New template. - In field 'Quote calculator' select 'search more..' - select 'New' button Issue: - New button throws validation error says missing required field 'name', blocking creation. Cause: - default value was not assigned to required field 'name' in respective model. Fix: - Added a default value for 'name' field, so creating a new quote calculator will initially be labeled as 'New Spreadsheet' and can be r

Steps:
- Sales app > Configuration > Quotation Templates.
- Create a New template.
- In field 'Quote calculator' select 'search more..'
- select 'New' button

Issue:
- New button throws validation error says missing required field 'name', blocking creation.

Cause:
- default value was not assigned to required field 'name' in respective model.

Fix:
- Added a default value for 'name' field, so creating a new quote calculator will initially be labeled as 'New Spreadsheet' and can be renamed as needed.

opw-4552429

Forward-Port-Of: odoo/enterprise#80439

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

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

Steps to reproduce: - open the trial balance with a company having some account groups (like BE company) - activate the hierarchy and subtotals filter - create an annotation for an account - press outside the popover to save the annotation - open the annotation popover -> The annotation is no longer visible Other similar issue - create an annotation (with again hierarchy activated) - directly create another one -> The popover disappear and no annotations are visible Cause of

Steps to reproduce:
 - open the trial balance with a company having some account groups (like BE company)
 - activate the hierarchy and subtotals filter
 - create an annotation for an account
 - press outside the popover to save the annotation
 - open the annotation popover -> The annotation is no longer visible

Other similar issue
 - create an annotation (with again hierarchy activated)
 - directly create another one -> The popover disappear and no annotations are visible

Cause of the issue:
When grouping per hierarchy, the line ids contains some unnecessary components for these grouping per account groups, which need to be filtered out with the helper function already created to handle this case.

opw-4546653

Forward-Port-Of: odoo/enterprise#81333

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

Translation tool `_` does not work inside a generator, but new tool* based on the environment (`env._`) does. This commit fixes the issue in upsell activity lines. *https://github.com/odoo/odoo/commit/b794f0f332f473deb2c04eba60baf4761db3b508 Forward-Port-Of: odoo/enterprise#81347

Translation tool `_` does not work inside a generator, but new tool* based on the environment (`env._`) does. This commit fixes the issue in upsell activity lines.

*https://github.com/odoo/odoo/commit/b794f0f332f473deb2c04eba60baf4761db3b508

Forward-Port-Of: odoo/enterprise#81347

Before this PR: - The SDD Mandate model was accessible only to invoicing users. - As a result, read-only users could not view payment records because some fields attempted to access the SDD Mandate model. After this PR: - Fields related to the SDD Mandate model are now restricted to invoicing users using the appropriate access groups. - This ensures that read-only users can view payment records without encountering access issues. Forward-Port-Of: odoo/enterprise#80336

Before this PR:
- The SDD Mandate model was accessible only to invoicing users.
- As a result, read-only users could not view payment records because some fields attempted to access the SDD Mandate model.

After this PR:
- Fields related to the SDD Mandate model are now restricted to invoicing users using the appropriate access groups.
- This ensures that read-only users can view payment records without encountering access issues.

Forward-Port-Of: odoo/enterprise#80336

Small oversight in odoo/enterprise#79245. Don't hide the entire group for service products. Visibility for goods/service products is determined per field below. opw-4601199 Forward-Port-Of: odoo/enterprise#80324

Small oversight in odoo/enterprise#79245. Don't hide the entire group for service products. Visibility for goods/service products is determined per field below.

opw-4601199

Forward-Port-Of: odoo/enterprise#80324