When a POS order is invoiced after its session has been closed, `_create_misc_reversal_move` builds a misc entry that reverses the portion of the closing entry corresponding to that order. It does so by negating `balance` and `amount_currency` on every prepared line, but leaves `tax_base_amount` on tax lines untouched.

As a result the reversal move ends up with tax lines whose `balance` sign is flipped relative to the source order while `tax_base_amount` keeps the source sign, breaking the invariant
`sign(balance) == sign(tax_base_amount)` that holds for every other correctly-generated tax line in the system.

Downstream, any report reading `tax_base_amount` directly (Audit view from the Tax Report, Journal Items XLSX export, custom exports) shows a base amount signed for the wrong direction alongside a debit/credit of the opposite sign, which is confusing and, for tax returns computed from `tax_base_amount`, incorrect.

Negate `tax_base_amount` alongside `balance` and `amount_currency` so the reversal move stays internally consistent.

opw-5975658

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

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

Forward-Port-Of: odoo/odoo#277067
Forward-Port-Of: odoo/odoo#269496

Description of the issue/feature this PR addresses:
A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one.

Current behavior before PR:
- Enable Multi-Companies in the settings.
- Create a second company (Company B).
- Open Accounting > Configuration > Cash Roundings.
- Create a cash rounding with strategy "Add a rounding line" and precision 1.00.
- Make Company A the active company in the company switcher.
- Set the cash rounding's profit and loss accounts to Company A accounts.
- Switch the active company to Company B.
- Set the cash rounding's profit and loss accounts to Company B accounts.
- Make Company A the active company again, keeping both companies active.
- Create a customer invoice for Company B.
- Add one invoice line whose total is not a multiple of the rounding precision.
- Set the invoice's cash rounding to the one above.
> Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B.

Desired behavior after PR is merged:
The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany.




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

Forward-Port-Of: odoo/odoo#278401
Forward-Port-Of: odoo/odoo#273410

[FIX] website_hr_recruitment: fix country filter

Bug reproduction:
    1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
    2 - Go to job page in website, activate country filter.
    3 - Select US jobs and search for the remote job.
    4 - All countries filter is readonly and it is not pressable.

Bug cause:
    1 - Check is done with jobs value
        1.1 - If no matching, readonly button is displayed.

Bug solution:
    1 - count_per_filter is used instead of jobs
        1.1 - Even there are matchings for other countries, it shows.
    2 - Also, searched keyword is added to filter url
        2.1 - When there is search in other country and we click to it:
            2.2 - The searched keyword will be still there.

task-6284436

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

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Forward-Port-Of: odoo/odoo#277822
Forward-Port-Of: odoo/odoo#276861

**Problem:**
For an hour-based time off allocation, changing the employee's working schedule leaves the allocation duration (in days) stale, so the balance shown on the Time Off dashboard becomes wrong.

**Steps to reproduce:**
1. Give an employee a working schedule of 8 hours/day.
2. Create an hour-based allocation (time off type with Request Unit = Hours) granting e.g. 8 hours (1 day).
3. Change the employee's working schedule to one with a different Hours per Day (e.g. 4 hours/day).
4. Check the allocation / the Time Off dashboard balance.

**Current behavior:**
number_of_days stays at its old value (1), so the balance is recomputed as 1 day x 4 hours = 4 hours instead of the 8 hours actually accrued.

**Expected behavior:**
The accrued hours stay constant; the duration in days follows the new schedule (8 hours / 4 hours-per-day = 2 days).

**Cause of the issue:**
`number_of_days` and `number_of_hours_display` compute from each other (`number_of_days = number_of_hours_display / hours_per_day` and `number_of_hours_display = number_of_days * hours_per_day`), forming a dependency cycle, and neither depends on the employee's working schedule. So a schedule change never recomputes either field. Adding the schedule to `_compute_number_of_days`' depends does not help: because of the cycle it recomputes `number_of_hours_display` from the stale `number_of_days` first, which silently destroys the accrued hours.

**Fix:**
When the employee's working schedule changes, the accrued hours are the quantity that must be preserved, so the duration is recomputed explicitly from the still-stored `number_of_hours_display` (setting `number_of_days` first, exactly as a manual `_compute_number_of_days()` does). Driving the order by hand is necessary because the cyclic compute graph cannot guarantee `number_of_days` is computed before `number_of_hours_display`.

opw-6276242

Forward-Port-Of: odoo/odoo#270129

Commit: odoo/odoo@2406a96765cc76de94d356dfd3b27cf98de82d7 made the computation of related fields go through `sudo()` unconditionally, to keep cache consistency with x2m related fields, which are themselves fetched in sudo.

That override, however, applies to every many2one related/inherited field, not just x2m ones, and ignores the field's own `compute_sudo` attribute. For a field with `compute_sudo=False`, the compute is still forced through `sudo()`, while every subsequent cache lookup on that field (in `Field.__get__`) is done on the non-sudo environment.

This is visible on `res.users.main_user_id`, an inherited field `res.partner.main_user_id` (compute_sudo=False, depends_context('uid')). The compute succeeds, but the resulting value is written into the sudo cache instead of the caller's cache, so the non-sudo cache check right after considers it missing:
```py
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1827, in __get__
    raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign res.users(2,).main_user_id
```
Confirmed in pdb: the id is missing from the plain cache but present in the sudo one:
```py
> /home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py(1823)__get__()
-> missing_recs_ids = tuple(self._cache_missing_ids(recs))
(Pdb) tuple(self._cache_missing_ids(recs))
(2,)
(Pdb) tuple(self._cache_missing_ids(recs.sudo()))
()
```

Steps to reproduce:
- in saas~19.3, open the Users list view
- using Studio, add the `main_user_id` field to the list view
- the view fails to load with: "The requested change caused an error in the view. It could be because a field was deleted, but still used somewhere else."
- The error in logs is the `ValueError` mentioned above

Restrict the forced `sudo()` to x2m fields, which is what the original comment describes and what actually needs it, and let many2one related fields honor their own `compute_sudo` like every other compute does.



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

Description of the issue/feature this PR addresses:

report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done inter-warehouse moves. This causes incorrect forecast values when a done stock move uses a UoM with a factor greater than 1.

Current behavior before PR:

When a done inter-warehouse move uses a UoM with factor > 1 (e.g. a box of 25 units), the forecast only subtracts the raw done quantity (e.g. 2 boxes) instead of the converted quantity in the product's base UoM (e.g. 50 units). This causes the forecast chart to show incorrect negative values before the move date.

Steps to reporduce:

- Create a storable product with base UoM = Units
- Create a UoM "Box of 25" with factor = 25 in the Units category, and add it to the product's allowed UoMs
- Create a second warehouse
- Do an inventory adjustment of 800 units into warehouse 1
- Create an inter-warehouse transfer of 2 "Box of 25" (= 50 units) from warehouse 1 to warehouse 2 and validate it
- Open the forecast chart for the product filtered to warehouse 1

Desired behavior after PR is merged:

The forecast report for done inter-warehouse moves correctly converts the done quantity to the product's base UoM using the move's UoM factor, so the forecast chart shows accurate values regardless of the UoM used on the move.


opw-6266745


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

Forward-Port-Of: odoo/odoo#273797
Forward-Port-Of: odoo/odoo#271766

Currently, sending a simplified invoice (`TD07`) to the Italian Tax
Agency fails when an invoice line contains multiple taxes.

**Steps to reproduce:**
- Install the `l10n_it_edi_withholding` module and switch to an IT Company.
- Create a new customer and set only the country to Italy and the Tax ID.
- Create a new invoice for that customer.
- Add a line with `22%` and `4% INPS` taxes.
- Go to the `Electronic Invoicing` tab, set the `Document Type` to
 `TD07 - Simplified invoice`, and confirm the invoice.
- Try to `Send To Tax Agency`.

**Error:**
`Node: <Natura t-if="line.tax_ids.l10n_it_exempt_reason" t-out="line.tax_ids.l10n_it_exempt_reason"/>`
`ValueError: Expected singleton: account.tax(102, 3)`

**Root Cause:**
At [1], the code accesses `line.tax_ids.l10n_it_exempt_reason`, but when an
invoice contains multiple taxes, causing an error.

**Fix:**
This commit prevents the error and ensures the user can send a simplified 
invoice by applying a fix similar to [2].

[1]:
https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_simplified_template.xml#L14

[2]:
https://github.com/odoo/odoo/blob/230483ffd7d8674cd6bf98a4ffb6591f755422e0/addons/l10n_it_edi/data/invoice_it_template.xml#L28-L181

Ticket [link](https://www.odoo.com/odoo/project.task/6354138)
Ticket [link](https://www.odoo.com/odoo/project.task/6379377)
opw-6354138
opw-6379377

Forward-Port-Of: odoo/odoo#278307
Forward-Port-Of: odoo/odoo#273823

Problem:
When computing inventory valuation or available quantities for a date in the past (using the  context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date.

However, when the environment context specified an ownership filter (e.g.,  to calculate company-owned valuation), this filter was only being applied to the  domain. The rollback domains for incoming and outgoing  records remained completely open.

As a result, the system would correctly see 0 company-owned current stock, but it would erroneously subtract incoming consigned stock moves from that balance. This resulted in an artificially negative past quantity and a negative inventory valuation for company-owned stock.

Solution:
This commit ensures the  context is applied symmetrically by filtering the rollback moves via the  field. The
time-travel calculation will now only evaluate stock moves that match the queried ownership context.

Steps to reproduce (runbot v19):
- Consignment enabled
- FIFO perpetual product w/ nonzero value
1. Create an inventory adjustment for an internal location, set the owner on the quant
2. Create a delivery for this product, but don't zero out all of the available stock
3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, before any move history in the db. The product's current on hand value will appear in ending stock, but negative.

opw-6300582

Forward-Port-Of: odoo/odoo#274492
Forward-Port-Of: odoo/odoo#270409

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Configure a multi-company environment with a `Main Company`
 and a `Secondary Company`
- Go to the setting enable Lots & Serial Numbers and switch into 
`Secondary Company`
- Create a warehouse for the Secondary Company
- In the Secondary Company, create a lot-tracked storable product
- Create and validate a delivery for that product
- Open the Traceability Report
- Print the report

Issue:
------
The report header always displays the Main Company, even though the
traceability report belongs entirely to the Secondary Company.

Cause:
------

https://github.com/odoo/odoo/blob/2d54db3ac0b6d807e580315e2633f3e2b10a700c/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L9

Clicking Print calls onClickPrint(), which builds the PDF URL and
downloads it with download() (a plain XMLHttpRequest POST), landing on
the `type='http'` route `/stock/<output_format>/<report_name>` 

https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L125-L134

That controller calls stock.traceability.report.get_pdf() without ever setting
 `company_id` in the rendering context.

https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/stock/controllers/main.py#L23

Inside `get_pdf()`, the report header is rendered by passing an `rcontext`
dict to `web.internal_layout`. 

That template resolves the company to display using the following priority:

https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/addons/web/views/report_templates.xml#L805-L816

  1. `company_id`  — an explicit company record in the render context
  2. `o.company_id` — the company of the document object `o`
  3. `res_company`  — the fallback, injected by `_render_template()` as
                      `self.env.company`

Because `get_pdf()` never sets `company_id` or `o` in `rcontext`, the
template always falls through to `res_company`.

https://github.com/odoo/odoo/blob/3bd6b10c3f9ad8d93062b6b46490500edb8c9697/odoo/addons/base/models/ir_actions_report.py#L770

 This is populated by `ir.actions.report._render_template()` 
as `self.env.company`, which resolves to the first company in
 the user's `allowed_company_ids` list — typically the main company 
regardless of which company owns the lot,
picking, or stock moves being printed.

As a result, the report content belongs to the secondary company while the
header always shows the main company.

Fix:
----
Resolve the company from the record on which the traceability report is
opened (using `active_model` and `active_id`) and pass it explicitly as
`company_id` when rendering the report.

`web.internal_layout` already gives precedence to an explicit
`company_id` over the default `res_company`, ensuring the report header
always displays the company that owns the traced record.

When the record has no company set, the header falls back to
`res_company`. Since the print request is a raw `type='http'` download
that never receives the company switcher's context, `user.context`
(holding `allowed_company_ids`) is now forwarded in the download POST
and merged into the environment by the controller - as done in
`web/controllers/report.py` - so the fallback resolves to the currently
active company instead of the user's default one.



<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/7e3a5d65-9114-4bce-9139-a88cff7c261f" />
  </div>

  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/0a105f80-b6ae-400d-a787-fb8706d5f519" />
  </div>
</details>

---

opw-6345446

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

Forward-Port-Of: odoo/odoo#273595

When a POS order is invoiced after its session has been closed, `_create_misc_reversal_move` builds a misc entry that reverses the portion of the closing entry corresponding to that order. It does so by negating `balance` and `amount_currency` on every prepared line, but leaves `tax_base_amount` on tax lines untouched.

As a result the reversal move ends up with tax lines whose `balance` sign is flipped relative to the source order while `tax_base_amount` keeps the source sign, breaking the invariant
`sign(balance) == sign(tax_base_amount)` that holds for every other correctly-generated tax line in the system.

Downstream, any report reading `tax_base_amount` directly (Audit view from the Tax Report, Journal Items XLSX export, custom exports) shows a base amount signed for the wrong direction alongside a debit/credit of the opposite sign, which is confusing and, for tax returns computed from `tax_base_amount`, incorrect.

Negate `tax_base_amount` alongside `balance` and `amount_currency` so the reversal move stays internally consistent.

opw-5975658

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

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

Forward-Port-Of: odoo/odoo#277067
Forward-Port-Of: odoo/odoo#269496

# How to reproduce
- In Contacts, Create a contact with name X and mail Y
- Go to the Recruitment App > Applications > All Applications
- Create a new Application with name Z, mail Y, any Job Position
- Save

# The problem
If we go back to the contact, we can see it's name changed from X to Z. This is an expect behavior since :
https://github.com/odoo/odoo/commit/c06aefa827bc00a14c9f8bd994d1831053cbf7af

The issue lies in the fact that this change to the linked partner is not logged in the Applicant's form view. This may lead to contacts being unitentionally updated.

# The cause
`hr.applicant` inherits from 'mail.track.mixin', which correctly handles the logging in the chatter when editing an Applicant. However, the edition of the contact is triggered by an inverse function when creating the record, which is not handled by the inherited module : https://github.com/odoo/odoo/blob/af50cb24ac536e6afb14eee8221c69906191ba2b/addons/hr_recruitment/models/hr_applicant.py#L248-L253

# Proposed solution
Use the `_track_record` method while tacking inspiration from : https://github.com/odoo/odoo/blob/3b5e4f558ccf9160e74e9e49ae324dd616241d61/addons/account/models/account_move_line.py#L2079

opw-6095671

[FIX] website_hr_recruitment: fix country filter

Bug reproduction:
    1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
    2 - Go to job page in website, activate country filter.
    3 - Select US jobs and search for the remote job.
    4 - All countries filter is readonly and it is not pressable.

Bug cause:
    1 - Check is done with jobs value
        1.1 - If no matching, readonly button is displayed.

Bug solution:
    1 - count_per_filter is used instead of jobs
        1.1 - Even there are matchings for other countries, it shows.
    2 - Also, searched keyword is added to filter url
        2.1 - When there is search in other country and we click to it:
            2.2 - The searched keyword will be still there.

task-6284436

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

Description of the issue/feature this PR addresses:
A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one.

Current behavior before PR:
- Enable Multi-Companies in the settings.
- Create a second company (Company B).
- Open Accounting > Configuration > Cash Roundings.
- Create a cash rounding with strategy "Add a rounding line" and precision 1.00.
- Make Company A the active company in the company switcher.
- Set the cash rounding's profit and loss accounts to Company A accounts.
- Switch the active company to Company B.
- Set the cash rounding's profit and loss accounts to Company B accounts.
- Make Company A the active company again, keeping both companies active.
- Create a customer invoice for Company B.
- Add one invoice line whose total is not a multiple of the rounding precision.
- Set the invoice's cash rounding to the one above.
> Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B.

Desired behavior after PR is merged:
The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany.




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

Forward-Port-Of: odoo/odoo#278401
Forward-Port-Of: odoo/odoo#273410

**Issue:**
When an employee uses a fully fixed duration based working schedule and each half-day attendance has a decimal duration such as 3.36h, a multi-day half-day time off request can compute a decimal duration such as 5.01 days. This is inconsistent with half-day time off types, which should consume time in half-day increments.

**Steps to reproduce:**
- Create an employee with a fully fixed duration-based schedule
- Set morning and afternoon attendances to 3.36 hours for each weekday
- Create a time off type with duration type set to half-day
- Create a time off request for the employee (e.g. Monday to Friday)
- The computed duration is 5.01 days instead of 5 days

**Cause:**
For half-day time off types, `number_of_days` was taken from generic calendar interval computation. https://github.com/odoo/odoo/blob/19c0e59cc37c7671f13cbda1b2d4850a7731eade/addons/hr_holidays/models/hr_leave.py#L585-L593 On duration-based schedules, this computation returns day values rounded at 0.001 precision, so decimal drift (e.g. 5.01) can appear, Since no final rounding to half-day steps was applied, half-day requests could end with non-half-day values.

**Solution:**
Round computed durations for half-day time off types to the nearest half-day increment.

opw-6215768

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

Forward-Port-Of: odoo/odoo#278432
Forward-Port-Of: odoo/odoo#267726

## Steps to Reproduce: _(cryptography version > 43.0.0)_
1. Install the `l10n_sa_edi` module.
2. Switch to SA Company.
3. Set the company name to an Arabic string between 32 and 64 characters. 
    (e.g; `مجموعة النخبة العالمية للاستشارات الفنية`)
5. Accounting > Configuration > Journals.
6. Open a Sales type journal.
7. Click "Re-onboard" in the ZATCA tab.
8. Enter an OTP and click "Request".

## Error:
`ValueError: Attribute's length must be >= 1 and <= 64, but it was 98`

## Cause:
The CSR validation checks the length of characters, if combined common_name (or other fields) are less than 64 characters, it passes the condition. - [1] But the cryptography library validates UTF-8 byte length for string values. Arabic characters take 2 bytes in UTF-8, causing the byte length to exceed the 64-byte limit enforced by the cryptography.

**Note:**
Starting with cryptography version 43.0.0, the library enforces the UTF-8 byte length limit for CSR string values during certificate creation. (Ref: https://github.com/pyca/cryptography/pull/11201)


## Fix:
Validate the UTF-8 encoded byte length instead of the character length.

[1] - https://github.com/odoo/odoo/blob/a66fedcaf555660e484a2becc49a9b7e602f5924/addons/l10n_sa_edi/models/certificate.py#L92

sentry-7608376856

Forward-Port-Of: odoo/odoo#277822
Forward-Port-Of: odoo/odoo#276861

**Problem:**
For an hour-based time off allocation, changing the employee's working schedule leaves the allocation duration (in days) stale, so the balance shown on the Time Off dashboard becomes wrong.

**Steps to reproduce:**
1. Give an employee a working schedule of 8 hours/day.
2. Create an hour-based allocation (time off type with Request Unit = Hours) granting e.g. 8 hours (1 day).
3. Change the employee's working schedule to one with a different Hours per Day (e.g. 4 hours/day).
4. Check the allocation / the Time Off dashboard balance.

**Current behavior:**
number_of_days stays at its old value (1), so the balance is recomputed as 1 day x 4 hours = 4 hours instead of the 8 hours actually accrued.

**Expected behavior:**
The accrued hours stay constant; the duration in days follows the new schedule (8 hours / 4 hours-per-day = 2 days).

**Cause of the issue:**
`number_of_days` and `number_of_hours_display` compute from each other (`number_of_days = number_of_hours_display / hours_per_day` and `number_of_hours_display = number_of_days * hours_per_day`), forming a dependency cycle, and neither depends on the employee's working schedule. So a schedule change never recomputes either field. Adding the schedule to `_compute_number_of_days`' depends does not help: because of the cycle it recomputes `number_of_hours_display` from the stale `number_of_days` first, which silently destroys the accrued hours.

**Fix:**
When the employee's working schedule changes, the accrued hours are the quantity that must be preserved, so the duration is recomputed explicitly from the still-stored `number_of_hours_display` (setting `number_of_days` first, exactly as a manual `_compute_number_of_days()` does). Driving the order by hand is necessary because the cyclic compute graph cannot guarantee `number_of_days` is computed before `number_of_hours_display`.

opw-6276242

Forward-Port-Of: odoo/odoo#270129

Steps to Reproduce:

- Go to Settings > Translations > Languages and select your active language.
- Change the Time Format to a 13:00:00 (24-hour)
- Click on the Attendance systray icon in the top navbar and Check In.
- Notice that the recorded time still displays in a 12-hour format.

Cause:

- The attendance popup doesn't enforce a strict 12-hour or 24-hour rule. Because of this missing rule, your web browser just uses your computer's default time settings. As a result, Odoo's actual language and time settings are completely ignored.

Fix:

- Replaced the browser-based formatting with the existing formatting utilities.
- Used is24HourFormat() to determine whether the active time format uses a 12-hour or 24-hour clock.

Solution:
- Dynamically selected the display format using:
    - HH:mm for 24-hour format
    - hh:mm a for 12-hour format
- Applied the selected format consistently for both check-in and check-out times so the systray now correctly follows the configured language time format.

task-6120540

When a POS order is invoiced after its session has been closed, `_create_misc_reversal_move` builds a misc entry that reverses the portion of the closing entry corresponding to that order. It does so by negating `balance` and `amount_currency` on every prepared line, but leaves `tax_base_amount` on tax lines untouched.

As a result the reversal move ends up with tax lines whose `balance` sign is flipped relative to the source order while `tax_base_amount` keeps the source sign, breaking the invariant
`sign(balance) == sign(tax_base_amount)` that holds for every other correctly-generated tax line in the system.

Downstream, any report reading `tax_base_amount` directly (Audit view from the Tax Report, Journal Items XLSX export, custom exports) shows a base amount signed for the wrong direction alongside a debit/credit of the opposite sign, which is confusing and, for tax returns computed from `tax_base_amount`, incorrect.

Negate `tax_base_amount` alongside `balance` and `amount_currency` so the reversal move stays internally consistent.

opw-5975658

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

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

Forward-Port-Of: odoo/odoo#277067
Forward-Port-Of: odoo/odoo#269496

You'll need two users :
	- Internal User A that can create projects
	- User B with a granted portal access

Optionnal third user to compare the flows :
	- Internal User B that can create tasks in a porject

- With User A, create a new project with atleast a single stage
- Go to the project settings
- Make sure that Visibility is set to : "All internal users and invited portal users"
- Click on Share Project
- Add User B as a new Collaborator with the Edit acess mode
- Confirm by clicking on Share Project
- Still in the project settings, click on the blue user icon in the top right to edit the Followers :
	- Make sure you are following the project
	- Click on the edit button and make sure Task Created is checked

 Optionnal for easiness of testing :
 - Go to the User A settings and in Preferences > Notifications : In Odoo

- Log in with User B (in a new incognito tab on the side is best)
- Go to Projects > The project that has been shared
- Create a new task

No notification is sent to User A. If the same flow is done using User C, then a notification is correctly sent.

The fields that determine to which users the notifications are sent to is `message_follower_ids`. In our case, the value of that field does not contain User A, so no notifcation is sent to them.

The method responsible for assigning values to that field is `_message_auto_subscribe()` which adds follower using subtypes parent relationship. The parent subtype of tasks are projects. So, essentially, we look for followers of the parent project, and see if we can add them to our task.

Before proceeding with the assignation, we check that the parent subtype's field was actually edited :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L4778-L4781

So we look that `updated_values` contains "project_id". `updated_values` is created by the the `mail_thread` create method by joining the values in `vals_list` and the context default variables. In our case, this should be enough since `default_project_id` is provided when creating a task :
https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mail/models/mail_thread.py#L340-L344

But, a bit before this, the task create method edits the context to replace 'default_project_id' by 'default_create_in_project_id' : https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/project/models/project_task.py#L1102-L1109

So we do not detect that `project_id` has been changed and don't actually add the followers.

We remove the custom 'default_create_in_project_id` context

opw-6026932

Forward-Port-Of: odoo/odoo#278353

When a POS order is invoiced after its session has been closed, `_create_misc_reversal_move` builds a misc entry that reverses the portion of the closing entry corresponding to that order. It does so by negating `balance` and `amount_currency` on every prepared line, but leaves `tax_base_amount` on tax lines untouched.

As a result the reversal move ends up with tax lines whose `balance` sign is flipped relative to the source order while `tax_base_amount` keeps the source sign, breaking the invariant
`sign(balance) == sign(tax_base_amount)` that holds for every other correctly-generated tax line in the system.

Downstream, any report reading `tax_base_amount` directly (Audit view from the Tax Report, Journal Items XLSX export, custom exports) shows a base amount signed for the wrong direction alongside a debit/credit of the opposite sign, which is confusing and, for tax returns computed from `tax_base_amount`, incorrect.

Negate `tax_base_amount` alongside `balance` and `amount_currency` so the reversal move stays internally consistent.

opw-5975658

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

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

Forward-Port-Of: odoo/odoo#277067
Forward-Port-Of: odoo/odoo#269496

Steps to reproduce the bug:
- Install l10n_ke_edi_oscu_stock
- Run Test_sale_mrp_kit_bom_cogs

Problem:
```self.assertAlmostEqual(stock_out_aml.credit, 1.53, msg="Should not include the value of consumable component")
AssertionError: 3.07 != 1.53 within 7 places (1.5399999999999998 difference) : Should not include the value of consumable component
```
The test delivered 1 whole unit of every component of Kit A regardless of the fractional quantity actually needed to produce a single kit (0.34/0.14/0.2 units for Component A/B/BB respectively). This went unnoticed under the default invoice_policy 'order', since qty_delivered never drives the invoiced quantity in that case.

l10n_ke_edi_oscu_stock forces invoice_policy to 'delivery' for storable products that have no explicit company_id, which is the case for the products created in this test. With invoice_policy 'delivery', _compute_kit_quantities() correctly reads the over-delivered components as enough stock to form 2 complete kits (min ratio 2.94, floored to 2) instead of 1, doubling the invoiced quantity and the resulting COGS (3.07 instead of 1.53).

runbot-243633

Forward-Port-Of: odoo/odoo#277519

[FIX] website_hr_recruitment: fix country filter

Bug reproduction:
    1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
    2 - Go to job page in website, activate country filter.
    3 - Select US jobs and search for the remote job.
    4 - All countries filter is readonly and it is not pressable.

Bug cause:
    1 - Check is done with jobs value
        1.1 - If no matching, readonly button is displayed.

Bug solution:
    1 - count_per_filter is used instead of jobs
        1.1 - Even there are matchings for other countries, it shows.
    2 - Also, searched keyword is added to filter url
        2.1 - When there is search in other country and we click to it:
            2.2 - The searched keyword will be still there.

task-6284436

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

### Steps to reproduce:

- Create 2 companies: c1, c2
- Create 2 storable products: P, Comp
- In c1 update the available qty of P to 10 units and its cost to 50
- In c2 create a kit bom for P: 1 x Comp
- With c1 > Accounting > Review > inventory > Inventory Valuation
#### > The total value of Super product is 0 instead of 500

### Cause of the issue:

The total value of the product will be set to 0 since the `qty_available` of the product is incorrectly computed to be 0:
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_account/models/product.py#L240-L243
This happens because the `_find_bom` used in the override of the `_compute_quantities_dict` in mrp does not consider take the contextual company into account:
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/mrp/models/product.py#L271-L289 and hence considers incorrectly that the product is a kit.

### Note:

We make the same company dependency as in the `is_kits` computation: https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/mrp/models/product.py#L41-L47

opw-6361690

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

Forward-Port-Of: odoo/odoo#276306

Steps to reproduce the issue easily:
- Remove the section in the footer.
- Drop enough snippets to have a scroll bar and to not see the footer when the scroll is at the top.
- Drop the "Pricelist" snippet at the bottom of the page and click on a column.
- Scroll up so the footer and the bottom of the snippet are not visible, and add a pricelist item with the "Add Product" option.
- => The page scrolls to the new item, but a big white space appears at the bottom of the screen, as if we scrolled too far.

The same issue happens with similar steps in the following cases:
- When using any option using the `addItem` action.
- When undoing/redoing a step that was done in an element not in the viewport (the screen will scroll to it and we will have the issue).
- When showing an invisible element (the screen will scroll to it if not in the viewport)
- Adding a grid item with the "Add Elements" option.
- Adding a new card in the "Floating Cards" snippet.

The common point to all these cases is that they all scroll to the added or shown element with the `scrollIntoView` built-in function, which scrolls everything, including the viewport. It also doesn't take into account the header that changes during the scroll, often ending with the element hidden by the header.

This commit fixes these issues by using the builder `scrollTo` util, which takes the header into account and only scrolls what needs to be. This function should always be preferred when scrolling in the builder.

task-6314322

Forward-Port-Of: odoo/odoo#275686

On a production-sized database the `hr.leave.attendance.report` SQL
view took over three hours to run. This caused a significant load on the
upgrade platform when processing databases that have a large number of
`hr.employee` records. Specifically, when running `test_mock_crawl` and
mocking the `Attendances > Reporting > Time Off Ledger` menu.

PostgreSQL mis-estimated the row counts produced by the view:

- The public-holiday check combined an `OR` with a function-wrapped
  `BETWEEN` (`... AT TIME ZONE ... ::date`), which the planner cannot
  estimate; it predicted ~1 surviving row (actual: 29.4M) and chose
  nested loops that re-aggregated whole tables once per output row.
- The attendance sub-query aggregated the entire `hr_attendance`
  table with no date bound, and was re-executed per output row.
- The working schedule was resolved with a per-(employee, day)
  `LIMIT 1` lookup into `hr_version` (29.4M index probes).

Rewrite the view as a set of CTEs: every heavy table is scanned once,
joins use plain equality keys (hash-joinable), public holidays are
pre-expanded so their exclusion stays an anti-join, the attendance
aggregate is bounded to the report window, and hr_version is resolved
by expanding each version over the days it covers. None of the CTEs
are explicitly materialized: left to its own heuristic, PostgreSQL
inlines a CTE referenced only once as a plain subquery and materializes
the ones referenced more than once, which benchmarked faster than
forcing materialization everywhere.

This rewrites the body of the SQL view only: no schema change, no new
field, no index, no migration. The report output is unchanged.

Measured with EXPLAIN (ANALYZE, BUFFERS) on the same database:

  | metric         | before        | after    | factor |
  |----------------|---------------|----------|--------|
  | execution time | 11 852 235 ms | 1 834 ms | ~6500x |
  | buffer hits    | 115 311 556   | 71 890   | ~1600x |

upg-4288902

Forward-Port-Of: odoo/odoo#266108

Steps to reproduce:
------------------------------------
1. Install Time off module
2. Create New Fully Flexible Employee
3. Click on the Time off smart button
4. Create time off for multiple days (eg. Mon - Friday)

Observation:
------------------------------------
Number of days still shows 1 Days.

Issue:
------------------------------------
Issue occurs because `work_time_per_day_mapped` returns one interval per day for
standard and flexible schedules in multi-day time off requests, so the interval
count correctly matches the number of leave days.
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/hr_holidays/models/hr_leave.py#L460-L461

However, for fully flexible schedules, it returns a single interval
containing the total hours across all days, causing the leave duration to
always be computed as 1 day regardless of the actual number of days requested.

Solution:
------------------------------------
For fully flexible employees, count the actual calendar days and subtract public
holidays when applicable.

opw-6060552

Forward-Port-Of: odoo/odoo#255826

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

Forward-Port-Of: odoo/odoo#270008

[FIX] website_hr_recruitment: fix country filter

Bug reproduction:
    1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
    2 - Go to job page in website, activate country filter.
    3 - Select US jobs and search for the remote job.
    4 - All countries filter is readonly and it is not pressable.

Bug cause:
    1 - Check is done with jobs value
        1.1 - If no matching, readonly button is displayed.

Bug solution:
    1 - count_per_filter is used instead of jobs
        1.1 - Even there are matchings for other countries, it shows.
    2 - Also, searched keyword is added to filter url
        2.1 - When there is search in other country and we click to it:
            2.2 - The searched keyword will be still there.

task-6284436

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

### [FIX] website: fix GMaps deprecation console warning for s_google_map

Google deprecated the synchronous script loader for initializing the
Maps JS API. This caused browser console warnings.

The fix adopts Google's official `importLibrary()` bootstrap pattern,
which loads map libraries (places, maps, marker) lazily on demand rather
than all at once.The version is updated to `v=weekly`, which Google
recommends as it receives updates weekly versus quarterly for version
numbers(`v=number`).

Steps to reproduce:
1. Add the `s_google_map` snippet(not the`s_map`, enable debug mode)
2. Open the browser console and observe the deprecation warning


### [IMP] website: warn user to reload after GMaps config changes

Switching from the legacy Google Maps APIs to the new APIs requires
enabling additional services in Google Cloud. Existing maps using the
legacy API continue to work, but when an admin edits a map without a
proper configuration, the `GoogleMapAPIKeyDialog` dialog opens.

Google Maps configuration changes (API key update or enabling services)
do not take effect during the current editor session because the Maps
JavaScript API is loaded at page initialization.

Before this commit, such misconfigurations (disabled services or invalid
API keys) only triggered a dialog showing a generic Google Maps error.

After this commit, a notification informs the user that the page must be
reloaded for configuration changes to take effect.

The setup instructions are also updated to reference the
"Places API (NEW)" service.


### [IMP] website: replace deprecated Places API calls in GPS picker

The GPS picker relied on `PlacesService.nearbySearch` and `getDetails`,
which are part of the deprecated Places API. The new places API replaces
these with `Place.searchNearby` and `fetchFields`.

Error handling is consolidated into a single try/catch since the new
Places API throws on failure rather than returning a status code,
removing the need for `PlacesServiceStatus` checks.


### [IMP] website, *: replace deprecated Google Autocomplete
*: website_form_project

google.maps.places.Autocomplete is deprecated in the new Places API.
The replacement (`AutocompleteSuggestion.fetchAutocompleteSuggestions`)
does not fire DOM events, making it incompatible with the old
event-listener pattern used in GPSPicker.

A new Owl component (`PlacesAutoComplete`) is introduced to wrap the new
API, built on top of the existing `AutoCompleteWithPages`.


References:
https://developers.google.com/maps/documentation/javascript/load-maps-js-api
https://developers.google.com/maps/documentation/javascript/advanced-markers/migration
https://developers.google.com/maps/documentation/javascript/legacy/places-migration-overview

task-[4441041](https://www.odoo.com/odoo/project/974/tasks/4441041)

Forward-Port-Of: odoo/odoo#242765

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278378

## Issue
The test `test_anglo_saxon_cogs_partial_down_payment_credit_note` from the `sale_stock` module is failing when the Kenyan localization is installed.

This issue is similar to the one fixed by https://github.com/odoo/odoo/commit/b9e5807cd70d.

## Steps to reproduce
1. Install `sale_stock` and `l10n_ke_edi_oscu_stock`
2. Run the test `test_anglo_saxon_cogs_partial_down_payment_credit_note`
3. **The test fails with the following error:**

```
AssertionError: Lists differ: [{'debit': 0, 'credit': 40, 'account_id': 268}] != []

First list contains 2 additional elements.
First extra element 0:
{'debit': 0, 'credit': 40, 'account_id': 288}

+ []
- [{'account_id': 288, 'credit': 40, 'debit': 0},
-  {'account_id': 268, 'credit': 0, 'debit': 40}]
```

## Cause
When `l10n_ke_edi_oscu_stock` is installed, the `invoice_policy` of Kenyan products (or products without a company set) is set to `"delivery"` by the `_compute_invoice_policy` method from that module:

https://github.com/odoo/enterprise/blob/f4cd9a38c699e8d8f17990a283793985bfc89948/l10n_ke_edi_oscu_stock/models/product.py#L16-L21

This impacts the `SaleOrder.qty_to_invoice` field, as we now use the `qty_delivered` (which is 0 here) instead of the `product_uom_qty`:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale/models/sale_order_line.py#L1001-L1006

With a `qty_to_invoice` set to 0, the `SaleOrder._get_invoiceable_lines` doesn't add the product as an invoiceable line:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale/models/sale_order.py#L1492-L1498

And finally, with the `'cogs'` invoice lines missing, the comparison with the expected values fail:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale_stock/tests/test_anglo_saxon_valuation.py#L1879-L1887

## Fix
We manually set the `invoice_policy` of the test product to 'order' to keep the test configuration consistent regardless of the other modules installed.

runbot-242508

Steps to reproduce the bug:
- Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery' in that case)
- Run TestSaleMRPAngloSaxonValuation.test_sale_mrp_kit_bom_cogs (sale_mrp) or TestAngloSaxonValuation.test_anglo_saxon_cogs_partial_down_payment_credit_note (sale_stock)

Problem:
These tests create their products without setting invoice_policy explicitly, relying on the field's implicit default. l10n_ke_edi_oscu_stock's _compute_invoice_policy (https://github.com/odoo/enterprise/blob/4e459417dac809caafea34aa2e487fc3c1f0ce1a/l10n_ke_edi_oscu_stock/models/product.py#L16-L21) forces invoice_policy to 'delivery' for any storable product whose company_id is not set, which is the case for products created in these test fixtures.

Once invoice_policy becomes 'delivery', invoiced quantities are driven by qty_delivered instead of the ordered quantity, which the affected tests never account for (some deliver an arbitrary quantity instead of the exact BoM demand, others never validate a delivery at all), causing wrong COGS amounts or wrongly invoiced quantities as soon as such a localization is installed alongside these modules.

Solution:
Pin invoice_policy to 'order' explicitly wherever these test fixtures create their products, so the test outcome no longer depends on which other modules happen to be installed.

runbot-243633

## Problem

When rendering PDF invoices that contain **section** or **note** lines, the `l10n_gcc_invoice.arabic_english_invoice` QWeb template raises:

```
TypeError: argument of type 'bool' is not iterable
```

This happens because `account.move.line` records of type `line_section` or `line_note` have `name = False`. The template evaluates `arabic_name not in line.name` (and the same for `english_name`), which fails because Python cannot apply the `in` operator on a boolean value.

## Fix

Add a `line.name and` guard before each `not in` check:

```xml
<!-- Before -->
<span t-if="arabic_name not in line.name" .../>
<span t-if="(english_name != arabic_name) and (english_name not in line.name)" .../>

<!-- After -->
<span t-if="line.name and arabic_name not in line.name" .../>
<span t-if="line.name and (english_name != arabic_name) and (english_name not in line.name)" .../>
```

## Steps to reproduce

1. Install `l10n_gcc_invoice` on an Odoo 16.0 instance.
2. Create a customer invoice and add a **Section** line.
3. Print/preview the invoice PDF.
4. Observe `Internal Server Error` / `TypeError: argument of type 'bool' is not iterable`.

Forward-Port-Of: odoo/odoo#267147