#### Description of the issue/feature this PR addresses: When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval) that may have been requested by an employee. These virtual leaves that ar

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

When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval)  that may have been requested by an employee. These virtual leaves that are not yet approved should not count towards the calculation since it could be possible that the employer could refuse them or the employee's accrual plan could grant sufficient leaves if it is requested for a future date.


#### Current behavior before PR:

1. Setup a timeoff type that requires approval from the manager
2. Set up an accrual plan where an employee accrues '_N_' days of leave at the start of each year with **no carryover** (NOTE: the no carryover is the most crucial step because this is what writes the number_of_days on the leave allocation to zero)
3. Request a leave by an employee for any date after the carryover period.

What should have happened: The accrual should reset the leaves based on no carryover policy back to _N_ days 
However, it throws a validation error:

Now the issue happens because when we see that the carryover is none because of which:
1. The allocated leaves are set to 0 when calling this CRON (for no carryover): https://github.com/odoo/odoo/blob/cf18c4ac88919513a9f2b922d625fa5dc113cb39/addons/hr_holidays/models/hr_leave_allocation.py#L527
2. The leave that was requested by the employee but not yet approved causes the validation to fail. It is best explained in the below screen recording which uses the test case mentioned in the commit:

https://github.com/user-attachments/assets/f8914bac-815d-48c9-b4b2-c132a2fccbdb

![image](https://github.com/user-attachments/assets/cc2e221d-a725-4e9e-aaee-a054f644dff6)
![image](https://github.com/user-attachments/assets/8522bc81-5416-4bf0-ac71-bea1d2a133b8)


#### Desired behavior after PR is merged:

Virtual Leaves that are not yet approved would not block us from updating the allocation's `number_of_days`

opw-4442471

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

Forward-Port-Of: odoo/odoo#198382

Commit [1] introduced tests that fail when they are run without demo data. The difference comes from the fact that the demo user has different rights when obtained from demo data or when generated by `HttpCaseWithUserDemo`. Investigating this failure has put in light a combination of other mistakes: - the rights on the user used for the test were not the expected ones: asserts have been added to make sure the scenario matches the expectation - the URL of the partner that was given to `start_to

Commit [1] introduced tests that fail when they are run without demo data. The difference comes from the fact that the demo user has different rights when obtained from demo data or when generated by `HttpCaseWithUserDemo`. Investigating this failure has put in light a combination of other mistakes:
- the rights on the user used for the test were not the expected ones: asserts have been added to make sure the scenario matches the expectation
- the URL of the partner that was given to `start_tour` was actually ignored on the Javascript side which redirected to the home page
- the test miraculously passed on the home page because the combination of rights of the patched demo user worked for publishing a page (which is not what was supposed to be tested)
- while fixing the test, it was noticed that the `_compute_can_publish` method that was updated in [2] was actually run in sudo for the specific scenario of the test, because it is obtained during the rendering of a QWeb template which reads `can_publish` to fill the `html_data` structure, while the `main_object` is a sudoed `res.partner` in order to be able to display some of its fields within the page, which leads to accesses always being considered as granted

This commit fixes this by:
- un-sudoing the records in `_compute_can_publish` in order to properly check for access rights
- starting the test tours from a `/partners` and adding a step to browse to the specific partner page
- assigning a level to the test partner so that it appears in the `/partners` page

[1]: https://github.com/odoo/odoo/commit/dbed390e645c93de1145662e9e00938fed984b5f
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da

task-3175890
runbot-114278
runbot-114279
runbot-114281
runbot-114283
runbot-114287
runbot-114289

Forward-Port-Of: odoo/odoo#200021
Forward-Port-Of: odoo/odoo#199462

Lately we have been encountering increasing issues with on-prem databases which are being duplicated without running neutralization scripts, and thus when one of the two instances renews its refresh token, the other database's refresh token gets out of sync and we end up with a cryptic error `Invalid signature for request to the account_edi proxy`. 1. Prod and Staging both have refresh token RT1 2. Staging needs new refresh token: sends RT1 to IAP and gets RT2 3. IAP invalidates RT1 4. Pro

Lately we have been encountering increasing issues with on-prem databases which are being duplicated without running neutralization scripts, and thus when one of the two instances renews its refresh token, the other database's refresh token gets out of sync and we end up with a cryptic error `Invalid signature for request to the account_edi proxy`.

1. Prod and Staging both have refresh token RT1
2. Staging needs new refresh token: sends RT1 to IAP and gets RT2
3. IAP invalidates RT1
4. Prod still has RT1 and tries to refresh
5. IAP rejects RT1 because it is no longer aware of RT1
6. Test cannot get a new token and loses access with this error as the signature is no longer valid

This commit simply improves this error message and redirects users to odoo support.

task-4531587

Forward-Port-Of: odoo/odoo#196271

How to reproduce: ============== - ​Have Marc Demo work in another sales team that yours. - ​Go to a kanban view of leads, grouped by salesperson. - ​Quick create a new lead. Current behavior: ============= ​It gets assigned to your team, probably because the default value is not properly updated. Expected behavior: ============== - ​The lead belongs to Marc and should be linked to his team. - ​It works fine if you do it from the form view. task-4438021 --- I confirm I hav

How to reproduce:
==============
- ​Have Marc Demo work in another sales team that yours.
- ​Go to a kanban view of leads, grouped by salesperson.
- ​Quick create a new lead.

Current behavior:
=============
​It gets assigned to your team, probably because
the default value is not properly updated.

Expected behavior:
==============
- ​The lead belongs to Marc and should be linked to his team.
- ​It works fine if you do it from the form view.

task-4438021

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

Forward-Port-Of: odoo/odoo#192934

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

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

- Incorrect "Sent" Status: When generating the XML with the UBL checkbox selected but without checking the Nilvera option, the move was incorrectly marked as "Sent" (is_move_sent). This behavior has been corrected. - Traceback During Send and Print with Nilvera: In the flow where the XML is first generated with UBL, and then the Send and Print action is performed with Nilvera, a traceback appeared since the ubl_cii_xml_attachment_values was not in the invoice_data anymore. Also Nilver

- Incorrect "Sent" Status:
When generating the XML with the UBL checkbox selected but without checking the
Nilvera option, the move was incorrectly marked as "Sent" (is_move_sent).  This
behavior has been corrected.

- Traceback During Send and Print with Nilvera:
In the flow where the XML is first generated with UBL, and then the Send and
Print action is performed with Nilvera, a traceback appeared since the
ubl_cii_xml_attachment_values was not in the invoice_data anymore.
Also Nilvera didn't accept the xml because they needed the issues date of the
document to accept it.

- City Name and Subdivision Inversion in XML
The values in the CitySubDivisionName and CityName elements of the XML were
inverted. This has been corrected to align with the expected structure.

task-4457092



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

Forward-Port-Of: odoo/odoo#192733

Steps to reproduce: - Create a Vendor Bill with 10% ND tax - Post - In 'Edi Documents' tab download e-invoice Issue: `CuotaIVADeducible` element show the full tax amount, even if the tax has been set to non deductible opw-4582712 Forward-Port-Of: odoo/odoo#200157

Steps to reproduce:
- Create a Vendor Bill with 10% ND tax
- Post
- In 'Edi Documents' tab download e-invoice

Issue: `CuotaIVADeducible` element show the full tax amount, 
even if the tax has been set to non deductible

opw-4582712

Forward-Port-Of: odoo/odoo#200157

Steps to reproduce the bug: - Install POS, then uninstall the sms gateway - Open a shop and then click on customers button - write anything in the input field then click on `Search More` Problem: Error is raised in the request because the `partner_list.js` screen is passing the field `phone_mobile_search` in the search_fields. The `phone_mobile_search` field is only introduced to the res.partner model in the a PhoneMixin and the inheritence is only applied in the `sms gateway module` s

Steps to reproduce the bug:
 - Install POS, then uninstall the sms gateway
 - Open a shop and then click on customers button
 - write anything in the input field then click on `Search More`

Problem:
Error is raised in the request because the `partner_list.js` screen is passing the field `phone_mobile_search` in the search_fields. The `phone_mobile_search` field is only introduced to the res.partner model in the a PhoneMixin and the inheritence is only applied in the `sms gateway module` so the field will only be available if the `sms gateway is installed`.

Possible Approaches:
- [18.0 fix] added a function in the partner_list.js that tells if the PhoneMixin is applied and it returns false in the pos, and overriden the same function in the pos_sms bridge module that implies that both pos and sms are installed and it returns true there meaning the mixin is applied.
- [16.0, 17.0 fix] changed the search filter to use phone, mobile attributes. this will lose the phone_mixin searching features. we don't have a pos_sms bridge module in these versions so the workaround in 18.0 can't be applied
- [Non Stable, master fix] add the inheritence of the mixin in the pos module, but that will require module upgrade
- [Non Stable] add a whole direct dependency between the pos and the sms gateway

opw-4455381

Description of the issue/feature this PR addresses:

Current behavior before PR: Search More button in the partner list in POS is not working if the sms module is uninstalled

Desired behavior after PR is merged: `Search More` button in partner list in POS is working whatever sms is installed or not




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

Forward-Port-Of: odoo/odoo#199041
Forward-Port-Of: odoo/odoo#196787

**Behavior before PR:** When removing format using removeFormat button, font-size style is not getting removed from formatted text. This happens because in `removeFormat` method `editor.document.execCommand('removeFormat')` fails to remove styles applied through classes. To remove these styles, font-size classes should be removed. **Behavior after PR is merged:** Now font-size related classes will be removed when removing format and font-size style will be removed from formatted text.

**Behavior before PR:**

When removing format using removeFormat button, font-size style is not getting removed from formatted text. This happens because in `removeFormat` method `editor.document.execCommand('removeFormat')` fails to remove styles applied through classes. To remove these styles, font-size classes should be removed.

**Behavior after PR is merged:**

Now font-size related classes will be removed when removing format and font-size style will be removed from formatted text.

task-4526026




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

Forward-Port-Of: odoo/odoo#195979

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#198993

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it.

We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task.

[1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03

task-3792478

Forward-Port-Of: odoo/odoo#198993

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#200123 Forward-Port-Of: odoo/odoo#198994

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it.

We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task.

[1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03

task-3792478

Forward-Port-Of: odoo/odoo#200123
Forward-Port-Of: odoo/odoo#198994

It is possible to add note / section lines with empty label (`name`). Currenlty we then print placeholder values: * section: `A section title` * note: `A note, whose content usually applies to the section or product above.` (They were added to be displayed in studio; see commit 2fbf17d235fb7c92914f0a3b6a3ce954c27f3032.) After this commit the placeholders will not be printed on PDFs anymore. (But they will still be shown in studio.) task: none Forward-Port-Of: odoo/odoo#200154

It is possible to add note / section lines with empty label (`name`). Currenlty we then print placeholder values:
  * section: `A section title`
  * note: `A note, whose content usually applies to the section or product above.` (They were added to be displayed in studio; see commit 2fbf17d235fb7c92914f0a3b6a3ce954c27f3032.)

After this commit the placeholders will not be printed on PDFs anymore. (But they will still be shown in studio.)

task: none

Forward-Port-Of: odoo/odoo#200154

In commit 2f62d5c0d78371be70586c79cb2b5931e733b042 the issue was fixed for some cases. But the problem remains in some other cases. In the original fix a special context value was added to the reconciliation of some lines. It prevents the creation of cash basis related moves for that reconciliation. This commit adds the same context to all the other reconciliations in the same function as the original reconciliation. Reproduce on runbot for l10n_mx for bank payment method 1. Install l1

In commit 2f62d5c0d78371be70586c79cb2b5931e733b042 the issue was fixed for some cases.

But the problem remains in some other cases.

In the original fix a special context value was added to the reconciliation of some lines. It prevents the creation of cash basis related moves for that reconciliation. This commit adds the same context to all the other reconciliations in the same function as the original reconciliation.

Reproduce on runbot for l10n_mx for bank payment method
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS 
    * Payment method: Bank on journal BNK1
    * Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Bank payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
   ```
    * 1 entry in the POS journal (order)
       base:       | - 100.0 $
       tax:        | -  16.0 $
       receivable: | + 116.0 $
     * 1 entry in the BNK1 journal (bank / payment)
       bank:       | + 116.0 $
       receivable: | - 116.0 $
     * 1 entry in the CBMX journal (caba)
       base:       | - 100.0 $
       base:       | + 100.0 $
       tax:        | -  16.0 $
       tax:        | +  16.0 $
     * 1 entry in the EXCH journal (exchange difference)
       for the cash basis rounding difference
       tax:        | -  16.0 $
       tax:        | +  16.0 $
   ```
opw-4355124

Forward-Port-Of: odoo/odoo#199194

Problem: When the user views the SLA tickets through the action, action_view_success_rate, they will only see successful SLA tickets after removing the 'SLA success' filter. Purpose: The user should be able to see all SLA tickets, successful and failed, after removing filters. Steps to Reproduce on Runbot: 1. Install Helpdesk 2. Navigate to Helpdesk and click on 'Success Rate' for Customer Care team 3. Remove filter 'SLA success' 4. Observe that failed SLA tickets doesn't display op

Problem: When the user views the SLA tickets through the action, action_view_success_rate, they will only see successful SLA tickets after removing the 'SLA success' filter.

Purpose: The user should be able to see all SLA tickets, successful and failed, after removing filters.

Steps to Reproduce on Runbot:
1. Install Helpdesk
2. Navigate to Helpdesk and click on 'Success Rate' for Customer Care team
3. Remove filter 'SLA success'
4. Observe that failed SLA tickets doesn't display

opw-4601178

Forward-Port-Of: odoo/enterprise#80087

The SAT added a new type of transport figure "Integrante de Coordinados". This should be available for the carta porte. task-4082068, previous pr for v15 67897 Forward-Port-Of: odoo/enterprise#77932 Forward-Port-Of: odoo/enterprise#73195

The SAT added a new type of transport figure "Integrante de Coordinados". This should be available for the carta porte.

task-4082068, previous pr for v15 67897

Forward-Port-Of: odoo/enterprise#77932
Forward-Port-Of: odoo/enterprise#73195

### Steps to reproduce: - Open a Helpdesk ticket - Send message on this ticket - Duplicate this ticket - Go to Reporting > Ticket Analysis - Check 'Hours to First Response' value for the duplicated ticket ### Cause: Those fields of response hours are being copied when duplicating tickets. ### Fix: We added 'copy=False' to each of those fields definition so we don't duplicate those fields when duplicating a record. opw-4582995 Forward-Port-Of: odoo/enterprise#80562

### Steps to reproduce:
	- Open a Helpdesk ticket
	- Send message on this ticket
	- Duplicate this ticket
	- Go to Reporting > Ticket Analysis
	- Check 'Hours to First Response' value for the duplicated ticket

### Cause:
Those fields of response hours are being copied when duplicating tickets.

### Fix:
We added 'copy=False' to each of those fields definition so we don't duplicate those fields when duplicating a record.

opw-4582995

Forward-Port-Of: odoo/enterprise#80562

Problem ---------- Amendments to PAYE computation from 27 Dec 2024 Objective ---------- Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024 Solution ---------- Adapt rules and parameters task-4457038 Forward-Port-Of: odoo/enterprise#79582

Problem
----------
Amendments to PAYE computation from 27 Dec 2024

Objective
----------
Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024

Solution
----------
Adapt rules and parameters

task-4457038

Forward-Port-Of: odoo/enterprise#79582

Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhanc

Versions:
-----------
- 17.0

Steps to reproduce:
-------------------------
- go to timesheet module
- click on grid cell

Issue:
-------
The action helper in web grid was resulting in only the web content being
displayed in the timesheet grid and so helper was missing

Cause:
---------
The action helper was being called from web_grid, causing a lack of content in
the timesheet_grid.

Solution:
-----------
Create a dedicated function to retrieve the no-content helper, enhancing
portability for easy customization.

task-3429403

Forward-Port-Of: odoo/enterprise#56158

Issue: When the user tries to create a contact from the approval form, they get a "Missing Record" error. Steps to reproduce: - Install the Approvals app - Create a new Approval Type with Contact set as either 'Required' or 'Optional' - When creating a new Request from the created Type, try to create a new Contact Cause: Both Approvals and Partners have a 'category_id' field. In the approval form, the context has the approval's value for 'category_id', which is being used for the part

Issue:
When the user tries to create a contact from the approval form, they get a "Missing Record" error.

Steps to reproduce:
- Install the Approvals app
- Create a new Approval Type with Contact set as either 'Required' or 'Optional'
- When creating a new Request from the created Type, try to create a new Contact

Cause:
Both Approvals and Partners have a 'category_id' field. In the approval form, the context has the approval's value for 'category_id', which is being used for the partner creation.

Solution:
In the approval form view, change the context used by the partner field to not have a default 'category_id'.

Ticket:
opw-4328371

Forward-Port-Of: odoo/enterprise#74579

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/enterprise#80654 Forward-Port-Of: odoo/enterprise#80034

Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it.

We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task.

[1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03

task-3792478

Forward-Port-Of: odoo/enterprise#80654
Forward-Port-Of: odoo/enterprise#80034

…versing Steps to reproduce: - In settings, set a default "Default invoice transaction code" and "Default refund transaction code" - Create an invoice with an invoice line and post it - Reverse it Issue: - The intrastat code will be the one from the invoice (and not the default refund one) Cause: When copying the lines we keep the one from the invoice Solution: Delete the default values when copying the data so the compute is triggered correctly which will set the correct value

…versing

Steps to reproduce:
- In settings, set a default "Default invoice transaction code" and "Default refund transaction code"
- Create an invoice with an invoice line and post it
- Reverse it

Issue:
- The intrastat code will be the one from the invoice (and not the default refund one)

Cause:
When copying the lines we keep the one from the invoice

Solution:
Delete the default values when copying the data so the compute is triggered correctly which will set the correct value

opw-4417566

Forward-Port-Of: odoo/enterprise#79267

This PR adapts access rights so that Worldline folder 'ctep' can be deleted by 'delete_iot_handlers' Forward-Port-Of: odoo/enterprise#80283

This PR adapts access rights so that Worldline folder 'ctep' can be deleted by 'delete_iot_handlers'

Forward-Port-Of: odoo/enterprise#80283