Currently, an error occurs when the "Payroll: Update Data" scheduled action is run.

**Steps to Reproduce:**

 - Install `l10n_au_hr_payroll` with demo data.
 - Switch to `Australian Company`.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. 
 - Delete all records related to the `Australian Company`. 
 - Go to `Scheduled Actions` and run `Payroll: Update Data`.

`ValueError: External ID not found in the system: l10n_au_hr_payroll.rule_category_ote`

After [this commit], the category_id field becomes non-required, allowing users to delete a rule 
category record even if it is linked to a salary rule. When updating the data file [1], an error is 
raised due to the missing rule category.

This commit ensures that when updating the salary rule data, it updates the category data 
beforehand as like [here]

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1] https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_au_hr_payroll/models/hr_payslip.py#L76-L83

[here]: https://github.com/odoo/enterprise/blob/b6612dd58276646b81a3a12cd48e8427ea5359c2/l10n_ch_hr_payroll/models/hr_payslip.py#L1074-L1087

sentry-7349905716

Forward-Port-Of: odoo/enterprise#121167

Currently, an error occurs when a user removes the payslip dates.

**Steps to reproduce:**

 - Install the `l10n_mx_hr_payroll_account_edi` module with demo data.
 - Switch to `ZAPATERIA URTADO ÑERI` company
 - Go to `Payslips`, create a payslip.
 - Set an `employee`, and remove either the `start date` or the `end date` from Period..

`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

After the [recent commit] adding a warning about the employee exceeding the salary limit, when the 
user removes the dates from the payslip, the compute method attempts to compute the warning 
from [1], and when it adds relativedelta to date_from, which is False, it raises the error [2].

This commit ensures that the payslip dates are checked first before adding relativedelta to the date 
and performing the comparison.

[recent commit]: https://github.com/odoo/enterprise/commit/6abfa47dafe439f9328d606ef6ac5126ec6eb1f6

[1]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/hr_payroll/models/hr_payslip.py#L1446

[2]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L272-L276

Forward-Port-Of: odoo/enterprise#125479
Forward-Port-Of: odoo/enterprise#122643

Steps to reproduce:
- Set the database language to Spanish (Latin America).
- Create a customer invoice, confirm it and send it to the SII.
- Print it using Print > Invoice PDF copy (Chile).
- Scroll to the CEDIBLE section at the bottom of the PDF.

Cause of the issue:
The CEDIBLE footer is merged into l10n_cl.report_invoice_document, which account.report_invoice (odoo/addons/l10n_cl/views/report_invoice.xml) renders with t-lang set to the invoice partner's lang, not the database/user language. The disclaimer text was hardcoded in English and relied on the regular translation to be shown in Spanish, so as
soon as the partner's lang field isn't Spanish, the translation lookup falls back to the untranslated English source, regardless of the database language.

Solution:
This disclaimer is boilerplate mandated by Chilean law: it must always be printed in Spanish, independently of the invoice partner's or current user's language. The same template already follows that rule a few lines above for the SII stamp block ("Timbre Electrónico SII..."), which is hardcoded in Spanish instead of relying on translation.

opw-6390207

Forward-Port-Of: odoo/enterprise#124916

If one of the Payroll Structure Types has the Scheduled Pay field unset,
opening the Payroll dashboard raises a traceback.

Steps to reproduce the error:
- Install ``hr_payroll`` module
- Go to Payroll > Configuration > Settings > Set Payroll Closing Date > Save
- Go to Payroll > Configuration > Structure Types > Create a new Structure Type > Unset Scheduled Pay
- Open Dashboard

Traceback:
```py
AttributeError: 'bool' object has no attribute 'title'
```

https://github.com/odoo/enterprise/blob/9a3ea83a432f42f62076a50fca6bc771a2de96bf/hr_payroll/models/hr_payroll_warning.py#L413-L419
The dashboard collects the scheduled pay values from all structure types and
later calls ``schedule.title()`` to build the labels. When a Structure Type has
no Scheduled Pay configured, so ``schedule`` becomes ``False``, leading to the traceback.

``_get_schedule_pay`` method can return False at [1],
So, It will generate the traceback from below line also. https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L401

Solution:
Added a fallback value when default scheduled pay is False.

[1]: https://github.com/odoo/enterprise/blob/8a3d87d51a9a3c4df656a328a9179ee43541022d/hr_payroll/models/hr_payroll_warning.py#L149-L154

sentry-7583037488

Forward-Port-Of: odoo/enterprise#122492

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

Forward-Port-Of: odoo/odoo#259918

## Issue
In Attendances > Management, negative overtimes do not appear in the list, even if they need approval from a manager.

## Steps to reproduce
1. Install *Attendances* (`hr_attendance`)
2. In Settings:
    - Toggle *Attendances from Backend*
    - Toggle *Absence Management*
    - Toggle *Display Extra Hours*
    - Set *Extra Hours Validation* to *Approved by Manager*
3. On an Employee E:
    - Overtime Ruleset: Default Ruleset
4. In Attendances, create an attendance for employee E on a day where they are expected to work. The attendance should be shorter than a full day of work (e.g., from 9:00am to 11:00am, which would be -6 hours of overtime if 8 hors are expected).
5. Navigate to Attendances > Management
6. **The attendance created in Step 4 does not appear, even though it should be approved by a manager.**

## Cause
The domain for the `hr_attendance_management_action` is the following:

https://github.com/odoo/odoo/blob/22a94663e4c1672366b7a614943cef843ced3503/addons/hr_attendance/views/hr_attendance_view.xml#L439

The `overtime_hours > 0` condition was added by https://github.com/odoo/odoo/commit/e5067262174725466056e9a6c530439b4845c19b with the intent to remove attendance records with zero extra hours. Instead, it removes all records with less than zero extra hours.

opw-6372360

## Current behavior:
Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter.

## Expected behavior:
Clicking on the Late activity for Lot/Serial in the notification systray should apply the Late activities filter.

## Steps to reproduce:
1. Install Inventory (stock) module, make sure to enable Lots & Serial Numbers in Inventory > Traceability
2. Create some new Lots / Serial numbers
3. Add some Activities with Due Date before today
4. Observe that the Clock icon on systray will count up, showing the number of activities that are late, for today and for future
5. Click on the Late activities (e.g. 2 Late) should only show the 2 late activities. Instead, no filter is applied, thus showing all the Lots / Serial numbers in the inventory

## Cause of the issue:
Missing filters for Late, Today and Future activities in the stock_lot_views.xml

## Fix:
Added 3 filters for Late, Today and Future activities

opw-6332560

Forward-Port-Of: odoo/odoo#278165
Forward-Port-Of: odoo/odoo#272735

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

Steps to reproduce the bug:
- Run the product module test suite on a loaded/slow CI runner
- Observe test_get_first_possible_combination occasionally failing

Problem:
test_get_first_possible_combination asserts that
_get_first_possible_combination() completes in under 0.5 seconds on a template with 10 attributes x 50 values and exclusion rules. On a busy runner (Testing country uk build) it took 0.587s and the test failed with `0.5868358612060547 not less than 0.5`, even though the returned combination was correct. The 0.5s threshold is an arbitrary sanity check meant to catch a gross algorithmic regression (e.g. loss of early pruning of invalid combinations), not a strict performance SLA, so it is too tight to survive normal CI load variance.

Solution:
Raise the threshold to 2 seconds, keeping enough margin to absorb CI load variance while still catching a real performance regression, which would take far longer than the current computation.

runbot-243606

Forward-Port-Of: odoo/odoo#277986

Currently, an error occurs when grouping invoice lines by tax.

**Steps to Reproduce:**
 - Install the `Accounting` module.
 - Go to `Accounting` > `Customers` > `Invoices` and `create an invoice`.
 - Add an `invoice line`, set a `price`, and select an `account`.
 - Go to `Accounting` > `Configuration` > `Chart of Accounts`, open the account used on 
   the invoice line, and clear its `Code` field.
 - Return to the `invoice`, click `Action` > `(Un)Group lines by tax`.

`ValueError: TypeError('sequence item 1: expected str instance, bool found') while evaluating`
`'if records:\n records.action_group_ungroup_lines_by_tax()'`


After this [recent commit], account codes became optional and can be removed. As a result, 
when a user adds an account with no code to an invoice line and groups the lines by the same 
tax, it creates the grouped line from here [1]. Then, when it gets the account code from the 
grouped line to prepare the name, the code is False, which raises the error [2].

This commit ensures that the grouped line name is built using filter(None, ...), which removes 
None and other falsy values, so that the account code is included if it exists; otherwise, 
it is not included.

[recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277

[1]- https://github.com/odoo/odoo/blob/92ced215895d027a2b5606dbecbf3eb96b9dcd10/addons/account_edi_ubl_cii/models/account_move.py#L156-L158

[2]- https://github.com/odoo/odoo/blob/92ced215895d027a2b5606dbecbf3eb96b9dcd10/addons/account_edi_ubl_cii/models/account_move.py#L189-L193

sentry-7598941609

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

**Issue**
Printing an invoice for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print on the invoice 
-> The generated PDF displays "lot1 & lot2" instead of "lot1"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 2` since the invoice is on a quantity of 2 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic (as they should be): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80
- for the last one, `is_stock_return = False` while it should not, thus the quantity is 1 instead of 0. Furthermore, it does not pass by this code:
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/sale_stock/models/account_move.py#L79 which would make the quantity for lot2 equalled to 0 (1-1) The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 1, lot2: 0}`

The report selects both lots since it starts with lot1 (qty of 1): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6236855

Forward-Port-Of: odoo/odoo#270599

# How to reproduce
- Have two language in the db
- Create an e-Commerce category
- Have a different translation for each language for that category's name
- Copy the link to that category's name in one language (Should be something like /shop/category/name-x)
- Have two websites, each with a different default language
- Create a link to the shop category in each website.
> ! The link must be the exact same
> You can put it in the header menu for simplicity
- Open the website editor
- Do 2 or 3 times :
    - click on the category link and switch website

# The issue
A traceback is displayed

# Cause
This manipulation will make us enter an infinite redirect scenario described here :
https://github.com/odoo/odoo/blob/f8741728294a5147c7d2427d9997738096386262/addons/website/static/src/client_actions/website_preview/website_builder_action.js#L371-L384

The problem is that this commit introduced an assignation to `iframe.contentDocument.body` before the patch :
https://github.com/odoo/odoo/commit/89994eb7a54ca606bab26b6d579d03e86c11ba60

But in our case, iframe.contentDocument is null, so it throws an error before the patch can be applied

opw-6322115

Forward-Port-Of: odoo/odoo#276634

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#278690
Forward-Port-Of: odoo/odoo#266108