VoIP contact loading no longer fails for users who do not have permission to view recruitment applicant records. Applicant details are now only included when the user is allowed to access them, improving reliability while respecting existing access rules.

Before this commit, the code unconditionnally reads and sends hr.applicant records linked to a VoIP contact, leading to a crash in case the current user doesn't have access to hr.applicant records.

After this commit, applicant data are only sent if the user has access to hr.applicant.

**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add a default tax to "Expenses" account - Create an invoice: * Customer: [any] * Currency: [EUR] (i.e. the foreign currency) * Invoice Date: [a date in the past where the currency rate is different than today] * Invoice Lines: [any] - Confirm th

**Steps to reproduce:**
- Install Accounting

- Activate a foreign currency (e.g. EUR)
- Make sure there are several rates with today rate different than others
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Add a default tax to "Expenses" account

- Create an invoice:
  * Customer: [any]
  * Currency: [EUR] (i.e. the foreign currency)
  * Invoice Date: [a date in the past where the currency rate is different than today]
  * Invoice Lines: [any]
- Confirm the invoice

- Go to "Accounting / Reporting / Management / Unrealized Currency Gains/Losses"
- Set date filter to "Today"
- If there is no adjustement to do, check if the following message is displayed:
"You are using custom exchange rates. => Reset to Odoo’s Rate"
If it's the case, reset to Odoo's rate (i.e. Today's rate)
- Click on "Adjustement Entry" button:
  * Journal: Miscellaneous Operations
  * Expense Account: Expenses
  * Income Account: [any]
- Create Entry

**Issue:**
The values (debit/credit) of the created entry are 0, which is not the case when there is no default tax on the expense account.

**Cause:**
"_sync_dynamic_lines" is executed on the created entry. If a default tax is set on the expense account, "_sync_tax_lines" is also executed.
As only debit and credit values are set on the invoice lines of the entry (neither balance nor amount_currency), the sync method messes up with the value of debit and credit, resetting them to 0 (via multiple recompute).

**Solution:**
Skip invoice sync.
The values computed in "Multicurrency Revaluation Wizard" should be the ones that are used.

opw-4664255

Forward-Port-Of: odoo/enterprise#83570

steps to reproduce: - set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes) - go to Payroll / Reporting / DMFA - create a new DMFA and generate an XML report - it should throw error saying expected `int` (since ONSS is a Char field) fix: - while performing the export, filtered the digits only from these fields task-4502689 Forward-Port-Of: odoo/enterprise#80876

steps to reproduce:
- set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes)
- go to Payroll / Reporting / DMFA
- create a new DMFA and generate an XML report
- it should throw error saying expected `int` (since ONSS is a Char field)

fix:
- while performing the export, filtered the digits only from these fields

task-4502689

Forward-Port-Of: odoo/enterprise#80876

-- Context -- When no seller is defined on the product that is included in the approval request, you cannot generate an RFQ. Adding a seller in the product should allow creating the RFQ without re-setting the request to draft. -- Behavior before the fix -- You had to reset the request to draft before being able to generate the RFQ when a seller has been added to the product. -- Behavior after the fix -- You can. There was a missing field in the depends of the compute method for the sell

-- Context --
When no seller is defined on the product that is included in the approval request, you cannot generate an RFQ. Adding a seller in the product should allow creating the RFQ without re-setting the request to draft.

-- Behavior before the fix --
You had to reset the request to draft before being able to generate the RFQ when a seller has been added to the product.

-- Behavior after the fix --
You can. There was a missing field in the depends of the compute method for the seller ids.

task-4680780

Forward-Port-Of: odoo/enterprise#83876
Forward-Port-Of: odoo/enterprise#82874

This work appears to adjust how Documents and Knowledge pages are handled, but the pull request details are still marked as work in progress. The likely business impact is limited until the final purpose and user-facing behavior are clarified.

### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question an dopen the generated PDF - All current companies show in the header and other currencies are present ### Cause: When sending to multiple partners, the action is dispatched with to cron_threads so a new `env` is created. This `env` has a key `companies` containing all companies that exist in the

### Steps to reproduce:
- Accounting > Reporting > Partner Ledger
- Select multiple partners
- Select "Customer Statements" as report
- Click "Send"
- Go to the one of the partner in question an dopen the generated PDF
- All current companies show in the header and other currencies are present

### Cause:
When sending to multiple partners, the action is dispatched with to cron_threads so a new `env` is created. This `env` has a key `companies` containing all companies that exist in the DB. When the `_init_options_companies` is called for the report it adds `self.env.companies` to the option ([code](https://github.com/odoo/enterprise/blob/4ef74fd9527a28616bf81c9716d6000aa25b839e/account_reports/models/account_report.py#L1276)). So in the end all companies appear on the report.

### Solution:
Add 'forced_companies' in the options before calling the `cron`. 

The format of 'forced_companies' had to be changed to only contain ids because fields cannot be added in `send_and_print_values` as it's a JSON fields. 

opw-4635283

Forward-Port-Of: odoo/enterprise#83862
Forward-Port-Of: odoo/enterprise#82320

This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83827 Forward-Port-Of: odoo/enterprise#83783

This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974.

Fix in community was changing all the xml files generated, whereas
it should only have had an impact on the invoice report.

opw-4661577

Forward-Port-Of: odoo/enterprise#83827
Forward-Port-Of: odoo/enterprise#83783

Before this commit: The technical name was not clearly visible in dark mode, making it difficult for users to read. After this commit: The technical name is now clearly visible in dark mode. Task-4680365 Forward-Port-Of: odoo/enterprise#82429

Before this commit:
The technical name was not clearly visible in dark mode, making it difficult for users to read.

After this commit:
The technical name is now clearly visible in dark mode.

Task-4680365

Forward-Port-Of: odoo/enterprise#82429

Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934 Forward-Port-Of: odoo/enterprise#83903

Steps to reproduce:
- insert a pivot into a spreadsheet
- add the dynamic pivot somewhere with the formula =PIVOT(1)
- right click on the values and sort them
- open the side panel
- update anything (e.g. the domain)

=> the sorting is dropped.

Since commit 93ffeeefe86, measures are identified with the `id` property, not the name.

Task: 4746057
opw-4741934

Forward-Port-Of: odoo/enterprise#83903

Steps: - duplicate a worksheet template - add a field on the new template - print the original template --> error : field doesn't exist on original worksheet model Current behaviour: Duplicating a worksheet template creates a new model, but the _generate_qweb_report_template method doesn't create a new view for the new template because we copied the original one. It also removes the customizations on the original template's view New behaviour: A new view is created for the dupli

Steps:
- duplicate a worksheet template
- add a field on the new template
- print the original template
--> error : field doesn't exist on original worksheet model

Current behaviour:
Duplicating a worksheet template creates a new model, but the
_generate_qweb_report_template method doesn't create a new view
for the new template because we copied the original one.

It also removes the customizations on the original template's view

New behaviour:
A new view is created for the duplicated template and remove the
duplicate option from the list view, as it is already hidden in
form view

opw-4664600
opw-4656835

Forward-Port-Of: odoo/enterprise#83529
Forward-Port-Of: odoo/enterprise#83166

In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885

In this PR we add the following wage types:
- Complementary LPP
- Alimony Deduction
- Deduction for prosecution office

Forward-Port-Of: odoo/enterprise#83885

**Steps to reproduce:** - Install Accounting - In Bank journal settings, make sure that there's no Outstanding Payments account - Create a bill for a customer - Confirm it - Create a second bill for the same customer - Confirm it - Go to the bills list - Select the 2 created bills - Create a payment via "Pay" button: * Journal: Bank * Payment Method: Manual Payment * Group Payments: [checked] - Do not validate the payment - Go to "Accounting / Vendors / Payments" - Selec

**Steps to reproduce:**
- Install Accounting
- In Bank journal settings, make sure that there's no Outstanding Payments account

- Create a bill for a customer
- Confirm it
- Create a second bill for the same customer
- Confirm it

- Go to the bills list
- Select the 2 created bills
- Create a payment via "Pay" button:
  * Journal: Bank
  * Payment Method: Manual Payment
  * Group Payments: [checked]
- Do not validate the payment
- Go to "Accounting / Vendors / Payments"
- Select the created payment and create a batch
- Validate the batch payment => The payment status of both bills is "In Payment"

- From Accounting dashboard, go to transactions of Bank journal (reconciliation widget)
- Create a new transaction for the previous customer with the amount of the batch payment
- In the reconciliation widget, go to "Batch Payments" tab
- Select the created batch payment
- Validate to reconcile
- Check the bills list

**Issue:**
Only one of the bills has its payment status set to "Paid", the other one staying in "In Payment" status.

**Cause:**
In the method that checks which account move lines are included in the batch payment, we loop on each linked move line and take the "min" between the remaining amount of the batch payment and the amount of the move line until the remaining amount reaches 0.
However, for vendor bills, these amounts are negative and taking the "min" amount returns the remaining amount directly, resulting in only having 1 move line set to reconcile.

opw-4595006

Forward-Port-Of: odoo/enterprise#83634

Fix certificate generation for AR companies when other LATAM countries are installed. opw-4584457 Forward-Port-Of: odoo/enterprise#82527

Fix certificate generation for AR companies when other LATAM countries are installed.

opw-4584457

Forward-Port-Of: odoo/enterprise#82527

The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the setTimeout(() => this.initializeIframe(), 1); interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`. I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" th

The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the

    setTimeout(() => this.initializeIframe(), 1);

interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.

I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...

https://runbot.odoo.com/odoo/error/181583

Forward-Port-Of: odoo/enterprise#83937

-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026

-- How to reproduce --
Duplicate two or more belgian employees.

-- Reason --
The sdworx code check constraint was wrongly single record.

-- Fix --
This commit fixes the issue by converting the check to multi records.

task-4708324

Forward-Port-Of: odoo/enterprise#83852
Forward-Port-Of: odoo/enterprise#83026

Coming From: https://github.com/odoo/enterprise/pull/69708 Forward-Port-Of: odoo/enterprise#83789

Coming From: https://github.com/odoo/enterprise/pull/69708

Forward-Port-Of: odoo/enterprise#83789

Steps: - Go to Payroll > Salary Structures > Stipend > Net. - Check 'Python Code' in Computation. - Generate payslip and check accounting/payment entries. Issue: - Net salary rule did not include the GROSS category. - Net salary rule includes the BASIC category which is unnecessary. - Stipend amount was not reflected in reports and COA entries. Fix: - Removed the 'BASIC' amount calculation to the net salary rule for the stipend. - Added the 'GROSS' amount calculation to the net sal

Steps:
- Go to Payroll > Salary Structures > Stipend > Net.
- Check 'Python Code' in Computation.
- Generate payslip and check accounting/payment entries.

Issue:
- Net salary rule did not include the GROSS category.
- Net salary rule includes the BASIC category which is unnecessary.
- Stipend amount was not reflected in reports and COA entries.

Fix:
- Removed the 'BASIC' amount calculation to the net salary rule for the stipend.
- Added the 'GROSS' amount calculation to the net salary rule for the stipend.
- Ensured that stipend amounts are included in reports and COA by updating the net salary rule logic.

Task - 4668024

Forward-Port-Of: odoo/enterprise#83123

*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi 1. fix the summary of account.move.send.batch.wizard The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened). We al

*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi

1. fix the summary of account.move.send.batch.wizard

The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened).

We also always put email as a fallback, even if no email is set, since it can be added through the wizard.

2. fix batch send of Peppol invoices when no format set

In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent.

[1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad

3. Remove 'skipped' state of Peppol moves

This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error.

task-no (review with TSB and PMAX)

Forward-Port-Of: odoo/enterprise#83750
Forward-Port-Of: odoo/enterprise#83443

The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029

The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible.

This PR fixes the issue by not copying the value of those field upon duplication.

task-4708324

Forward-Port-Of: odoo/enterprise#83029

Since we didn't wait for synchronization when clicking on the order button, tours are too fast and the response from the server isn't received in time. This commit adds a wait to ensure that the synchronization is complete before proceeding with the next step. Runbot: 181579 Forward-Port-Of: odoo/enterprise#83795

Since we didn't wait for synchronization when clicking on the order button, tours are too fast and the response from the server isn't received in time. This commit adds a wait to ensure that the synchronization is complete before proceeding with the next step.

Runbot: 181579

Forward-Port-Of: odoo/enterprise#83795

In this PR we modify the gantt_model to only display 1 day/week/month at a time Forward-Port-Of: odoo/enterprise#83505

In this PR we modify the gantt_model to only display 1 day/week/month at a time

Forward-Port-Of: odoo/enterprise#83505

This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643 Forward-Port-Of: odoo/enterprise#82526 Forward-Port-Of: odoo/enterprise#78048

This commit modifies Elvera and Roque demo data for hr mexican localization

target: 17.0 -> master
task-4486643

Forward-Port-Of: odoo/enterprise#82526
Forward-Port-Of: odoo/enterprise#78048