Following this commit : - getRenderedReceipt method is optimised to pass dynamic values. - o-employee-name class has been added for applying xpath. Enterprise PR: https://github.com/odoo/enterprise/pull/81559 task-4633156 Forward-Port-Of: odoo/odoo#207731 Forward-Port-Of: odoo/odoo#202003

Following this commit :
- getRenderedReceipt method is optimised to pass dynamic values.
- o-employee-name class has been added for applying xpath.
Enterprise PR: https://github.com/odoo/enterprise/pull/81559

task-4633156

Forward-Port-Of: odoo/odoo#207731
Forward-Port-Of: odoo/odoo#202003

Before this commit, the second and onwards view of the product screen will pull and sort products by the data stored in IndexedDB. The first load of the product screen sorts based on a SQL query, whose sorting may be lost on sequential loads of the product screen. This change maintains the sort sequence to 'product.template' when loading the product screen when IndexedDB exists in the browser. opw-4584724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su

Before this commit, the second and onwards view of the product screen will pull and sort products by the data stored in IndexedDB. The first load of the product screen sorts based on a SQL query, whose sorting may be lost on sequential loads of the product screen.

This change maintains the sort sequence to 'product.template' when loading the product screen when IndexedDB exists in the browser.

opw-4584724

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

Forward-Port-Of: odoo/odoo#201640

Before this commit, in Odoo, it was not possible to change an all-day event to a timed event and have it synchronized in Google correctly. This is because were sending to Google both 'date' and 'datetime' info for a single event (since Google stores the previous date and dateTime), which lead to "ERROR 400 Invalid start time." After this commit, the user can successfuly update a timed event to all-day event and vice versa and get it successfully updated in Google, since we now send 'date' as

Before this commit, in Odoo, it was not possible to change an all-day event to a timed event and have it synchronized in Google correctly. This is because were sending to Google both 'date' and 'datetime' info for a single event (since Google stores the previous date and dateTime), which lead to "ERROR 400 Invalid start time."

After this commit, the user can successfuly update a timed event to all-day event and vice versa and get it successfully updated in Google, since we now send 'date' as null when the event is timed and 'dateTime' as null when it is an all-day event.

task-3965107

Forward-Port-Of: odoo/odoo#205563
Forward-Port-Of: odoo/odoo#177549

Problem: When viewing the project update of a project that timesheets on a service product with standard valuation, the 'cost_of_goods_sold' section is displayed when it should not be. Purpose: The COGS section should only be displayed in the project updates if COGS lines exists in relation to the project. The behavior should stay consistent with v17.0 as with this commit: #203936 Steps to reproduce the issue: 1. Install Purchase, Sales, Project,sale_project, Inventory, Timesheets 2. Cre

Problem: When viewing the project update of a project that timesheets on a service product with standard valuation, the 'cost_of_goods_sold' section is displayed when it should not be.

Purpose: The COGS section should only be displayed in the project updates if COGS lines exists in relation to the project. The behavior should stay consistent with v17.0 as with this commit: #203936

Steps to reproduce the issue:
1. Install Purchase, Sales, Project,sale_project, Inventory, Timesheets
2. Create a service product with standard valuation and creates project & task on order
3. Create a sales order with the service product
4. Invoice the sales order and confirm
5. Create another invoice not linked to the sales order but contains project's analytic account
6. Load the project update or dashboard of the project and notice there's a COGS section displayed despite no related COGS invoice line

opw-4684445

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

Forward-Port-Of: odoo/odoo#208019

This fix solves a specific corner case where the analytic distribution could False by defaulting to an empty list. To reproduce the issue: - Enable analytic accounting. - Create an expense paid by the company with a linked SO. - Disable Analytic Accounting (also ensure the analytic distribution in the journal entry is False at this point) - Try to reset the Expense or its journal entry back to draft. This issue happens because the code assumes that the analytic distribution is always

This fix solves a specific corner case where the analytic distribution could False by defaulting to an empty list.

To reproduce the issue:

- Enable analytic accounting.
- Create an expense paid by the company with a linked SO.
- Disable Analytic Accounting (also ensure the analytic distribution in the journal entry is False at this point)
- Try to reset the Expense or its journal entry back to draft.

This issue happens because the code assumes that the analytic distribution is always a list, which might not since analytic accounting is disabled.

opw-4710518

Forward-Port-Of: odoo/odoo#207221

This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions. ### Steps to reproduce: 1. Install both `stock`, `delivery` and `mrp` 2. Create a product with a kit BOM and weight - Set the kit UoM to Unit and the components to Kg - Add a weight to the components too 3. Create SO with the kit product 4. Add shipping (UPS) 5. Delivery product 6. `The unit of measure Unit defined on the order line doesn't bel

This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions.

### Steps to reproduce:
1. Install both `stock`, `delivery` and `mrp`
2. Create a product with a kit BOM and weight
   - Set the kit UoM to Unit and the components to Kg
   - Add a weight to the components too
3. Create SO with the kit product
4. Add shipping (UPS)
5. Delivery product
6. `The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure Kg`

The sale price computed in `stock_delivery` does not take kits into account, which leads to conversion of UoM from different products (and therefore different UoM categories).
However, `sale_mrp` already computes the right value for kits.

It worked in earlier versions, thanks to the module loading order, but `_compute_sale_price` moved from the module `delivery` to `stock_delivery`.

Here is the (simplified) module dependency graph:
```
Odoo 16.0:
sale
`-> sale_management
   `-> delivery
`-> sale_stock
   `-> sale_mrp

Odoo 17.0:
sale
`-> delivery
   `-> stock_delivery
`-> sale_stock
  `-> sale_mrp
```

Odoo sorts modules by depth in the graph, and ordered alphabetically for modules with the same depth.
So in Odoo 16.0, `delivery` was loaded before `sale_mrp`, but starting Odoo 17.0, `stock_delivery` is loaded after `sale_mrp` since they both have the same depth.

opw-4385052

Forward-Port-Of: odoo/odoo#206753
Forward-Port-Of: odoo/odoo#190750

Before this commit, the test "Message shows up even if channel data is incomplete" would sometimes fail. This happened because it waited for a bus subscription triggered by a call to the `_forceUpdateChannel` method of the bus service. However, this method is debounced, and as a result, the subscription sometimes occurred too late, causing the test to fail. This commit resolves the issue by using `runAllTimers`, which immediately executes the debounced method. fixes runbot-76011 Forward-P

Before this commit, the test "Message shows up even if channel data is incomplete" would sometimes fail. This happened because it waited for a bus subscription triggered by a call to the `_forceUpdateChannel` method of the bus service. However, this method is debounced, and as a result, the subscription sometimes occurred too late, causing the test to fail.

This commit resolves the issue by using `runAllTimers`, which immediately executes the debounced method.

fixes runbot-76011

Forward-Port-Of: odoo/odoo#208015
Forward-Port-Of: odoo/odoo#207914

<b>Steps to reproduce:</b> 1. Setting > Navigate to Configure Document layout > layout : DIN 5008. 2. Accounting > invoice > PDF without Payment. Note :Ensure the address has at least 33 characters without spaces to trigger the issue. <b>Issue:</b> The footer of the invoice is not displaying correctly — the company name in the bottom left corner is overlapping and not aligned properly. <b>Cause:</b> An upstream PR modified the footer text sizing, leading to layout issues

<b>Steps to reproduce:</b>

1. Setting > Navigate to Configure Document layout > layout : DIN 5008.
2. Accounting > invoice > PDF without Payment.

Note :Ensure the address has at least 33 characters without spaces to trigger the issue.

<b>Issue:</b>
   The footer of the invoice is not displaying correctly — the company name in the
   bottom left corner is overlapping and not aligned properly.

<b>Cause:</b>
   An upstream PR modified the footer text sizing, leading to layout issues when
   fields contain long values.

<b>Solution:</b>
Removed the `text-nowrap` class from the company details in the footer section.
Improved section alignment using `colspan` and made minor adjustments to footer text sizing.
These changes prevent content overlap in the company information section of reports,
ensuring proper display regardless of content length.

<b>opw: 4731515</b>

Before changes applied:
![image](https://github.com/user-attachments/assets/cf00bda8-ffde-4ea4-b5ca-59a47df152bd)
After changes applied:
![image](https://github.com/user-attachments/assets/354bf1ba-43b1-4a1e-aa66-142c3c44b38d)

Forward-Port-Of: odoo/odoo#206774