Steps to reproduce: [l10n_* nl/be/etc - Europe] - create a customer form Monaco with a valid TVA number `FR53000004605` - create an invoice with this customer with an intra-eu tax - Open the EC Sales List Report Issue: The invoice will not be displayed Cause: Monaco is not part of the list Solution: We add it if the company.country_id is not France. Because for any other european country we want Monaco's invoices to be displayed opw-4075452 Forward-Port-Of: odoo/enterprise#68

Steps to reproduce:
[l10n_* nl/be/etc - Europe]
- create a customer form Monaco with a valid TVA number `FR53000004605`
- create an invoice with this customer with an intra-eu tax
- Open the EC Sales List Report

Issue:
The invoice will not be displayed

Cause:
Monaco is not part of the list

Solution:
We add it if the company.country_id is not France. Because for any other european country we want Monaco's invoices to be displayed

opw-4075452

Forward-Port-Of: odoo/enterprise#68560

Current behaviour: --- When you open a document, and you want to add a tag, the preview closes. Steps to reproduce: --- 1. Go to Documents 2. Open a document 3. Add a tag 4. The preview closes Cause of the issue: --- In updateRecordTagId from documents_search_model.js Update trigger > load > documents-close-preview trigger opw-3879288 Forward-Port-Of: odoo/enterprise#66684

Current behaviour:
---
When you open a document, and you want to add a tag, the preview closes.

Steps to reproduce:
---
1. Go to Documents
2. Open a document
3. Add a tag
4. The preview closes

Cause of the issue:
---
In updateRecordTagId from documents_search_model.js
Update trigger > load > documents-close-preview trigger

opw-3879288

Forward-Port-Of: odoo/enterprise#66684

Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual then duplicate it - Create a subscription with the indiviual as customer - Duplicate the subscription then set the duplicate contact as customer - Debug mode > Scheduled actions - Sale subscription: Generate recurring invoices and payments > Run manually The subsciptions are invoiced separ

Steps to reproduce:
- Settings > Enable 'Consolidate subscriptions billing'
- Contact > Create a company
- Contacts & Addresses tab > Add
- Add an invoice address on the company
- Add an individual then duplicate it
- Create a subscription with the indiviual as customer
- Duplicate the subscription then set the duplicate contact as customer
- Debug mode > Scheduled actions
- Sale subscription: Generate recurring invoices and payments > Run manually

The subsciptions are invoiced separately instead of having one invoice
for both. The consolidated billing should produce only one invoice since
the invoicing address is the same.

This behavior works as intended if using the create invoices action on both
subscriptions at once. Here, the recurring invoice creation for subscriptions
uses its own grouping function using partner_id as a key instead of
partner_invoice_id which is 'parent invoice address id if any, else partner_id'.

Because this grouping is performed before creating the invoices, we end
up processing sale orders that should have belonged to the same group
separarately and thus create the invoices one by one. This means we
don't let _create_invoices do the grouping since we only pass it one SO
at a time, this fix will make it so _create_invoices is called on the
grouped SOs instead.

opw-4114035

Forward-Port-Of: odoo/enterprise#69277

…ew ro Version: 17.0 Steps: Click on the schedule feature in the rental module. Click on the 'New' to create the rental order. Issue : When a user clicks on the "Schedule" feature in the rental module and then clicks on "New" to create a rental order, the rental period feature is disabled, and the payment period appears instead. Cause : The issue is caused by the condition invisible="not is_rental_order" on the rental_start_date field. fix: To fix this issue, we remove the invis

…ew ro

Version: 17.0
Steps:
Click on the schedule feature in the rental module. Click on the 'New' to create the rental order.

Issue :
When a user clicks on the "Schedule" feature in the rental module and then clicks on "New" to create a rental order, the rental period feature is disabled, and the payment period appears instead.

Cause :
The issue is caused by the condition invisible="not is_rental_order" on the rental_start_date field.

fix:
To fix this issue, we remove the invisible="not is_rental_order" condition from the rental_start_date field definition.
This ensures that the rental period feature is always visible when creating a new rental order.

opw-4016866

Forward-Port-Of: odoo/enterprise#69306
Forward-Port-Of: odoo/enterprise#66904

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid. This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised. Step to reproduce: - create a db with hr_tim

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.

This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised.

Step to reproduce:
- create a db with hr_timesheet installed
- have a user with 'user' access rights on project and 'own timesheet' on timesheet
- create an internal project
- create a task inside that internal project and assigned the user on it
- connect with the other user
- open timesheet app
- select the task from the internal project to start a new timesheet timer
- an error access right on 'project' is triggered

Solution:
Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project.

task - 3922511
affected version 16.0 - master

Forward-Port-Of: odoo/enterprise#69226
Forward-Port-Of: odoo/enterprise#63159

- create a new spreadsheet - fill all cell with content (add rows and content until it crashes) - click on the Share button => boom We have a monkey-patched version of `literal_eval` which only accepts an input size of maximum 100KiB. But spreadsheet files can be larger than that. Bug introduced by https://github.com/odoo-dev/enterprise/commit/e55597dde848ae349248e4381f812e516b839985 opw-4139087 opw-4082093 Forward-Port-Of: odoo/enterprise#69433

- create a new spreadsheet
- fill all cell with content (add rows and content until it crashes)
- click on the Share button

=> boom

We have a monkey-patched version of `literal_eval` which only accepts
an input size of maximum 100KiB.

But spreadsheet files can be larger than that.

Bug introduced by https://github.com/odoo-dev/enterprise/commit/e55597dde848ae349248e4381f812e516b839985

opw-4139087
opw-4082093

Forward-Port-Of: odoo/enterprise#69433

We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9). Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore. We then add it again to fix the issue. Support task: 4152608 Forward-Port-Of: odoo/enterprise#69429

We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9).  
Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore.

We then add it again to fix the issue.

Support task: 4152608

Forward-Port-Of: odoo/enterprise#69429

When we tried to open the dialog, we would get an error telling us that the function close from the props is missing. The fix is to use a custom close function that will trigger the action of type `act_window_close` task-4154392 Forward-Port-Of: odoo/enterprise#69263

When we tried to open the dialog, we would get an error telling us that the function close from the props is missing.

The fix is to use a custom close function that will trigger the action of type `act_window_close`

task-4154392

Forward-Port-Of: odoo/enterprise#69263

Before this commit, Using the "request signature" option allowed users to create templates on the fly, which could lead to errors. In this commit, the Creation of templates on the fly from the wizard is no longer allowed. task-4069128 Forward-Port-Of: odoo/enterprise#69486 Forward-Port-Of: odoo/enterprise#67232

Before this commit, Using the "request signature" option allowed users to create templates on the fly, which could lead to errors.

In this commit, the Creation of templates on the fly from the wizard is no longer allowed.

task-4069128

Forward-Port-Of: odoo/enterprise#69486
Forward-Port-Of: odoo/enterprise#67232

With this commit, some rules category are fixed : deduction, allowance are set only on employee rule. One file's name changed to be coherent with others payrolls. task-4069829 Forward-Port-Of: odoo/enterprise#69170 Forward-Port-Of: odoo/enterprise#68889

With this commit, some rules category are fixed : deduction, allowance are set only on employee rule. One file's name changed to be coherent with others payrolls.

task-4069829

Forward-Port-Of: odoo/enterprise#69170
Forward-Port-Of: odoo/enterprise#68889

### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the delivered quantity of the field service product to meet the order quantity - Check the invoice status (will be 'Fully Invoiced') - Set the field service product in the SO to a unit price 0 ### Current behavior before PR: After creating an invoice for a SO that has field service product and

### Steps to reproduce:
	- Install Sale and Field Service modules
	- Create a Quotation with a normal product and another Field service product
	- Confirm the quotation and invoice it
	- Change the delivered quantity of the field service product to meet the order quantity
	- Check the invoice status (will be 'Fully Invoiced')
	- Set the field service product in the SO to a unit price 0

### Current behavior before PR:
After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91

### Desired behavior after PR is merged:
We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL.

opw-4017282

Forward-Port-Of: odoo/enterprise#68893

The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period) An existing solution: Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the reple

The case:
- I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers

The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period)

An existing solution:
Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the replenishment report everyday and don't have weekend. And if they use automatic RR they lose the control over the warehouse that should resupply the product.

Also they can't use the visibility days feature and plan for a week.

In order to allow a better planning and flexibility we add a small parameter to ignore the returns of rental order. That way the forecast ignore returns and allow visibilty.

BUT it's DANGEROUS. Because it means that outgoing after return won't be correctly forecasted. So the user have to use a small lead time. E.g. Global lead days = 70 days, do a rental order in 10 days (for a day) and another in 20 days. With the parameter enable, it will suggest 2 units. However it should be one since one is returned.

Forward-Port-Of: odoo/enterprise#69236
Forward-Port-Of: odoo/enterprise#69015

Change the conditions of the account_3way_match filter on accounting dashboard for the bills journal. Before this commit: Show Bills with release_to_pay = 'yes' or invoice date < today. After this commit: Show Bills with release_to_pay = 'yes' or 'exception', the invoice date is no more used. task:3877069 Forward-Port-Of: odoo/enterprise#69068 Forward-Port-Of: odoo/enterprise#67357

Change the conditions of the account_3way_match filter on accounting dashboard for the bills journal.

Before this commit: Show Bills with release_to_pay = 'yes' or invoice date < today.

After this commit: Show Bills with release_to_pay = 'yes' or 'exception', the invoice date is no more used.

task:3877069

Forward-Port-Of: odoo/enterprise#69068
Forward-Port-Of: odoo/enterprise#67357

This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML. Purpose: In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id). This commit also rest

This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML.

Purpose:
In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id).

This commit also restructures the placement of `t-if`/`div`s so that they appear in the right places and not generate empty divs.

task-id: 4064069

Forward-Port-Of: odoo/enterprise#69234
Forward-Port-Of: odoo/enterprise#68902

When an internal user with planning access performs the Add to Calendar action, the planning backend view opens instead of downloading the ICS file.This commit fixed this behavior. task-3978534 Forward-Port-Of: odoo/enterprise#66141

When an internal user with planning access performs the Add to Calendar action,
the planning backend view opens instead of downloading the ICS file.This commit
fixed this behavior.

task-3978534

Forward-Port-Of: odoo/enterprise#66141

commit 073163f1ae3fd2c659653b773d3ed66836eb2cb2 replaced the new barcode files with the correct code but an intermediate version with incorrect barcode has been forgot in the root of the repository Forward-Port-Of: odoo/enterprise#69416

commit 073163f1ae3fd2c659653b773d3ed66836eb2cb2 replaced the new barcode files with the correct code but an intermediate version with incorrect barcode has been forgot in the root of the repository

Forward-Port-Of: odoo/enterprise#69416

**Steps to reproduce:** - Install Accounting, Sales and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Create a SO for a Peruvian customer (e.g. Comercial Constructora) - Confirm the SO - Create a down payment - Confirm the down payment - Send it to Peru UBL 2.1 **Issue:** The Electronic Service Operator (OSE) responds with an error because an item is declared without unit of measure. **Cause:** From saas-17.1, there is no product associated to a down payment line

**Steps to reproduce:**
- Install Accounting, Sales and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Create a SO for a Peruvian customer (e.g. Comercial Constructora)
- Confirm the SO
- Create a down payment
- Confirm the down payment
- Send it to Peru UBL 2.1

**Issue:**
The Electronic Service Operator (OSE) responds with an error because an item is declared without unit of measure.

**Cause:**
From saas-17.1, there is no product associated to a down payment line anymore.

**Solution:**
For down payment line, use the code (i.e. NIU) of the default unit of measure (i.e. Units), which was the default UoM of the down payment product before saas-17.1.

opw-4057252

Forward-Port-Of: odoo/enterprise#69308
Forward-Port-Of: odoo/enterprise#69124

### Before this PR: ->If we create a product that isn't a service > open the helpdesk ticket form view -> type the name of the product you created from the SOL field and click create -> a new SOL is generated for this product and is successfully set on the ticket ### After this PR: A new SOL is generated only for service products, it should only be allowed for services products, it will throw validation error that isn't service task-3972359 Forward-Port-Of: odoo/enterprise#69380

### Before this PR:

 ->If we create a product that isn't a service > open the helpdesk ticket form view
 -> type the name of the product you created from the SOL field and click create
 -> a new SOL is generated for this product and is successfully set on the ticket

### After this PR:
A new SOL is generated only for service products,  it should only be allowed for services products, it will throw validation error that isn't service

task-3972359

Forward-Port-Of: odoo/enterprise#69380
Forward-Port-Of: odoo/enterprise#66463

Forward-Port-Of: odoo/enterprise#69399

Forward-Port-Of: odoo/enterprise#69399

Problem: Upon installing helpdesk_fsm in a multi-company setup, the default fsm project when enabling "use_fsm" on helpdesk teams is incorrectly retrieving the fsm project from the wrong company. This leads to a multi-company access error when trying to navigate to the fsm project linked to the helpdesk teams. Purpose: Instead of incorrectly defaulting the fsm project from the wrong company upon installation using a default method, compute the default of fsm project based on the team's compan

Problem: Upon installing helpdesk_fsm in a multi-company setup, the default fsm project when enabling "use_fsm" on helpdesk teams is incorrectly retrieving the fsm project from the wrong company. This leads to a multi-company access error when trying to navigate to the fsm project linked to the helpdesk teams.

Purpose: Instead of incorrectly defaulting the fsm project from the wrong company upon installation using a default method, compute the default of fsm project based on the team's company.

Steps to Reproduce on Runbot:
1. Install Project, Field Service, and any l10n module
2. Switch to the localized company
3. Create a helpdesk team
4. Install the helpdesk_fsm module
5. Navigate to the helpdesk team settings
6. Enable "use_fsm" on the team
7. Try to access the default fsm project
8. multi-company AccessError is thrown

opw-3989799

Forward-Port-Of: odoo/enterprise#69115
Forward-Port-Of: odoo/enterprise#65701

Before this commit, when the payment provider updated the tx state with a webhook, the order was updated in a separate SQL transaction than the invoicing corn of subscription. Both transactions would update the same sale.order, resulting in concurrent update errors. Forward-Port-Of: odoo/enterprise#69142

Before this commit, when the payment provider updated the tx state with a webhook, the order was updated in a separate SQL transaction than the invoicing corn of subscription. Both transactions would update the same sale.order, resulting in concurrent update errors.

Forward-Port-Of: odoo/enterprise#69142