[FIX] hr_payroll: fix payslip warning bug

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#109791

… sheet

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.

opw-5883505

Forward-Port-Of: odoo/enterprise#111328

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Last Test Update:
    1 - I noticed that contract date changes was not affecting the warning appearance directly
    2 - Unit test is expanded with contract date change and observing the warning appearance

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758

In version 19.1, an error occurs when inviting a new user via General Settings and then clicking Manage Users:
"The operation cannot be completed: A user cannot be linked to multiple employees in the same company."

This happens even when logged in as an admin user with an existing linked employee. The issue stems from the `employee_id` field in the `res_users` model being a context-dependent computed field.

The `self.env.cache` lacks the employee data,
specifically `'res.users.employee_id': {(1, (2, True)): {2: None}}`.

To resolve this, i've used invalidate_recordset for proper clean the cache,
and again get the value of employee_id.

Clicking directly on "Manage Users" sometimes we cannot face an error, possibly a caching issue.
Inviting a user before accessing "Manage Users" results in an error,

<img width="1885" height="964" alt="2026-03-25_16-21" src="https://github.com/user-attachments/assets/8cd7d094-b0ce-42ca-a43f-1081de7ddc70" />

[opw-6041866](https://www.odoo.com/odoo/project/70/tasks/6041866)
[upg-4031096](https://upgrade.odoo.com/odoo/request/4031096)

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

**Steps to reproduce:**
* Install the *Purchase* module
* Create a product and set an *Reference* and
  Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*.
* Create a Purchase Order with the same vendor set as on the product.
* Add the configured product to the *Purchase Order Lines*.
* Add the same product again on a second line and save the order.
* Activate debug mode
* Go to the view:Form and add a limit to have only 1 POL per page
* Return to your PO
* Go to the second page

**Observed behavior:**
* The *product display name* in the purchase order lines is different on
  the second page compared to the first page.

**Cause:**
* On the first page, purchase order lines are fetched via a web_read on the
purchase order.
* On subsequent pages, lines are fetched via a web_read directly on the
purchase order lines.
* The client requests both name and product_id.display_name.
product field context includes partner_id, causing
product_id.display_name to be computed as the vendor name.
* As both values resolve to the vendor name, the original product
name is lost, leading to inconsistent display across pages.

**Note:**

A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36
* but its consequence it breaks the search using the vendor code/name in POL.

* That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d

**Fix:**
* This ensures the product name is propagated correctly in the form
view while preserving search by vendor code or name.

---

opw-5170924

Forward-Port-Of: odoo/odoo#258467
Forward-Port-Of: odoo/odoo#240515

Steps to produce:
---
- Install `Sales` module.
- Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab.
- Confirm the sale order and create an invoice.

Issue:
---
- In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00.

Root cause:
---
- Here at [1], the record name is False because the invoice is still in draft state.
- In [18], _sync_invoice sets amount_currency = line.balance for new
  lines, but balance is precomputed as 0 before the INSERT because
  _compute_balance returns 0 for invoice lines. In [17] it read
  price_subtotal directly, which is always correct.
- In 17.0 the same mail fires at the same moment, but _sync_invoice
  had already set balance = −295 and amount_currency = −295 from
  price_subtotal, so the email reads the correct 295.00.

Solution:
---
- Use record.display_name instead of record.name, as display_name is always present regardless of the record state.
- Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices.

[1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478
[18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610
[17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585


Before:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" />

After:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" />


opw-6023827
---

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

Forward-Port-Of: odoo/odoo#258375
Forward-Port-Of: odoo/odoo#254862

### Issue before this commit:
When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language.

### Steps to reproduce the issue:
1. Activate at least 2 languages (X and Y)
2. Create a product and set the translation for that product in the activated languages
3. Create a Contact with the language X
4. Create a child contact (invoice adress type) for that contact with language Y
5. Create a new invoice setting the customer as the child contact
6. Add the product you created
7. See the label is displayed in the language of the parent contact

### Cause of the issue:
The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language.

### Reason to introduce the fix:
To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner.

opw-5955875

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

Forward-Port-Of: odoo/odoo#258458
Forward-Port-Of: odoo/odoo#254833

Steps to produce:
---
- Install the `E-commerce` module.
- Configure a product with a very large price.
- Open the product on the website, add it to the cart, and navigate to the cart.

Issue:
---
- The quantity input group appears visually stretched, and the border rendering is inconsistent.

Root Cause:
---
- After upgrading from Bootstrap 5.1 to 5.3, border utility behavior changed. Classes like `border-end-0` no longer apply unless a base border class is also present.

Solution:
---
- Explicitly add the `border` class alongside `border-end-0` on the affected elements to restore the intended border styling.

Before:
---
<img width="822" height="185" alt="image" src="https://github.com/user-attachments/assets/6478083e-f5c1-4374-9c9a-979254eaee3d" />

After:
---
<img width="828" height="188" alt="image" src="https://github.com/user-attachments/assets/5a1cb138-c9a5-4508-ad34-64d988904407" />


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

Forward-Port-Of: odoo/odoo#258572
Forward-Port-Of: odoo/odoo#256797

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
  to use the `domain` engine:
  `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
  with subformula `-sum`.
  This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
  which covers the standard year-end affectation workflow.

opw-5883505

Forward-Port-Of: odoo/odoo#253559

# How to reproduce
- Go to Website app > Configuration > Websites > Select your website > Custom Code
- In the "Custom <head> code" section add the script given at the last section of this PR (with a proper TAG_ID)
- Go to a new Incognito Tab and go to the Website front page
- Refuse the optionnal cookies
- Open the browser's console and go to Application > Storage > Cookies

# The problem
The Google Ads cookies are present (prefixed by _ga)

# Why
This commit introduced the blocking of 3rd party cookies :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1

It works by doing 2 things, but none of them works in our case :

First, it edits the view rendering to replace the `src` value with "about:blank" for watched
tags, but this does not work for `website.custom_code_head` (our case) and `website.custom_code_footer` because it is t-out'ed which bypasses this code :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-a27798e1ecfe96676dd48766e0aa9d12fbc0784e328ac1a3ec82b1ce199fc58bR121-R166

Second, it adds a script in the head of the page that patches the setter for the `src`
property of the script tags. If the value that we try to set is a URL to a site that we
block and the cookies are not yet accepted, we replace the `src` value with "about:blank".

https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/website/static/src/js/content/cookie_watcher.js#L8

This sadly does not work for parser-inserted scripts that are directly parsed from the HTML.
Indeed, they do not use the setter of `HTMLScriptElement.prototype`.

It is possible to verify this by adding a `MutationObserver` that checks for new script
insertions and adding breakpoints in this observer and in the patched setter. For the
first scripts of the page, the breakpoint in `MutationObserver`is triggerred while the
 one in the setter is not.

# Proposed solution
We move this code into new helper functions :
https://github.com/odoo/odoo/blob/95dc247ecd773044ef9c9f1512c7d86d73df836c/addons/website/models/ir_qweb.py#L130-L135

And use these helper functions to create another helper function that allows us to check
an html field for trackers that would need to be removed

We then use this helper function on `website.custom_code_head` and `website.custom_code_footer`

# The script
```html
<!-- Google tag (gtag.js) -->
  <script async src="[https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script](https://www.googletagmanager.com/gtag/js?id=TAG_ID%22%3E%3C/script)>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'TAG_ID');
  </script>
```
Source : https://developers.google.com/tag-platform/gtagjs

opw-6007810

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

Forward-Port-Of: odoo/odoo#256808

Description of the issue/feature this PR addresses:

During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet.

But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine.

Current behavior before PR:

Logs may contain warnings such as:

- Patching res.partner.ref with company_dependent=True
- Patching product.template.sale_ok with company_dependent=True
- Patching product.product.default_code with company_dependent=True

even though there is no actual issue (ok normal behavior)

The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine.

Desired behavior after PR is merged:

Keep the same mechanism, but lower the log level from WARNING to DEBUG.
This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG.
Having the production branches green.



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

Forward-Port-Of: odoo/odoo#258444
Forward-Port-Of: odoo/odoo#258326

**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.

**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.

**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.

**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.

opw-6099340

Forward-Port-Of: odoo/odoo#258750
Forward-Port-Of: odoo/odoo#258006

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#256658
Forward-Port-Of: odoo/odoo#255780

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023

Forward-Port-Of: odoo/odoo#258520
Forward-Port-Of: odoo/odoo#247091