Issue: = - Updating presets on multiple POS setups at once caused a singleton error. Fix: = - Now processes each POS configuration individually to prevent the error. Related PR: https://github.com/odoo/odoo/pull/196800 Task: 4523232 Forward-Port-Of: odoo/odoo#208223

Issue:
=
- Updating presets on multiple POS setups at once caused a singleton error.

Fix:
=
- Now processes each POS configuration individually to prevent the error.

Related PR: https://github.com/odoo/odoo/pull/196800
Task: 4523232

Forward-Port-Of: odoo/odoo#208223

**Steps to reproduce:** - Create a service with "Create on Order" = `Project & Task` and "Invoicing Policy" = `Based on Delivered Quantity (Manual)`. - Create a quotation using this service as a product. - Create a new line in Timesheet with the Project of the service. - The Sales Order Item field updates automatically. - If manually modified, the item no longer appears in the lists of `name_search` or `web_search_read`. **Issue:** Inconsistent behavior on the domain used for the Sale O

**Steps to reproduce:**
- Create a service with "Create on Order" = `Project & Task` and "Invoicing Policy" = `Based on Delivered Quantity (Manual)`.
- Create a quotation using this service as a product.
- Create a new line in Timesheet with the Project of the service.
- The Sales Order Item field updates automatically.
- If manually modified, the item no longer appears in the lists of `name_search` or `web_search_read`.

**Issue:**
Inconsistent behavior on the domain used for the Sale Order Item showed in the Timesheet app.

**Fix:**
Removed `qty_delivered_method` domain filtering to allow sale order line with any `qty_delivered_method` to
be used in the Timesheet app.

opw-4710840

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

Forward-Port-Of: odoo/odoo#207681

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

In this commit, we prefer to use click on element instead of press Tab because tab will directly focus the other range period input. Forward-Port-Of: odoo/enterprise#83395 Forward-Port-Of: odoo/enterprise#82937

In this commit, we prefer to use click on element instead of press Tab
because tab will directly focus the other range period input.

Forward-Port-Of: odoo/enterprise#83395
Forward-Port-Of: odoo/enterprise#82937

The compute method was removed in this commit, but is declared in the field. commit : https://github.com/odoo/enterprise/commit/70d96c44bb834ecbe89b5720ae18a93038301796#diff-2f3d348951d6293f7e805819d7053ac4ec65994bbacc829dac5dc68b00c932c> Traceback: --- `AttributeError: 'product.product' object has no attribute '_compute_pricer_display_price'` This commit removes the compute declaration from the field. sentry-6547636163 Forward-Port-Of: odoo/enterprise#83599

The compute method was removed in this commit, but is declared in the field.
commit : https://github.com/odoo/enterprise/commit/70d96c44bb834ecbe89b5720ae18a93038301796#diff-2f3d348951d6293f7e805819d7053ac4ec65994bbacc829dac5dc68b00c932c>

Traceback:
---
`AttributeError: 'product.product' object has no attribute '_compute_pricer_display_price'`

This commit removes the compute declaration from the field.



sentry-6547636163

Forward-Port-Of: odoo/enterprise#83599

Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed. Steps to reproduce: - Install account_3way_match - Create and partially pay an invoice - Go to the dashboard - The displayed amount should reflect the residual, but it shows the full amount This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute

Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed.

Steps to reproduce:
- Install account_3way_match
- Create and partially pay an invoice
- Go to the dashboard
- The displayed amount should reflect the residual, but it shows the full amount

This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute `amount_total` and `amount_total_company`.

opw-4731478

Forward-Port-Of: odoo/enterprise#83823

Forward-Port-Of: odoo/enterprise#84045 Forward-Port-Of: odoo/enterprise#84014

Forward-Port-Of: odoo/enterprise#84045
Forward-Port-Of: odoo/enterprise#84014

The aim of this commit is slightly changing the chatter's behavior in the bank reconciliation widget. Before this commit, the user activated/deactivated the chatter by clicking on a chatter icon available on each statement line. Although this feature is still existing to activate the chatter, we add a new button on the top corner right where the user can activate / deactivate the chatter. We also change the selected move id when you select another statement line, it's not necessary to click on

The aim of this commit is slightly changing the chatter's behavior in the bank reconciliation widget.
Before this commit, the user activated/deactivated the chatter by clicking on a chatter icon available on each statement line. Although this feature is still existing to activate the chatter, we add a new button on the top corner right where the user can activate / deactivate the chatter. We also change the selected move id when you select another statement line, it's not necessary to click on the chatter icon to do it. This commit also introduces a cleaner way of working with several components to activate / deactivate the chatter by using a customer service.

task-4750009

[FIX] account_accountant: Remove bus usage and use own service

The aim of this commit is removing 2 usages of the event bus where we need to do synchronous calls.
This commit will use the brand-new service developed for the bank reconciliation widget.

no task id

Forward-Port-Of: odoo/enterprise#84283

This pull request adds contributor license agreement records for individual contributors and includes a small compatibility fix for internal lint testing. It helps keep contribution records complete while maintaining automated checks on supported Python versions.

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

**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the Vendor Bill. Adding the product straight from the vendor bill worked fine. **Steps to reproduce:** - Make a product with a landed cost. - Make a new vendor bill and go to the catalog from the Invoice Lines tab. - Search for your product and add it to the Vendor Bill. - Return to the Vendo

**Problem:**
When adding a product that has the landed cost setting activated
to a Vendor Bill, the landed cost checkbox was not checked, thus
the product was not registered with a landed cost in the Vendor
Bill. Adding the product straight from the vendor bill worked fine.

**Steps to reproduce:**
- Make a product with a landed cost.
- Make a new vendor bill and go to the catalog from the Invoice Lines tab.
- Search for your product and add it to the Vendor Bill.
- Return to the Vendor Bill and see that the landed cost is not checked.

**Cause of the issue:**
The field is_landed_costs_line is set in an onchange function,
thus when adding a product from the catalog the said function
is not triggered and the is_landed_costs_line is not applied.
https://github.com/odoo/odoo/blob/01058b94d860ab508bc2c013af5fe887e08247d9/addons/stock_landed_costs/models/account_move.py#L61-L66

**Fix:**
An override of the create function was added to add the
correct landed cost even when the onchange function is
not called. With the onchange function and the create
function, this ensures that the is_landed_costs_line
will be set correctly regardless of where it is created
from.

opw-4521391

Forward-Port-Of: odoo/odoo#201622

We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal. Steps to reproduce: 1. Have two purchase journal A and B on the same company 2. Set an expense account that is allowed on one of those journa

We predict the account to use in an invoice/purchase entries based on product configuration and frequent account used for partner but we do not verify if those accounts are allowed on the specified journal. This can be problematic if the entry is generated from a external file (ex: using Peppol), Odoo should retrieve an account allowed in the journal.

Steps to reproduce:
1. Have two purchase journal A and B on the same company
2. Set an expense account that is allowed on one of those journal (A) and not the other (B)
3. Create multiple bills with this account on the journal A for partner X
4. Upload a XML bill of partner X in journal B -> The expense account is used based on the bills in journal A -> Error because journal B is not allowed for this account

opw-4607733

Forward-Port-Of: odoo/odoo#206104
Forward-Port-Of: odoo/odoo#203664

…dd it in the tax details 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#207100 Forward-Port-Of: odoo/odoo#206052

…dd it in the tax details

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#207100
Forward-Port-Of: odoo/odoo#206052

**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will

**Problem:**
The problem happens when  a service is linked to a task but it's not billed on timesheet.

If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation.

If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. 

Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation.

**Steps to reproduce:**
- In settings, activate the "margins" setting in Sales
- Open Sales/products and create a new product
- Set the product type as "Service"
- Set the "create on order" field as Task
- Set the "project" field to an existing project
- Set a strictly positive value in the cost field
- Set a name and save
- Create a new quotation and add the product you just created
- Confirm the quotation
- In the order lines page, add the cost column
- Change the value of the cost column
- Click on the "Tasks" smart button
- Add a new timesheet in the timesheet page and save
- Come back to the sale order via the smart button

**Current behavior:**
The value of the cost column was reset the the cost of the product

**Expected behavior:**
Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets

**Cause of the issue:**
Because the sale_timesheet_margin module is installed the
_compute_purchase_price method is overriden and depends on
analytic_line_ids.amount
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8
when this method is called in our flow, because
sol.product_id.purchase_price is not null our sale order line
will not get filtered out
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11
and it will reach the original
_compute_purchase_price method were the value of purchase_price
will be reset to the value of self.product_id.standard_price
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30


**Fix:**
We want to filter out the sale.order.lines for which the computation
of purchase_price has been triggered via the analytic_line_ids.amount
dependency and for which we don't want the computation to happen
(when the service_policy is not "timesheet").
We need to do this without filtering out the sales.order.lines for which the
computation of purchase_price has been triggered by a dependency from
the original compute_purchase_price method
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21
or another orverride of this method
(for now there are two of those : one in sale_expense_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11
and one in sale_stock_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11
)

is_expense is defined in the sale module
is_service is defined in the sale_service module
service_policy is defined in the sale_project module
all those field are available when sale_timesheet_margin is installed



opw-4627037

Forward-Port-Of: odoo/odoo#205415

Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207640

Description of the issue/feature this PR addresses:
Wrong address/zip/city in Swiss QR bill template.

Current behavior before PR:
The template for Swiss QR bills uses the company address, zip code and city.

Desired behavior after PR is merged:
The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available.

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

Forward-Port-Of: odoo/odoo#207640

The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84410

The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout.

This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client.

Task: 4760366

Forward-Port-Of: odoo/enterprise#84410

Version: - saas-17.4 Steps to reproduce: - Create request signature activity for sign request. - Try to send document for sign from activity. Issue: - It will give a traceback to user. Cause: - It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model. Solution: - Since reference_doc is not supported for 'sign.request', this fix adds a condition to explici

Version:
- saas-17.4

Steps to reproduce:
- Create request signature activity for sign request.
- Try to send document for sign from activity.

Issue:
- It will give a traceback to user.

Cause:
- It will try to create a record for 'sign.request' model and in reference_doc field it was showing wrong value as we are not allowing to create reference_doc for 'sign.request' model.

Solution:
- Since reference_doc is not supported for 'sign.request', this fix adds a condition to explicitly skip setting it for that model

task-4416253

Forward-Port-Of: odoo/enterprise#75611

Forward-Port-Of: odoo/enterprise#84045 Forward-Port-Of: odoo/enterprise#84014

Forward-Port-Of: odoo/enterprise#84045
Forward-Port-Of: odoo/enterprise#84014

Before This **PR**: If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error: {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue. After This **PR**: A new function has been introduced to check whether another compa

Before This **PR**:
If a company attempted to generate a GST token using a GST number already assigned to another company with a valid token, the system returned an ambiguous error:  {'message': 'API access is not available or user expiry duration is less than or equal to auth token expiry duration', 'error_cd': 'AUTH4037'}. This caused confusion for users, as the message did not clearly indicate the issue.

After This **PR**:
A new function has been introduced to check whether another company has the same GST number and a valid token before sending the request. If such a case is detected, the system now displays a warning, recommending the use of a Tax Unit.

**task**-4636041

Forward-Port-Of: odoo/enterprise#84528
Forward-Port-Of: odoo/enterprise#81218