**Steps to reproduce:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Forward-Port-Of: odoo/odoo#264434
Forward-Port-Of: odoo/odoo#259566

Currently an error occurs when the user unlinks all websites and tries
to access the frontend ( website).

Steps to produce an error:
- Install the website module
- Delete external identifier default_website
- Delete the My Website from Website > Configuration > Websites
- An error will occur when we try to access the website.

Error: `TypeError: expected string or bytes-like object, got 'bool'`

This issue was generated because while setting cookies to the Werkzeug
response, we got 'value' as a `False` at line [1], and the `value` is the
language code from the request (see line [2]) .

The language is determined by the `IrHttp` class through the `_get_default_lang`
method (see code line [3]). In the website module, this method is overridden
to return the language configured on the current website.

However, when all websites are deleted, no valid website record remains.
As a result, the method attempts to retrieve the language from an empty website,
which returns `False` (see code line [4]), leading to the issue.

This commit fixes the issue by preventing the deletion of all website records.

The method `_unlink_except_default_website` already ensures that the
default website (identified by the external ID `website.default_website`)
cannot be deleted. However, if this external identifier has been removed,
the safeguard no longer applies, allowing the default website to be deleted
without raising any error.

To address this, an additional check has been introduced: when the
`default_website` is not found, the system verifies whether any website records
remain using search_count. If no records are found, a `UserError` is raised to
prevent the deletion and ensure that at least one website always exists.

[1]: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/odoo/http.py#L1825
[2]: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/http_routing/models/ir_http.py#L518
[3]: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/http_routing/models/ir_http.py#L407-L411
[4]: https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/website/models/ir_http.py#L288

sentry-7413005338

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#264518
Forward-Port-Of: odoo/odoo#260566

## **Issue**

When a cash basis tax is configured with a payable/receivable
transition account, tax journal items are generated on that account
without a due date.

Since payable/receivable accounts require a due date on journal
items, this leads to a validation error during move creation:

"Any journal item on a payable account must have a due date and vice versa."

## **Steps to reproduce:**

1. Install the Accounting and Inter-Company modules.
2. Create an additional company so that there are a total of two companies, then switch to Company 1.
3. Create a product with a price and assign a tax to it.
4. Navigate to Accounting → Configuration → Settings and enable Cash Basis accounting.
5. Go to Accounting → Configuration → Taxes and open the purchase tax (or the tax assigned to the product).
6. In the Tax Computation section, ensure that Group of Taxes is not selected.
7. Under the Advanced Options tab, set Tax Exigibility to Based on Payment.
8. Set the Cash Basis Transition Account to a payable account.
9. Open Company Settings, select Company 1, go to the Inter-Company Transactions section, and enable Synchronize invoices/bills.
10. Switch to Company 2 and create an invoice using the same product. Select the contact that is the partner of Company 1.
11. Confirm the invoice.

The following error is raised:

"Any journal item on a payable account must have a due date and vice versa."

## **With This Commit:**
Added a domain on the Cash Basis Transition Account field to prevent
users from selecting payable or receivable accounts, avoiding invalid
configurations and runtime validation errors.

opw-6189615

Forward-Port-Of: odoo/odoo#264777
Forward-Port-Of: odoo/odoo#263792

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

**Problem:**
When opening a PDF attachment preview in v19+, the print button disappeared. As a result, the Print button is not accessible from the main toolbar.

In v18 the buttons remained permanently visible.

**Steps to reproduce:**
- Open any record that has a PDF attachment in the chatter.
- Click the PDF attachment to open the preview popup.
- Observe toolbar buttons disappeared.

**Cause:**
commit responsible for this: https://github.com/odoo/odoo/commit/b7889d007f72c7e7f9f22318a9968338cde0ddb3 It was removed to prevent some bugs with some android/smartdevice and some old browsers

`file_viewer.js` passes `hidePrint: true` to `hidePDFJSButtons()`. This was originally added alongside the mobile guard (`isMobileOS()`), but the `isMobileOS()` guard in `hidePDFJSButtons` already handles mobile, so the explicit `hidePrint: true` in `file_viewer.js` was redundantly hiding Print on desktop too. https://github.com/odoo/odoo/blob/654a1caafc2ab7b2841c372910b2e81dc6e9c035/addons/web/static/src/core/file_viewer/file_viewer.js#L60-L71 https://github.com/odoo/odoo/blob/654a1caafc2ab7b2841c372910b2e81dc6e9c035/addons/web/static/src/core/utils/pdfjs.js#L35-L37

**Fix:**
- Remove `hidePrint: true` from `file_viewer.js` since mobile is already covered by the `isMobileOS()` check inside `hidePDFJSButtons()`.

opw-6216534

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

Forward-Port-Of: odoo/odoo#264739

**Steps to reproduce in runbot:**
1. Install hr_holidays_attendance.
2. Create an employee with a contract start date (e.g., April 1st).
3. Set the timezone(for both user and emp working schedule) to Europe/Brussels.
4. Create an attendance record (e.g., April 15th).
5. Go to Reporting > Time Off Ledger and remove all filters.
 -> Attendance is correctly shown for all dates from April 1st
6. Create a public holiday on April 16th starting at 00:00.
7. Check the Time Off Ledger again.

**Issue:**
The attendance entry for April 15th disappears after adding the public holiday.

**Cause:**
Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144

**Solution:**
Convert calendar leave datetimes to the resource calendar timezone before casting to date, ensuring comparisons reflect the correct local boundaries.

**NOTE:**
This issue is mainly reproducible on runbot since its server timezone is
GMT. On local machines configured with UTC, the stored datetime values
already align with the expected conversions, so the date shift does not occur.


opw-6118043




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

Forward-Port-Of: odoo/odoo#262179

Steps to reproduce:-
- Navigate to Time off Dashboard calendar view.
- Create a leave. First approve it then refuse it.
- Now on the same day create a leave and approve it.
- Now re-approve the previously refused leave from step 2.
- System will let user to create 2 leave of same types on same day!

Cause:-
In `_compute_dashboard_warning_message`, refused/cancelled leaves were
excluded from warning computation. When approving a refused request,
the warning message was not set, allowing the constraint check to pass
even when conflicting approved requests existed for the same period.

Fix:-
1. Refactored `_compute_dashboard_warning_message` to only compute
   warnings for active leaves (non-refused/cancelled) while still
   detecting conflicts with already approved requests
2. Updated `_check_date` constraint to skip validation for refused/
   cancelled leaves, but enforce it when state changes to validate
3. Added 'state' to constraint triggers to ensure validation runs
   when approving previously refused requests

task-[6181717](https://www.odoo.com/odoo/project/1251/tasks/6181717)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#262703

__
## Short functional explanation of the error
When setting attendances on several consecutive days for a flexible employee, with an overtime ruleset containing a single rule. This rule being based on week and quantity.
When regenerating overtimes for this ruleset, the overtime hours generated isn't correct.

## Reproduction Steps
1. Create an employee. In the Payroll tab, set a start date for their contract. Set Work Entry Source as Attendances. Set their Working Hours as a flexible schedule. Set their weekly hours at 40.
2. Create an Overtime Ruleset. Add a single rule, based on Quantity, if the worked hours on a `Week` differs `from the amount defined on the contract`. Check Pay Extra Hours and leave the Work Entry Type to use as Overtime Hours.
3. Go back to the employee. In Settings, set the Overtime Ruleset field as the new Overtime Ruleset you just created.
4. Create 5 attendances, each from 8 am to 6 pm, from Monday to Friday.
5. Go to the Overtime Ruleset you just created and click on Regenerate Overtimes.
6. Go back to Attendances. Search for your employee, and click on the list view.

### Expected behavior
The employee's schedule is 40 hours per week. They worked 50 hours. 10 hours should be considered as Worked Extra Hours.

### Unexpected behavior
18 hours are considered as extra hours.

## Origin of the issue
To compute the expected duration of the day, we run: https://github.com/odoo/odoo/blob/7fc5edc29f854d619dbcb5fcc3503fb18ca05335/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L303-L304 where `schedule['work']` will contain intervals on 5 consecutive days, from 8 am to 4 pm.
However, the last day of the employee's attendances isn't contained in these intervals. As a result, `period_schedule` will contain 4 days (the common days between the employee's Attendance days and `schedule['work']` ) and thus, `expected_duration` will be set at 36 hours instead of 40.
In the case where overtimes are computed based on hours from the 
contract, for flexible employees, the expected hours are the ones
indicated on their schedule.

__
opw-6131543

Forward-Port-Of: odoo/odoo#263335

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

Forward-Port-Of: odoo/odoo#264798
Forward-Port-Of: odoo/odoo#245905

There is no need to do a query to get a random foreign state. This search can be performed many times during imports.

While the query is generally not reading a lot of data, it is still doing a seq scan because of the ORDER BY, while the query can be avoided completely.

```sql
EXPLAIN ANALYZE
  SELECT "res_country_state"."id"
    FROM "res_country_state"
   WHERE "res_country_state"."code" NOT IN ('IN')
ORDER BY "res_country_state"."code", "res_country_state"."id"
   LIMIT 1;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=84.93..84.94 rows=1 width=8) (actual time=0.450..0.450 rows=1 loops=1)
   ->  Sort  (cost=84.93..90.49 rows=2224 width=8) (actual time=0.449..0.449 rows=1 loops=1)
         Sort Key: code, id
         Sort Method: top-N heapsort  Memory: 25kB
         ->  Seq Scan on res_country_state  (cost=0.00..73.81 rows=2224 width=8) (actual time=0.012..0.281 rows=2223 loops=1)
               Filter: ((code)::text <> 'IN'::text)
               Rows Removed by Filter: 2
 Planning Time: 0.075 ms
 Execution Time: 0.462 ms
```

This can be worse if when the table is not in the buffer.

Forward-Port-Of: odoo/odoo#265007