Currently, an error occurs when a user sets an employee on a payslip.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Create an `employee` and make sure that the employee's version has no `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and set that employee.

`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

When a user sets an employee on a payslip, the system computes the worked day lines [1]. 
If the salary structure uses worked day lines, it creates the corresponding records [2] and 
calculates out days and out hours based on the contract dates.
During this process, the payslip dates are compared with the version's contract start date. 
If the version does not have a contract start date, it raises an error [3].

This commit ensures that the payslip dates are compared with the version's contract start date, 
and that out days and out hours are calculated only when the contract start date exists. Cases 
where no contract start date is defined are already handled in payslip [4].

[1]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1964

[2]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1985-L1988

[3]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/l10n_hk_hr_payroll/models/hr_payslip.py#L309

[4]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1092-L1096

sentry-7632216317

Forward-Port-Of: odoo/enterprise#120234

Problem:
When testing the import of contacts with a user without accounting access rights, the test fails and leads to an error.

Steps to reproduce:
1- Remove accounting access rights from your user (Set Accounting to No) 2- Open Contacts app
3- Try importing contacts (you can download the available template and use it as the file you are asked to upload)
4- Test the import
5- Notice the error you receive

Cause:
When importing contacts, the commercial fields (fields related to the contact's parent) are loaded and then written. Some of these fields may have access rights that the user trying to import doesn't have. As a result, when trying to load/write them, the user may get an error.

Solution:
Use sudo() when loading them. This shouldn't be an issue since they are only copied from the parent. Also, sudo() is already being used when writing the values,
https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/odoo/addons/base/models/res_partner.py#L996 so sudo() should also be used when loading them.

opw-6396086

Forward-Port-Of: odoo/odoo#278638

When an internal recipient receives an Out of Office (OOO) notification, the resulting `mail.message` record has `partner_ids` populated with the recipient partner ID, while `outgoing_email_to` is set to `False`.

When a second internal user emails the OOO user within the 4-day window, `_notify_thread_with_out_of_office` excutes a search domain with an OR condition: `'|', ('partner_ids', 'in', recipient.ids), ('outgoing_email_to', '=', email_to)`

Because `email_to` is `False` for internal partners, `('outgoing_email_to', '=', False)` evaluated to `True` against the first recipient's message record. Consequently, the search falsely determined that the second recipient was already notified, suppressing OOO replies for all subsequent contacts across the 4-day window.

## Proposed solution:
We resolve this by dynamically constructing recipient sub-domains conditionally depending if `recipient` or `email_to` are set.
We also extend `test_routing_with_out_of_office` with a corresponding test case.

## How to reproduce:
1. Set up a DB with at least 3 users (User A, User B, User C).
2. Configure User A to be out of office (in user preferences)
3. Go to any chatter/mail.thread while logged as User B and tag User A in a log note. -> triggers OOO message
4. Log as User C, tag User A in a log note. -> BUG: no OOO message because the "4 day" check falsely believes that User C already received a OOO from User A

OPW-6110300

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

Forward-Port-Of: odoo/odoo#279881
Forward-Port-Of: odoo/odoo#277880

Steps to reproduce:
-------------------
1. Install hr_holidays.
2. Create a new Time Off Type with "Duration type" set to Hours.
3. Create a time off request.
4. Change the default hour value (e.g., from 12 AM to 10 AM) and observe the formatted value.
5. Switch the user language to Dutch.
6. Create another time off request and change the hour value to 10 AM.

Issue:
------
After changing the value to 10 AM, the displayed formatted value remains 12 a.m.

Cause:
------
https://github.com/odoo/odoo/blob/c1acf61ab23f231e416354a3504cc3c18170af2c/addons/hr_holidays/static/src/components/float_time_selection/float_time_selection.js#L45-L56 Here, the code attempts to parse the hours and minutes by splitting the already localized formatted string (super.formattedValue) and checking if the formatted value ended with "h" or "m".

In Dutch, the localized string ends with "u" instead of "h", causing the string-matching logic to fail silently and default back to 0 (12 a.m.).

Example: If we change the value to 10:30 AM, in Dutch the formatted value becomes "10u 30m".

Reference: e80750d

Solution:
---------
Stop parsing the localized formatted string and instead compute hours and minutes directly from the float value stored in the record using `floatToHoursMinutes`, making the formatting independent of translations.

opw-6303884


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

Forward-Port-Of: odoo/odoo#271085

Currently, an error occurs when a user sets an employee on a payslip.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Create an `employee` and make sure that the employee's version has no `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and set that employee.

`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

When a user sets an employee on a payslip, the system computes the worked day lines [1]. 
If the salary structure uses worked day lines, it creates the corresponding records [2] and 
calculates out days and out hours based on the contract dates.
During this process, the payslip dates are compared with the version's contract start date. 
If the version does not have a contract start date, it raises an error [3].

This commit ensures that the payslip dates are compared with the version's contract start date, 
and that out days and out hours are calculated only when the contract start date exists. Cases 
where no contract start date is defined are already handled in payslip [4].

[1]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1964

[2]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1985-L1988

[3]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/l10n_hk_hr_payroll/models/hr_payslip.py#L309

[4]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1092-L1096

sentry-7632216317

Forward-Port-Of: odoo/enterprise#120234

Issue:
In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date)

Steps to reproduce:
1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered)
2) Pick any "As of" date
3) Open any row
4) Click breadcrumb to return to the accrual list
5) Observe the "As of" date has been reset to today's date
To generate some data you could:
create a PO, then upload the bill, validate the receipt, then you'll find it in bills received

Cause:
`AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16

Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65

Solution:
- Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation.
- Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path.
- In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore.

opw-6232263


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

Forward-Port-Of: odoo/enterprise#126087
Forward-Port-Of: odoo/enterprise#118669

### Issue:
During RunBot single module tests, some tests caused an error: `Maximum call stack size exceeded` after repeated: `[Owl] Unhandled error. Destroying the root component`

### Affected tests:
- `sign_money_in_out.called at right time`
- `sign_drawer_open.called at right time`
- `sign_work_in.called when opening register, setting & resetting cashier`
- `sign_work_in_employee.called from login screen (closed session)`

### Cause:
The tests passed `dialogData: {}` to the component env But `dialogData` must at least define `scrollToOrigin`, which is called automatically in `onWillDestroy`:
https://github.com/odoo/odoo/blob/0042e83fb60353a49d4759a79a3ceb0eee6f74b6/addons/web/static/src/core/dialog/dialog.js#L122-L126

Calling `scrollToOrigin()` on an empty object raises a `TypeError`, which Owl catches and re-throws repeatedly until the call stack is exceeded

The full `dialogData` shape is defined in `makeDialogMockEnv`: https://github.com/odoo/odoo/blob/62c540d96fc49d9e74d8c660019754651cb0e085/addons/web/static/tests/_framework/env_test_helpers.js#L151-L161

### Steps to reproduce:
- Install `l10n_be_pos_blackbox` (fresh `-i`, or `-u` with `web` on an existing db)
- Run the tests in MobileWebSuite

Before the fix, the errors are triggered

runbot-941232

Problem:
When testing the import of contacts with a user without accounting access rights, the test fails and leads to an error.

Steps to reproduce:
1- Remove accounting access rights from your user (Set Accounting to No) 2- Open Contacts app
3- Try importing contacts (you can download the available template and use it as the file you are asked to upload)
4- Test the import
5- Notice the error you receive

Cause:
When importing contacts, the commercial fields (fields related to the contact's parent) are loaded and then written. Some of these fields may have access rights that the user trying to import doesn't have. As a result, when trying to load/write them, the user may get an error.

Solution:
Use sudo() when loading them. This shouldn't be an issue since they are only copied from the parent. Also, sudo() is already being used when writing the values,
https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/odoo/addons/base/models/res_partner.py#L996 so sudo() should also be used when loading them.

opw-6396086

Forward-Port-Of: odoo/odoo#278638

When an internal recipient receives an Out of Office (OOO) notification, the resulting `mail.message` record has `partner_ids` populated with the recipient partner ID, while `outgoing_email_to` is set to `False`.

When a second internal user emails the OOO user within the 4-day window, `_notify_thread_with_out_of_office` excutes a search domain with an OR condition: `'|', ('partner_ids', 'in', recipient.ids), ('outgoing_email_to', '=', email_to)`

Because `email_to` is `False` for internal partners, `('outgoing_email_to', '=', False)` evaluated to `True` against the first recipient's message record. Consequently, the search falsely determined that the second recipient was already notified, suppressing OOO replies for all subsequent contacts across the 4-day window.

## Proposed solution:
We resolve this by dynamically constructing recipient sub-domains conditionally depending if `recipient` or `email_to` are set.
We also extend `test_routing_with_out_of_office` with a corresponding test case.

## How to reproduce:
1. Set up a DB with at least 3 users (User A, User B, User C).
2. Configure User A to be out of office (in user preferences)
3. Go to any chatter/mail.thread while logged as User B and tag User A in a log note. -> triggers OOO message
4. Log as User C, tag User A in a log note. -> BUG: no OOO message because the "4 day" check falsely believes that User C already received a OOO from User A

OPW-6110300

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

Forward-Port-Of: odoo/odoo#279881
Forward-Port-Of: odoo/odoo#277880

Steps to reproduce:
-------------------
1. Install hr_holidays.
2. Create a new Time Off Type with "Duration type" set to Hours.
3. Create a time off request.
4. Change the default hour value (e.g., from 12 AM to 10 AM) and observe the formatted value.
5. Switch the user language to Dutch.
6. Create another time off request and change the hour value to 10 AM.

Issue:
------
After changing the value to 10 AM, the displayed formatted value remains 12 a.m.

Cause:
------
https://github.com/odoo/odoo/blob/c1acf61ab23f231e416354a3504cc3c18170af2c/addons/hr_holidays/static/src/components/float_time_selection/float_time_selection.js#L45-L56 Here, the code attempts to parse the hours and minutes by splitting the already localized formatted string (super.formattedValue) and checking if the formatted value ended with "h" or "m".

In Dutch, the localized string ends with "u" instead of "h", causing the string-matching logic to fail silently and default back to 0 (12 a.m.).

Example: If we change the value to 10:30 AM, in Dutch the formatted value becomes "10u 30m".

Reference: e80750d

Solution:
---------
Stop parsing the localized formatted string and instead compute hours and minutes directly from the float value stored in the record using `floatToHoursMinutes`, making the formatting independent of translations.

opw-6303884


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

Forward-Port-Of: odoo/odoo#271085

### Issue:
When a `stock.move.line` is manually added to a component move of a Manufacturing Order via the debug View button, it is not linked to the MO

This causes the line to appear without a `production_id` in Move History (shown in gray in 18.3+ instead of colored)

### Cause:
`production_id` is set on move lines in `_action_assign`, overridden in `mrp` to propagate MO-specific data: https://github.com/odoo/odoo/blob/e8d4ea2dc71109e9afc5b894c9359bcfc08295ae/addons/mrp/models/stock_move.py#L352-L358

In the normal flow, `_action_assign` is called by `_action_confirm` on the `stock.move`:
https://github.com/odoo/odoo/blob/737e28b9c8609d488d93ce7ce05941ff93779e04/addons/stock/models/stock_move.py#L1644-L1646

But when a line is added manually, the move is already created with state `assigned`, so `_action_confirm` skips the call and `_action_assign` is never executed

### Fix:
Setting `production_id` in `_action_assign` was incorrectly placed — there is no reason to set it during move assignment
Moving it to the move line creation avoids the issue entirely and removes the dependency on a code path that may not be triggered

### Steps to reproduce:
- Install `mrp`
- Create a BoM for a tracked product with 2 tracked components
- Enable Developer mode
- Create a Manufacturing Order for the product
- Unhide the View button on a component move and click it
- Add a new line for the first component (qty: 1)
- Confirm and Produce All the MO
- Go to Inventory > Reporting > Move History
- Add `production_id` via Studio (or check line color in 18.3+)

Before the fix, the manually added line has no `production_id` (and in 18.3+ the line is gray instead of colored)

opw-6250911

Forward-Port-Of: odoo/odoo#279839
Forward-Port-Of: odoo/odoo#272035

### Issue:
When a `stock.move.line` is manually added to a component move of a Manufacturing Order via the debug View button, it is not linked to the MO

This causes the line to appear without a `production_id` in Move History (shown in gray in 18.3+ instead of colored)

### Cause:
`production_id` is set on move lines in `_action_assign`, overridden in `mrp` to propagate MO-specific data: https://github.com/odoo/odoo/blob/e8d4ea2dc71109e9afc5b894c9359bcfc08295ae/addons/mrp/models/stock_move.py#L352-L358

In the normal flow, `_action_assign` is called by `_action_confirm` on the `stock.move`:
https://github.com/odoo/odoo/blob/737e28b9c8609d488d93ce7ce05941ff93779e04/addons/stock/models/stock_move.py#L1644-L1646

But when a line is added manually, the move is already created with state `assigned`, so `_action_confirm` skips the call and `_action_assign` is never executed

### Fix:
Setting `production_id` in `_action_assign` was incorrectly placed — there is no reason to set it during move assignment
Moving it to the move line creation avoids the issue entirely and removes the dependency on a code path that may not be triggered

### Steps to reproduce:
- Install `mrp`
- Create a BoM for a tracked product with 2 tracked components
- Enable Developer mode
- Create a Manufacturing Order for the product
- Unhide the View button on a component move and click it
- Add a new line for the first component (qty: 1)
- Confirm and Produce All the MO
- Go to Inventory > Reporting > Move History
- Add `production_id` via Studio (or check line color in 18.3+)

Before the fix, the manually added line has no `production_id` (and in 18.3+ the line is gray instead of colored)

opw-6250911

Forward-Port-Of: odoo/odoo#272035

In a MO for a product tracked by serial number, when changing the serial number after confirming the mo, it will silently assign a serial number.

**Steps to reproduce**

* Create three products:
  - "Component"
  - "Final" with a bom containing "Component" and tracked by Serial number
  - "Setup" with a bom containing "Final"
* Create and confirm a MO for "Setup"
  - assign the serial number "PROD" to "Final"
* Produce "Setup"
* Create and confirm a MO for "Final"
* Generate a serial number
* Clear the serial number
* Generate a new serial number
* Produce "Final" 
-> In Product Moves you can see that the serial number assign was "PROD"

**Observation**

First when creating the MO, it will create a stock move for "final" and create a stock move line without assigning any quant. action_confirm -> _action_assign
https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_move.py#L1643-L1646 
In _action_assign it will bypass_reservation since the location is "production": https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_move.py#L1948 https://github.com/odoo/odoo/blob/ff0dd8fcc8dfbb5e5cb798c90d68be41d56b7b4c/addons/stock/models/stock_location.py#L411-L413 
and create the sml:
https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/stock/models/stock_move.py#L2048

When adding the Serial number it will be added to lot_producing_ids, set qty_producing and call set_qty_producing ->_set_quantity_done -> _set_quantity_done_prepare_vals: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/mrp/models/mrp_production.py#L1593-L1597 
In set_qty_producing->_set_quantity_done ->_set_quantity_done_prepare_vals nothing will be done since there already is a stock move line with the right quantity: https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/stock/models/stock_move.py#L2368-L2371

Second when clearing the Serial number it will call action_clear_lot_producing_ids, where it will
  - Erase the lot from lot_producing_ids
  - Set qty_producing to 0
  - and call _set_qty_producing _set_qty_producing -> _set_quantity_done -> _set_quantity_done_prepare_vals: where it will erase the stock move line since it's new quantity is 0: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/stock/models/stock_move.py#L2353-L2355

Lastly this means that when add in the new lot, it will not already have a stock move line, and it will create a new stock move line based on available quants: https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/stock/models/stock_move.py#L2392-L2402

The lot_ids on the moves is supposed the get assigned when we produce the product: https://github.com/odoo/odoo/blob/e8aa9219e3c72a987f431e47a1534f9ccb0028b2/addons/mrp/models/mrp_production.py#L1911-L1913

opw-6240857

Forward-Port-Of: odoo/odoo#268542

## Problem
When computing qty_delivered on a sale order line, intercompany 'delieveries' from the other company would count towards the delivery total.

## Solution
When retreiving the relevant moves for quantity calculation (_get_outgoing_incoming_moves), we will filter out any moves not belonging to the SOL's company. This will prevent moves from other companies into the interco location from being counted towards qty_delivered.

## Steps to Replicate (runbot v19)
1. Create a route
    - Pull Comp B -> Interco, MTO, Comp B delivery
    -  Pull Interco -> Comp A, MTS, Comp A receipt
    (You can review the test for more info about this route config)
    (There is also this video showcasing the issue on runbot: https://drive.google.com/file/d/1YeUie4EhWPyg_RuJkNf40S9zARB4jXWY/view)
2. Attach a product to this new route
3. Create a SO for the product and confirm it
4. You should see 4 pickings, validate the chain
5. The qty_delivered on the sale order is double the demand

opw-6361559

Forward-Port-Of: odoo/odoo#275694

**Issue**
The height is not correctly computed in the picking form when editing product description.

**Steps to reproduce**
- Create a delivery for a product
- Add a description to it
- Click on editing the description
 -> Observe that the description is partially hidden because the widget height is incorrectly computed

**Cause**
Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root.

The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`:
https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 
**Solution**
Explicitly add a div around the product display and description to still use the `Autoresize`

Forward-Port-Of: odoo/odoo#271564

### 1. Prevent tour failure by waiting on the correct loading class

Before this PR, the tour introduced in commit [1] and modified in commit [2] could fail non-deterministically because it waited for `o_we_ui_loading` to disappear. However, this class was added with a delay in `operation.js`, allowing the next tour step to run before the loader was shown.

After this commit, the tour waits for `o_loading_screen`, which is added immediately and remains visible until the operation finishes. This ensures that the tour waits correctly before proceeding.

[1]: https://github.com/odoo/odoo/commit/091b8dee407fe30a115d4bb2e96d4d
[2]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711

**runbot:** [941508](https://runbot.odoo.com/odoo/error/941508)

---

### 2. Prevent tour failure by clicking the "Close" button instead of pressing "Escape"

Before this PR, the tour step introduced in commit [1], which pressed the <kbd>Escape</kbd> key to close the Insert Snippet dialog, could fail non-deterministically with the error:

> It is not allowed to do action on an element that's below a modal.

After this PR, instead of pressing <kbd>Escape</kbd>, the tour clicks the **Close** (`X`) button to close the dialog. This is a more reliable way to close the dialog and prevents the non-deterministic failure of the sync color shape tour.

[1]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711d

**runbot:** [944543](https://runbot.odoo.com/odoo/error/944543)

---

### 3. Prevent tour failure by adding steps to open sliding panel for color-related options

Before this PR, the tour introduced in commit [1] and modified in commit [2] was breaking, because it expected the color-related options to be directly available under the theme tab. However, after commit [3], the color-related controls were moved into a sliding panel.

This PR adds the missing steps to open the sliding panel before accessing the color-related options, allowing the tour to complete successfully.

[3]: https://github.com/odoo/odoo/commit/8e104a3a416781a903f3b3b4b77e5f8be24fc7b0

**runbot:** [944587](https://runbot.odoo.com/odoo/error/944587)

Forward-Port-Of: odoo/odoo#279395
Forward-Port-Of: odoo/odoo#278743

recently in 19.1 a commit adds a warning and disables the button in the signup for if you are alreafy logged in. The issue is that for websites without the header (which is the case for internal, but can happen to customers) there is no way to get to the homepage (except from writing to the url or hiting the back button)

This created an issue in internal as an example, since our customers have aparently bookmarked the login page, and they would simply login again before this. For some people, since they would access the page so often, google automatically fill up the url when they type odoo to odoo/web/login

This commit aims to introduce a link to the home page that will be displayed in the warning message. This way cusotmers can get to the home page, and we will hopefully stop the support tickets this has created

opw-6331783

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

Problem:
When testing the import of contacts with a user without accounting access rights, the test fails and leads to an error.

Steps to reproduce:
1- Remove accounting access rights from your user (Set Accounting to No) 2- Open Contacts app
3- Try importing contacts (you can download the available template and use it as the file you are asked to upload)
4- Test the import
5- Notice the error you receive

Cause:
When importing contacts, the commercial fields (fields related to the contact's parent) are loaded and then written. Some of these fields may have access rights that the user trying to import doesn't have. As a result, when trying to load/write them, the user may get an error.

Solution:
Use sudo() when loading them. This shouldn't be an issue since they are only copied from the parent. Also, sudo() is already being used when writing the values,
https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/odoo/addons/base/models/res_partner.py#L996 so sudo() should also be used when loading them.

opw-6396086

Forward-Port-Of: odoo/odoo#278638

### Steps to reproduce:
- Set the environment timezone (`env.tz`) to a timezone ahead of UTC (e.g., Europe/Brussels)
- Run the enterprise tests (L10n standalone, Single app, or Multi l10n) during the late evening in UTC (e.g., 23:00 UTC)

> UserError: The Payment Date cannot be later than the Value Date, please make sure that the
correct dates are set

### Cause of Issue:
In the payroll payment report wizards, a race condition occurs around midnight due to mismatched timezone context evaluations between different date fields. The `effective_date` field (defined in the base hr_payroll module) derives its default value using `fields.Date.context_today`, which correctly applies the client's timezone offset to the current server time.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L23-L26

However, `l10n_sa_wps_value_date` (and similar date fields in other localizations like AU, HK, AE) derives its default value using `fields.Date.today()`, which strictly relies on the server's UTC time.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/l10n_sa_hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L13-L14

When the nightly Runbot builds execute late at night UTC time, the environment timezone frequently crosses midnight into "tomorrow" while the server time is still on "today". Because of this offset, `effective_date` rolls over to tomorrow, but `l10n_sa_wps_value_date` evaluates as today + 1 day (which is also tomorrow). The validation check `effective_date >= l10n_sa_wps_value_date` evaluates to True.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/l10n_sa_hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L93-L94

### Fix:
Standardize the default date computations to ensure they are all evaluated within the same timezone context and prevent the midnight timezone rollover discrepancy.

runbot-937793

Problem:
When testing the import of contacts with a user without accounting access rights, the test fails and leads to an error.

Steps to reproduce:
1- Remove accounting access rights from your user (Set Accounting to No) 2- Open Contacts app
3- Try importing contacts (you can download the available template and use it as the file you are asked to upload)
4- Test the import
5- Notice the error you receive

Cause:
When importing contacts, the commercial fields (fields related to the contact's parent) are loaded and then written. Some of these fields may have access rights that the user trying to import doesn't have. As a result, when trying to load/write them, the user may get an error.

Solution:
Use sudo() when loading them. This shouldn't be an issue since they are only copied from the parent. Also, sudo() is already being used when writing the values,
https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/odoo/addons/base/models/res_partner.py#L996 so sudo() should also be used when loading them.

opw-6396086

Forward-Port-Of: odoo/odoo#278638

Currently, when a quotation is created from a repair order generated from a helpdesk ticket, 
the salesperson is not set on the quotation even if the customer has a salesperson assigned.

**Steps to Reproduce:**

 - Install `helpdesk_repair`.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams`.
 - Open a team recod and enable `Repairs`.
 - Create a `contact/customer` with a `salesperson` assigned.
 - Go to `Helpdesk`, create a ticket for that `customer`, and select the `helpdesk team` 
   configured above.
 - Click `Repair`, then click `Create Quotation`.
 - Open the quotation and check the `Salesperson` field in the `Other Info` tab.

**Current behavior:**
The Salesperson field on the quotation remains empty.

**Expected behavior:**
The Salesperson field on the quotation should inherit the salesperson assigned to the 
selected customer/contact.

**Cause of the issue:**
When a repair order is created from a helpdesk ticket, default_user_id [1] is passed in the context . 
This value is propagated when creating the repair order [2] . Later, when creating the quotation from 
the repair order [3], the same context is reused.
Because default_user_id is already present in the context, it overrides the precomputation of user_id 
from the customer. As a result, user_id is initialized with an empty value and remains unset.

**Fix:**
This commit ensures that default_user_id is removed from the context before creating the 
sale order. Without a default value for user_id, the field is correctly precomputed from the 
selected customer, and the salesperson is properly assigned.
[1]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L52

[2]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L36-L40

[3]: https://github.com/odoo/odoo/blob/29328b8fccff833c14de317b51f3b4e5a8c40f75/addons/repair/models/repair.py#L357

opw-6344939

Forward-Port-Of: odoo/enterprise#126310
Forward-Port-Of: odoo/enterprise#122980

Currently, users encounter a traceback when attempting to print the traceability report for a manufacturing order.

## Steps to produce:
- Install Manufacturing without demo data.
- Enable Lots & Serial Numbers in Settings.
- Create two products: Car and Engine.
- Configure Engine to use Unique Serial Number tracking (Inventory →Traceability).
- Set the on-hand quantity of Engine to 1 with serial number 0001.
- Create a BoM for Car using Engine as a component.
- Create and confirm a manufacturing order for Car.
- Click `Consumed` for the component and click Produce All.
- Navigate to Lots & Serial Numbers → Engine → 0001 → Traceability.
- Click the arrow next to the manufacturing order reference, then click Print.

## Observed Behavior:
An `Arbitrary Uncaught Python Exception` traceback is raised, resulting in a 404 error.

## Root Cause:
This issue occurs because, when the user clicks the arrow button in the traceability report, the template [1] invokes the `onClickUpDownStream` function.

This function adds the URL `/stock/output_format/stock/active_id` to the context , as shown in [2]. Later, when the user clicks the Print button, `onClickPrint()` [3] constructs the print URL using the `controllerUrl` value by replacing the active model and active ID placeholders with values from the context.

However, the URL stored in the context contains `/active_id` instead of `:active_id`. As a result, the placeholder replacement does not occur, leaving the URL unchanged. This causes the print action to use an invalid URL, ultimately resulting in a 404 error.

As shown in [4], `controllerUrl` is assigned directly from the context.

[1]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L52-L56 [2]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L105-L118 [3]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L120-L131 [4]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L53-L55

## Solution:
Pass the correct URL in the context so that the active ID placeholder can be replaced correctly during the print action. This ensures that the generated print URL is valid, allowing the user to print the report without encountering any errors.


opw-6372834

Forward-Port-Of: odoo/odoo#276449

**Summary**:
When a user receives products from a Purchase Order and later decreases the ordered quantity below the quantity already received, Odoo currently allows the change to be saved. This leaves the Purchase Order in an inconsistent state, where the received quantity exceeds the ordered quantity.

**Steps to reproduce:**
- Install the Purchase and Inventory modules.
- Create a Purchase Order with one storable product.
- Set the ordered quantity to 10.
- Confirm the Purchase Order.
- Receive all 10 units and validate the receipt.
- Return to the Purchase Order.
- Change the ordered quantity from 10 to 5.
- Save the Purchase Order.

**Observed Behavior:**
The Purchase Order is saved successfully even though only 5 units are ordered while 10 units have already been received.

This results in an inconsistent state because the ordered quantity becomes lower than the quantity already received, breaking the expected business logic and potentially leading to inconsistencies between purchase and stock data.

**Previous behavior:**
Until v18.0, Odoo prevented users from decreasing the ordered quantity below the quantity already received by raising a validation error.

Starting from v18.3, following the introduction of the new purchase quantity update flow (see PR #209110), this validation is no longer applied when updating the ordered quantity, allowing the Purchase Order to be saved in an inconsistent state.

**Cause:**
The new purchase quantity update flow introduced in v18.3 updates the Purchase Order line without validating that the new ordered quantity remains greater than or equal to the quantity already received.

As a result, decreasing the ordered quantity below `qty_received` is accepted, creating an inconsistent Purchase Order where the received quantity exceeds the ordered quantity. This regression was introduced because the validation present in the previous flow is no longer enforced in the new update flow.

**Fix:**
Restore the missing validation in the new purchase quantity update flow to prevent decreasing the ordered quantity below the already received quantity.

If a user attempts to do so, raise a `UserError` instructing them to create a return before reducing the ordered quantity.

opw-[6270228](https://www.odoo.com/odoo/project/49/tasks/6270228)

Currently, an error occurs when a user sets an employee on a payslip.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Create an `employee` and make sure that the employee's version has no `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and set that employee.

`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

When a user sets an employee on a payslip, the system computes the worked day lines [1]. 
If the salary structure uses worked day lines, it creates the corresponding records [2] and 
calculates out days and out hours based on the contract dates.
During this process, the payslip dates are compared with the version's contract start date. 
If the version does not have a contract start date, it raises an error [3].

This commit ensures that the payslip dates are compared with the version's contract start date, 
and that out days and out hours are calculated only when the contract start date exists. Cases 
where no contract start date is defined are already handled in payslip [4].

[1]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1964

[2]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1985-L1988

[3]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/l10n_hk_hr_payroll/models/hr_payslip.py#L309

[4]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1092-L1096

sentry-7632216317

Forward-Port-Of: odoo/enterprise#120234

When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in payment_ref.

If this payment refs contains only spaces (eg. ' '), it will trigger an index out of range traceback. This is explained by the fact that spaces are striped then '' is considered as False in some filtering leaving the list empty.

From the UI, putting ' ' is not supposed to be possible because spaces are striped before write but there is many ways to import statement lines which may lead to this hence the decision of handling this scenario to make the code more robust.

Steps to reproduce:
1/ Create two statement lines with payment_ref as ' ' (you can force it using a write)
2/ Click "Set account" on first one and pick 100000 Issued Capital
3/ Do the same for the second statement line
=> Traceback

In this commit, we do not check for common substring if there is less than two
labels.

opw-6379977

Currently, users encounter a traceback when attempting to print the traceability report for a manufacturing order.

## Steps to produce:
- Install Manufacturing without demo data.
- Enable Lots & Serial Numbers in Settings.
- Create two products: Car and Engine.
- Configure Engine to use Unique Serial Number tracking (Inventory →Traceability).
- Set the on-hand quantity of Engine to 1 with serial number 0001.
- Create a BoM for Car using Engine as a component.
- Create and confirm a manufacturing order for Car.
- Click `Consumed` for the component and click Produce All.
- Navigate to Lots & Serial Numbers → Engine → 0001 → Traceability.
- Click the arrow next to the manufacturing order reference, then click Print.

## Observed Behavior:
An `Arbitrary Uncaught Python Exception` traceback is raised, resulting in a 404 error.

## Root Cause:
This issue occurs because, when the user clicks the arrow button in the traceability report, the template [1] invokes the `onClickUpDownStream` function.

This function adds the URL `/stock/output_format/stock/active_id` to the context , as shown in [2]. Later, when the user clicks the Print button, `onClickPrint()` [3] constructs the print URL using the `controllerUrl` value by replacing the active model and active ID placeholders with values from the context.

However, the URL stored in the context contains `/active_id` instead of `:active_id`. As a result, the placeholder replacement does not occur, leaving the URL unchanged. This causes the print action to use an invalid URL, ultimately resulting in a 404 error.

As shown in [4], `controllerUrl` is assigned directly from the context.

[1]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.xml#L52-L56 [2]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L105-L118 [3]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L120-L131 [4]:
https://github.com/odoo/odoo/blob/a398ade607940a281552f8cba2c1cf80bb0e77f6/addons/stock/static/src/client_actions/stock_traceability_report_backend.js#L53-L55

## Solution:
Pass the correct URL in the context so that the active ID placeholder can be replaced correctly during the print action. This ensures that the generated print URL is valid, allowing the user to print the report without encountering any errors.


opw-6372834

Forward-Port-Of: odoo/odoo#276449