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

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

Posting a message bumps discuss_channel.last_interest_dt. _update_last_interest_dt writes it in a separate transaction so the channel row lock is released almost instantly, letting parallel posters proceed instead of piling up on that hot row and crashing with:

    could not serialize access due to concurrent update

However, when the main transaction also writes the channel row (e.g. im_livechat sets livechat_failure in _message_post_after_hook), it holds the row lock for the whole request. The separate transaction then blocks on that lock until timeout. It is not even reported as a deadlock, since the main transaction is not itself waiting on anything, so the request just hangs.

Update last_interest_dt at the end of the post flow, in _message_post_after_hook, once all the channel writes it may trigger have been done. There, if the channel row is already dirty in the main transaction, write last_interest_dt on that transaction rather than a separate one: its row is already locked, so a separate transaction has nothing to gain and would only block.

task-6321278



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

Currently, when using the quick create form to create a calendar.event, if you set up the event for the whole day the show_as field will always be saved as free no matter the value set by the user.

Steps to reproduce:
-------------------
* Open Calendar app
* Select the a slot that corresponds to a whole day
* Ensure all day is ticked
* Change 'Available' to 'Busy'
* Save
* Select the slot and select Edit
> Observe that the status is showing 'Available'

Why the fix:
------------
The defaults should be: all day = free, not all day = busy However those values should still remain modifyable.

This commit https://github.com/odoo/odoo/commit/62ecdba6dc963ddcdfca9e2e924ae5f6ca34e5de states:
> When the user toggles allDay within the edit form, the availability is recomputed (this behavior matches google calendar)

For the normal form itself the onchange triggers and behaves as stated. And if the user decides to change the show_as value it will save its choice correctly.

For the quick create form, the onchange also triggers correcly. Meaning the velue of show_as is recomputed depending on allday. However upon saving, the value of show_as is bypassed if allday is true but it should keep the value selected by the user.

opw-6326575

Forward-Port-Of: odoo/odoo#273567

### 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#279227
Forward-Port-Of: odoo/odoo#276306

### Steps to reproduce:
- Install `sale_mrp` and `l10n_ke_edi_oscu_stock`
- Set company country to be 'Kenya'
- Run the `test_kit_cogs_entry_with_delivery_line_removal` test
> odoo.exceptions.UserError: Cannot create an invoice. No items are available to invoice.

### Cause of Issue:
The test validates COGS entries for a kit by creating a sale order, then generating an invoice.

When `l10n_ke_edi_oscu_stock` is installed, it overrides the `invoice_policy` of all storable products for Kenyan companies to `'delivery'`.
https://github.com/odoo/enterprise/blob/82b736a283ed5ab3ad431a1cdbcedc1b8e3c2d7c/l10n_ke_edi_oscu_stock/models/product.py#L16-L21

Because the test removes a required component from the picking, the delivered quantity of the kit is computed as 0. Since the kit's invoice policy is dynamically forced to `'delivery'` by the localization, calling `_create_invoices()` raises a `UserError` as there are no delivered items to invoice, failing the test on runbot.

### Fix:
Ensure that kit product use an invoicing policy of 'Ordered Quantities' rather than the default 'Delivered Quantities'. This allows the test to proceed and correctly evaluate the core COGS computation logic it was designed to check.

runbot-243342

Forward-Port-Of: odoo/odoo#279450

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**
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

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

Currently, when using the quick create form to create a calendar.event, if you set up the event for the whole day the show_as field will always be saved as free no matter the value set by the user.

Steps to reproduce:
-------------------
* Open Calendar app
* Select the a slot that corresponds to a whole day
* Ensure all day is ticked
* Change 'Available' to 'Busy'
* Save
* Select the slot and select Edit
> Observe that the status is showing 'Available'

Why the fix:
------------
The defaults should be: all day = free, not all day = busy However those values should still remain modifyable.

This commit https://github.com/odoo/odoo/commit/62ecdba6dc963ddcdfca9e2e924ae5f6ca34e5de states:
> When the user toggles allDay within the edit form, the availability is recomputed (this behavior matches google calendar)

For the normal form itself the onchange triggers and behaves as stated. And if the user decides to change the show_as value it will save its choice correctly.

For the quick create form, the onchange also triggers correcly. Meaning the velue of show_as is recomputed depending on allday. However upon saving, the value of show_as is bypassed if allday is true but it should keep the value selected by the user.

opw-6326575

Forward-Port-Of: odoo/odoo#273567

### Steps to reproduce:
- Install `sale_mrp` and `l10n_ke_edi_oscu_stock`
- Set company country to be 'Kenya'
- Run the `test_kit_cogs_entry_with_delivery_line_removal` test
> odoo.exceptions.UserError: Cannot create an invoice. No items are available to invoice.

### Cause of Issue:
The test validates COGS entries for a kit by creating a sale order, then generating an invoice.

When `l10n_ke_edi_oscu_stock` is installed, it overrides the `invoice_policy` of all storable products for Kenyan companies to `'delivery'`.
https://github.com/odoo/enterprise/blob/82b736a283ed5ab3ad431a1cdbcedc1b8e3c2d7c/l10n_ke_edi_oscu_stock/models/product.py#L16-L21

Because the test removes a required component from the picking, the delivered quantity of the kit is computed as 0. Since the kit's invoice policy is dynamically forced to `'delivery'` by the localization, calling `_create_invoices()` raises a `UserError` as there are no delivered items to invoice, failing the test on runbot.

### Fix:
Ensure that kit product use an invoicing policy of 'Ordered Quantities' rather than the default 'Delivered Quantities'. This allows the test to proceed and correctly evaluate the core COGS computation logic it was designed to check.

runbot-243342

Forward-Port-Of: odoo/odoo#279450

**Description of the issue/feature this PR addresses:**

When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line.

This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely.

This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal.

The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO.

opw-6279406

**Steps to Reproduce:**

- Accounting > Configuration > Settings > Analytics > enable Analytic Accounting
- Accounting > Configuration > Analytic Accounting > Analytic Distribution Models
  - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”)
- Create SO, enable “Analytic Distribution” in filters
  - Add any customer, add the above product (e.g. “Bolt”), save
  - Observe that the “Production” Analytic Distribution is automatically populated
- On the same SO > Other Info> Project > add (e.g. “Home Construction”)
  - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save
  - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is)


**Current behavior before PR:**

- Product analytic distributions are not automatically applied when the Sales Order is already linked to a project

**Desired behavior after PR is merged:**

- Product analytic distributions are automatically applied even when the Sales Order is linked to a project

**Note:**

This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote:

>However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic
distribution, as it is much harder to add it again after its removal.
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.

The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799

Forward-Port-Of: odoo/odoo#274893

Steps to reproduce
1. Create two products and assign the same vendor to both in the Purchase tab
2. Create two Sales Orders using the dropship route (one product per order)
3. Generate and merge the corresponding Purchase Orders, then confirm the merged PO
4. Validate the dropship transfer

Issue
stock.picking.sale_id is a Many2one (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/sale_stock/models/stock.py#L99)
computed from procurement.group.sale_id, and stock.picking.group_id is a
stored related on move_ids.group_id (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/stock/models/stock_picking.py#L186).
A single picking can therefore only resolve to one SO. _create_picking
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order.py#L290)
builds one picking per PO and _prepare_stock_moves assigns every move
the merged PO's group_id
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order_line.py#L307),
so when a merged dropship PO carries lines from multiple SOs every move
lands in one picking under the PO group. Only one SO gets linked and
the others stay "not fully delivered" even after validation.

Solution
Override PurchaseOrderLine._prepare_stock_moves to set group_id to the
SO's procurement_group_id when sale_line_id is set, so each dropship
move is created in its originating SO's procurement group.

Override PurchaseOrder._create_picking to detect dropship POs whose
order lines span more than one SO and create one picking per SO group
by calling _prepare_picking and _create_stock_moves per group.
picking.group_id then resolves to the SO group via the stored related
field, picking.sale_id points to the right SO, and delivery_status
updates correctly on validation.

opw-6094608

Forward-Port-Of: odoo/odoo#279843
Forward-Port-Of: odoo/odoo#257823

[*]=website

1. Sync background shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    3. Drop any snippet.
    4. Add a background shape.
    5. Set the background shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
  
    Issue:
    The background shape color is not updated when the theme color changes.
    
    Reason:
    The background shape color is embedded in the URL of the "**background-image**" style attribute. When the theme color value changes, this URL is not updated. Additionally, the URL uses color variables rather than resolved hexadecimal color values as parameters. As a result, even when an updation occurs, the URL itself remains unchanged, preventing the background shape color from being updated.
    
2. Sync image shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    2. Drop any snippet.
    4. Click on the image and add a shape.
    5. Set the image shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
    
    Issue:
    The image shape color is not updated when the theme color changes.
    
    Reason:
    When the theme color value changes, the SVGs are not re-fetched. Additionally, the image "**shapeColors**" dataset stores the hexadecimal value of the theme color instead of the corresponding CSS variable. As a result, there is no way to determine which theme color was selected (for example, whether `o-color-1` or `o-color-2`), since only the hex value is available.


task-5438314

Forward-Port-Of: odoo/odoo#274079
Forward-Port-Of: odoo/odoo#241968

**Description of the issue/feature this PR addresses:**
`test_search_date_category` is failing across runbot builds

Remove the blanket deletion of all repair orders at the start of test_search_date_category and replace the exact count assertion with assertIn. This avoids interfering with other test data and makes the test resilient to pre-existing records in the database.

**Current behavior before PR:**
```
ERROR: TestRepair.test_search_date_category
Traceback (most recent call last):
  File "/data/build/odoo/addons/repair/tests/test_repair.py", line 915, in test_search_date_category
    self.env['repair.order'].search([]).unlink()
  File "/data/build/odoo/addons/rating/models/mail_thread.py", line 21, in unlink
    result = super().unlink()
             ^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/mail/models/mail_thread.py", line 391, in unlink
    res = super(MailThread, self).unlink()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/mail/models/models.py", line 46, in unlink
    result = super().unlink()
             ^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/models.py", line 4131, in unlink
    func(self)
  File "/data/build/odoo/addons/repair/models/repair.py", line 421, in _unlink_except_confirmed
    repairs_to_cancel.action_repair_cancel()
  File "/data/build/enterprise/quality_repair/models/repair.py", line 114, in action_repair_cancel
    res = super().action_repair_cancel()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/repair/models/repair.py", line 475, in action_repair_cancel
    raise UserError(_("You cannot cancel a Repair Order that's already been completed"))
odoo.exceptions.UserError: You cannot cancel a Repair Order that's already been completed
```
**Desired behavior after PR is merged:**
`test_search_date_category` passes

opw-[4998413](https://www.odoo.com/odoo/my-tasks/4998413)
runbot.build.error-[231146](https://runbot.odoo.com/odoo/runbot.build.error/231146)

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

Forward-Port-Of: odoo/odoo#267852

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

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

**Description of the issue/feature this PR addresses:**

When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line.

This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely.

This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal.

The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO.

opw-6279406

**Steps to Reproduce:**

- Accounting > Configuration > Settings > Analytics > enable Analytic Accounting
- Accounting > Configuration > Analytic Accounting > Analytic Distribution Models
  - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”)
- Create SO, enable “Analytic Distribution” in filters
  - Add any customer, add the above product (e.g. “Bolt”), save
  - Observe that the “Production” Analytic Distribution is automatically populated
- On the same SO > Other Info> Project > add (e.g. “Home Construction”)
  - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save
  - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is)


**Current behavior before PR:**

- Product analytic distributions are not automatically applied when the Sales Order is already linked to a project

**Desired behavior after PR is merged:**

- Product analytic distributions are automatically applied even when the Sales Order is linked to a project

**Note:**

This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote:

>However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic
distribution, as it is much harder to add it again after its removal.
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.

The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799

Forward-Port-Of: odoo/odoo#274893

Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were written with a trailing comma inside the XML id, making the two checks silently fail for everyone. Only the accounting read group check, written correctly, was effective.

Steps to reproduce:
- create a service product with "Create on Order: Project & Task", sell it on a sale order and confirm it
- create a down payment invoice from the sale order and post it
- create a user with Sales "User: All Documents" access, Project "User" access and no accounting access
- as that user, open the dashboard of the generated project and look at the Down Payments line of the profitability panel

The Down Payments amount is displayed as plain text, while a user with accounting access can click it to open the related invoices, as intended for the salesperson too.

Solution:
Move the commas out of the group references.

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

Forward-Port-Of: odoo/odoo#278521

Steps to reproduce
1. Create two products and assign the same vendor to both in the Purchase tab
2. Create two Sales Orders using the dropship route (one product per order)
3. Generate and merge the corresponding Purchase Orders, then confirm the merged PO
4. Validate the dropship transfer

Issue
stock.picking.sale_id is a Many2one (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/sale_stock/models/stock.py#L99)
computed from procurement.group.sale_id, and stock.picking.group_id is a
stored related on move_ids.group_id (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/stock/models/stock_picking.py#L186).
A single picking can therefore only resolve to one SO. _create_picking
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order.py#L290)
builds one picking per PO and _prepare_stock_moves assigns every move
the merged PO's group_id
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order_line.py#L307),
so when a merged dropship PO carries lines from multiple SOs every move
lands in one picking under the PO group. Only one SO gets linked and
the others stay "not fully delivered" even after validation.

Solution
Override PurchaseOrderLine._prepare_stock_moves to set group_id to the
SO's procurement_group_id when sale_line_id is set, so each dropship
move is created in its originating SO's procurement group.

Override PurchaseOrder._create_picking to detect dropship POs whose
order lines span more than one SO and create one picking per SO group
by calling _prepare_picking and _create_stock_moves per group.
picking.group_id then resolves to the SO group via the stored related
field, picking.sale_id points to the right SO, and delivery_status
updates correctly on validation.

opw-6094608

Forward-Port-Of: odoo/odoo#279843
Forward-Port-Of: odoo/odoo#257823

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)

Current behaviour:
In the Calendar view (day/week/month scale), when the user's timezone observes a DST transition that starts exactly at local midnight (e.g. Africa/Cairo, since 2023), the day column right after the transition gets the wrong weekday name, duplicating the previous day's name. For ex. it renders "... THU THU FRI ..." instead of "... THU FRI SAT ...", for the week surrounding April 30th 2027.

To fix this we add 1 hour to the Date before reading its weekday/day from it, mirroring the workaround FullCalendar itself adopted for this same bug. It has no effect on any ordinary day (adding 1h to a correct local midnight stays within the same calendar day), and it cannot overshoot into the next day since no real-world DST gap exceeds that margin.

Note: This is a known bug (https://github.com/fullcalendar/fullcalendar/issues/7633), fixed in FullCalendar v6.1.17, a major version ahead of the v4.4.0, so the fix can't be applied directly without a full library upgrade.

opw-6370140

Forward-Port-Of: odoo/odoo#279836
Forward-Port-Of: odoo/odoo#279343

**Description of the issue/feature this PR addresses:**

When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line.

This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely.

This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal.

The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO.

opw-6279406

**Steps to Reproduce:**

- Accounting > Configuration > Settings > Analytics > enable Analytic Accounting
- Accounting > Configuration > Analytic Accounting > Analytic Distribution Models
  - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”)
- Create SO, enable “Analytic Distribution” in filters
  - Add any customer, add the above product (e.g. “Bolt”), save
  - Observe that the “Production” Analytic Distribution is automatically populated
- On the same SO > Other Info> Project > add (e.g. “Home Construction”)
  - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save
  - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is)


**Current behavior before PR:**

- Product analytic distributions are not automatically applied when the Sales Order is already linked to a project

**Desired behavior after PR is merged:**

- Product analytic distributions are automatically applied even when the Sales Order is linked to a project

**Note:**

This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote:

>However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic
distribution, as it is much harder to add it again after its removal.
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.

The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799

Forward-Port-Of: odoo/odoo#274893

Before this commit, the down payments line of the project profitability panel had no drill down action for salespersons and billing users without accounting access, because the group references were written with a trailing comma inside the XML id, making the two checks silently fail for everyone. Only the accounting read group check, written correctly, was effective.

Steps to reproduce:
- create a service product with "Create on Order: Project & Task", sell it on a sale order and confirm it
- create a down payment invoice from the sale order and post it
- create a user with Sales "User: All Documents" access, Project "User" access and no accounting access
- as that user, open the dashboard of the generated project and look at the Down Payments line of the profitability panel

The Down Payments amount is displayed as plain text, while a user with accounting access can click it to open the related invoices, as intended for the salesperson too.

Solution:
Move the commas out of the group references.

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

Forward-Port-Of: odoo/odoo#278521

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

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

**Steps to reproduce:**
- Go to CRM app as an internal user (non-admin)
- Click on Generate button
- Can't create leads from business card pictures
- Only setting the user as admin enables it (was working fine in previous versions)

**Issue:**
Dropdown action is restricted to admin only by default using `hasAccess`.
If there is a corresponding model on the `LeadGenerationDropdown` it is later changed according to the current user access rights using `await user.checkAccessRight(model, "create")`.

**Fix:**
Default `hasAccess` to `True` as there is no related model for the lead generation of business cards.
(Note: could also provide the missing model ?)

- Installation should be restricted to the admin.
- Access message should be shown to the user if he doesn't have enough rights to the related model.
- Non-admin users should be able to use the feature if no model is provided and the related app is available.

dropdown: https://github.com/odoo/odoo/commit/978019522746ccb971eeb15c5d9530e438b7d2f3
business card: https://github.com/odoo/enterprise/commit/48a9cba24cb51b11a08dd9c0ff1291e15232260f

opw-6258689

Forward-Port-Of: odoo/enterprise#121682

**Step To Reproduce:**

1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display).
2. Create a new order in the POS and add the first product.
3. Observe that the order does not appear on the Kitchen Display.
4. Add a second product to the same order.
5. Observe that the order now appears on the Kitchen Display.

**Issue:**

The first product of a new restaurant order is not synchronised with the Kitchen Display when the German Fiskaly localisation is enabled.

**Reason:**

`syncAllOrders()` only processes orders returned by `getPendingOrder()` and ignores orders explicitly passed through `options.orders`. After the initial Fiskaly synchronisation, the order is serialised and removed from the pending queue. Consequently, the Preparation Display synchronisation receives no orders from `getPendingOrder()`, preventing the order from reaching the backend.

**Solution:**

Update `syncAllOrders()` to prioritize the orders explicitly provided through `options.orders`. When `options.orders` is not available, fall back to the existing behavior by synchronizing the orders from `orderToCreate` and `orderToUpdate`.

opw-6321376

Forward-Port-Of: odoo/enterprise#125743

**Problem:**
On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate.

**Steps to reproduce:**
1. Install `website_sale_renting_planning`.
2. Create a planning role with `sync_shift_rental` and one resource.
3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above.
4. Pre-book the resource for some window via a `planning.slot`.
5. From eCommerce, add the product to the cart for the same window.
6. Proceed to checkout/payment.

**Current behavior:**
The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period.

**Expected behavior:**
The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity.

**Cause of the issue:**
`sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but
`website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all.

**Fix:**
Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types.

opw-6247034

Forward-Port-Of: odoo/enterprise#125855
Forward-Port-Of: odoo/enterprise#118943

Once a lock date is set on a company, report lines that look back before a given date, such as a Balance Sheet's "Profits (Losses) from Previous Years", could silently lose data. Any line that gets captured in a snapshot and uses a date scope 'to_beginning_of_*' was affected.

Snapshots are computed on the options of the lock date and stored with their 'date' set to the options' date_to (the lock date). Only 'from_beginning' actually evaluates the accounting up to date_to. The 'to_beginning_of_*' scopes stop right before the period or fiscal year, so the data really aggregated stops earlier than the stored date:

  - 'to_beginning_of_fiscalyear': up to a whole fiscal year earlier.
  - 'to_beginning_of_period': up to a whole period earlier.

When the report is rendered, the engine sums only the moves dated after the snapshot's date and adds the snapshot's data. Everything between the snapshot's real cut-off and its (later) stored date is never counted.

Aim the options at the lock date so each scope's bound falls on it, and store the date really covered(using _get_date_bounds_info()). The snapshot's date then always matches its data, and "to_beginning_of_*" covers the last fiscal year starting before the lock date instead of forcing every later render to rescan it.

Snapshots written before this fix still hold the mismatched date, so the account_codes sub-engine version is bumped to 2 to re-trigger the snapshots generation

opw-6379956

Forward-Port-Of: odoo/enterprise#126542

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

**Steps to reproduce:**
1. Install Accounting and l10n_be and switch to the Belgian company
2. In the settings, set the discount account (`708000`) on Customer Invoices under "Default Accounts" and enable analytic accounting
3. Go to [Accounting -> Configuration -> Analytic Accounts] and create 4 new accounts with "Project" plan (i.e 1,2,3,4)
4. Create a new invoice with two lines, each having 2 of the analytic accounts with 50% each.
5. Set the price to 1000 and a 10% discount for each line then save.
6. Edit the second line and set the discount to 20%.
7. Open the Journal Items tab

**Issue:**
 - When an invoice contains multiple lines with analytic distributions, changing the discount percentage on any line other than the first fails to correctly update the analytic distribution percentages on the corresponding discount journal items.
- The analytic account distribution splits the percentage evenly across both accounts event if they are not split 50/50

**Why this happens:**
- This occurred because `_compute_discount_allocation_needed` iterated over `self` to populate target changes. When only one line was modified, `self` contains that line only which is correctly updated with the new analytic distribution. Later in the execution in `_sync_dynamic_line`, particularly in https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move.py#L2263-L2274 The first line in `computed_needed` is what gets set in res, and subsequent lines only modify the field if it's monetary. So if the second invoice line is the one  updated, it will never override the `analytic_distribution` with the updated values, leaving stale values in that field.
- The code iterated directly over `line.analytic_distribution` dictionary keys (the account IDs) rather than its `.items()`. This caused it to ignore the individual percentage value splits (e.g. 60/40), accumulating the un-weighted full discount amount to each account ID. https://github.com/odoo/odoo/blob/5a14360705a55f4d91edf39c936d7a5d8573044b/addons/account/models/account_move_line.py#L1044-L1052

**Fix:**
- Change the processing loop  inside `_compute_discount_allocation_needed` from `self` to `self.move_id.line_ids` to calculate the correct `analytic_distribution` across all records.
- Applying the factored weight ratio (`amount * (percentage / 100.0)`) to `distribution_totals`

opw-6362084

Forward-Port-Of: odoo/odoo#275070

Steps to reproduce:
- Install 'Sales', 'Accounting' and 'l10n_sa_edi'
- Settings > Accounting > Rounding Method > Round Globally
- Create an invoice whose per-line tax base is fractional (e.g. a price-included 15% VAT, 3 lines at 10.00 -> base 8.6957 each)
- Generate the ZATCA UBL document

Issue:
The exported document is internally inconsistent and is rejected by ZATCA (BR-CO-13): cbc:LineExtensionAmount (BT-106) = 26.10 while cbc:TaxExclusiveAmount (BT-109), and thus the QR / PayableAmount (BT-115), = 26.09. This is the same 0.01 discrepancy reported for 100% down-payment invoices under global rounding.

Cause:
LineExtensionAmount was built by summing account.move.line.price_subtotal, which is always rounded per line (8.70 x 3 = 26.10), whereas TaxExclusiveAmount is built from the aggregated base_amount_currency, which follows the company rounding method and is rounded globally (26.087 -> 26.09). Under 'round_globally' the two diverge by a cent.

This is the base-amount counterpart of commit 3d398789, which aligned the prepaid tax amount to global rounding but left the line net amount on per-line rounding.

Solution:
Derive the line net amount from the globally-rounded aggregated base (taxes_vals['base_amount_currency'])
https://github.com/odoo/odoo/blob/c7c361e6af4da43dc1f9653703067ffe6500a046/addons/account/models/account_tax.py#L1529 instead of the per-line rounded
price_subtotal, consistent with total_amount_sa on the same line. The whole document now stays on a single rounding basis, so the sum of the line net amounts equals the TaxExclusiveAmount and BR-CO-13 is satisfied.

opw-5881564