Friday, May 2, 2025
20 changes · 18.0
Resolved issues and error corrections
This fix prevents errors when resetting certain company-paid expenses or related journal entries after analytic accounting has been turned off. It ensures Odoo handles missing analytic distribution data safely, improving reliability for sales-project expense workflows.
Original PR description
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
Timesheet users can now select the appropriate sales order item even when it uses manual delivered-quantity invoicing. This removes an inconsistency where an automatically filled item could disappear from search lists after being changed manually.
Original PR description
**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
Project updates will no longer show the cost of goods sold section unless there are actual COGS lines tied to the project. This prevents misleading financial information from appearing on project dashboards and keeps behavior consistent with prior versions.
Original PR description
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…
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
After a delivery order is signed, the Sign button is now hidden so users cannot sign the same document again. This makes the delivery status clearer and prevents duplicate signatures on completed delivery documents.
Original PR description
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imply that the transaction is not finalized. **Fix:** Hide 'Sign' button after signature validation using the `is_signed` field value. This prevents users from signing multiple time the same delivery document. opw-4700124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops users from saving a timesheet line when its project has been removed. It helps keep timesheet records accurate and avoids entries that appear incomplete or inconsistent.
Original PR description
Currently it's possible for a timesheet user to set and write the project to False in the timesheet list view. The UI will say the project is missing but the analytic line is changed anyway. This PR add check that the project is set before writing to the analytic line record. opw-4649817
Belgian Intrastat XML exports no longer fail when an invoice includes a line without a product. The export now excludes those productless lines, matching what users already see in the report and allowing compliant files to be generated reliably.
Original PR description
How to reproduce: - Select a Belgian company - Create an invoice for a EU country - Add a line with no product - Display the intrastat report for the invoice period - Export the xml The default sql query allows the selection of account move lines with no product to be able to trigger a warning. Those lines are then filtered out when displayed in the web interface. Those lines were not filtered out when getting data for file exports. An error would trigger rendering the xml as the weight would be None where an integer is required. This commit adds a condition to only select move lines with a product_id when querying data for a file. Task 4763185 See opw-4671512, opw-4735439, opw-4642781
After a delivery order is signed in the Barcode app, the Sign button is now hidden. This prevents duplicate signatures and makes it clearer that the delivery document has already been finalized.
Original PR description
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order in the Barcode app. - Go to the settings in the top-right corner to find the 'Sign' button. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imply that the transaction is not finalized. **Fix:** Hide 'Sign' button after signature validation using the `record.signature` field value. This prevents users from signing multiple time the same delivery document. opw-4700124
This fixes an unnecessary error that could prevent HR document share links from being sent when a company workspace setting was not configured. The sharing process no longer depends on that setting, so users can continue sending document links without extra setup.
Original PR description
This reverts FW #82587. The functionality of `action_send_documents_share_link` was changed as of #65655 in 18+, which no longer requires the`company.documents_hr_folder` setting. opw-4559772
Payroll payment reports now use the company linked to the payslip batch instead of the company currently selected by the user. This prevents incorrect company details from appearing when working with multiple companies.
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306
Miscellaneous changes
When settling an order from the POS, the amount to invoice was not correctly computed. Steps to reproduce: ------------------- * Create a draft sale order with a product * Go to the POS and select the order * Pay for the order * Go to the backend and check the amount to invoice > Observation: The amount to invoice is still the full order amount Why the fix: ------------ We should take into account the PoS payment lines when computing the amount to invoice of an order. opw-460367
Original PR description
When settling an order from the POS, the amount to invoice was not correctly computed. Steps to reproduce: ------------------- * Create a draft sale order with a product * Go to the POS and select the order * Pay for the order * Go to the backend and check the amount to invoice > Observation: The amount to invoice is still the full order amount Why the fix: ------------ We should take into account the PoS payment lines when computing the amount to invoice of an order. opw-4603671 Forward-Port-Of: odoo/odoo#207710 Forward-Port-Of: odoo/odoo#202950
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
Original PR description
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
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
Original PR description
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#203434 Forward-Port-Of: odoo/odoo#177549
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 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#206976 Forward-Port-Of: odoo/odoo#204980
Original PR description
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 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#206976 Forward-Port-Of: odoo/odoo#204980
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
Original PR description
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
Original PR description
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
Original PR description
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
<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
Original PR description
<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…
<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:  After changes applied:  Forward-Port-Of: odoo/odoo#206774
We never took the 'cumulated_start' option of an Odoo chart into account and instead relied on 'cumulative' but the options are not linked neither one implied by the other. Task-4701303 Forward-Port-Of: odoo/enterprise#83901 Forward-Port-Of: odoo/enterprise#82954
Original PR description
We never took the 'cumulated_start' option of an Odoo chart into account and instead relied on 'cumulative' but the options are not linked neither one implied by the other. Task-4701303 Forward-Port-Of: odoo/enterprise#83901 Forward-Port-Of: odoo/enterprise#82954
ISSUE: when trying to archive employees who are connected to planning slots an exception is raised REPRODUCE: - Select all employees - try to Archive - the `strptime` method needs the argument to be string but the values dict has the dates values as datetime objects. so, convert the values using `str` Task: 4734621 Forward-Port-Of: odoo/enterprise#83575
Original PR description
ISSUE: when trying to archive employees who are connected to planning slots an exception is raised REPRODUCE: - Select all employees - try to Archive - the `strptime` method needs the argument to be string but the values dict has the dates values as datetime objects. so, convert the values using `str` Task: 4734621 Forward-Port-Of: odoo/enterprise#83575
* quality_mrp, stock_barcode ### Steps to reproduce: - Create a product FP with a bom: - 1 x comp - Create a control check point per product for FP for the manufacturing operation type - Go to the barcode app - Scan the manufacturing operation type - Scan FP and set the qty_producing - Click quality check #### > Traceback ### Cause of the issue: By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As
Original PR description
* quality_mrp, stock_barcode ### Steps to reproduce: - Create a product FP with a bom: - 1 x comp - Create a control check point per product for FP for the manufacturing operation type - Go to the…
* quality_mrp, stock_barcode
### Steps to reproduce:
- Create a product FP with a bom:
- 1 x comp
- Create a control check point per product for FP for the manufacturing operation type
- Go to the barcode app
- Scan the manufacturing operation type
- Scan FP and set the qty_producing
- Click quality check
#### > Traceback
### Cause of the issue:
By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As such, the `resId` the barcode `MainComponent` is `false`. However, this "id" is used in the orm call of the `checkQuality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L15-L19 As such, we launch a call of the `check_quality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/quality_mrp/models/mrp_production.py#L70-L72 that ends up raising an traceback since the `product_uom` is `False` on the "unexpected" record `mrp.production(False,)`.
### Fix:
Since we just saved the record and hence created the record prior to this call:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L12-L15 we should rather rely on the new created id.
opw-4644128
Forward-Port-Of: odoo/enterprise#83437
Forward-Port-Of: odoo/enterprise#82688