Daily updates from Odoo
Friday, November 21, 2025
221 changes
3 changes
Enhancements to existing features
The IoT Box homepage now waits longer between data refreshes when a tab stays open. This reduces unnecessary background requests, helping the device stay responsive while still updating the page periodically.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min. Forward-Port-Of: odoo/odoo#236664
Resolved issues and error corrections
This fix makes planning analysis reports count time only when a shift actually falls within working hours. It prevents hours from being incorrectly assigned to the wrong month when a shift crosses midnight outside an employee’s schedule.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This fix makes the vendor on-time rate shown in the smart button match the graph and the actual purchase order quantities. It prevents duplicated receipts from inflating totals and gives users a reliable delivery performance view.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#236779 Forward-Port-Of: odoo/odoo#225529
6 changes
Enhancements to existing features
The system now waits longer between homepage data updates when a browser tab stays open, instead of checking too frequently at first. This reduces unnecessary requests to the IoT Box and helps keep it more responsive over time.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min. Forward-Port-Of: odoo/odoo#236664
Resolved issues and error corrections
Planning and timesheet analysis reports now correctly respect employees’ working hours when calculating planned time. This prevents shifts that cross into a new month outside working hours from being counted in the wrong month, improving report accuracy.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
The vendor on-time rate now uses the original purchase order quantity instead of a recalculated stock move quantity. This fixes a mismatch between the smart button and the graph, so vendor performance figures are accurate and consistent.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#236779 Forward-Port-Of: odoo/odoo#225529
This update corrects how the mail module simulates browser platforms in its tests. It ensures the test setup uses the expected platform value, which helps keep automated checks accurate and reliable.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/odoo#236837This change allows users to create reordering rules for a product in one company even if that product has a kit bill of materials in another company. It prevents an incorrect validation error and makes multi-company behavior more consistent.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
This update restores the missing date filtering on certain Balance Sheet lines in the Syscohada reports. It helps ensure the report shows figures for the selected period consistently, reducing the risk of confusing or incomplete financial output.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
2 changes
Resolved issues and error corrections
This update corrects how planning hours are counted in Timesheets/Planning analysis reports. Shifts that end outside normal working hours, especially when they cross into a new month, will no longer be incorrectly included in the next month’s planned hours.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This update corrects the Balance Sheet report so its linked lines use the proper date scope rules. As a result, report totals and drill-downs are more accurate and consistent when users view financial data over specific periods.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
5 changes
Resolved issues and error corrections
When an e-invoice request is rejected by ETA, Odoo now handles the response more gracefully instead of showing a traceback. This improves the user experience by turning a technical failure into proper error handling.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update removes duplicate method definitions found in several areas of the codebase. It helps keep the system easier to maintain and reduces the risk of inconsistent behavior in payroll and expense-related features.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
This update makes record access checks use the same rules everywhere, regardless of a specific context setting. It prevents inconsistent access behavior and helps ensure users see and can act on records as expected.
Original PR description
Since https://github.com/odoo/odoo/pull/219703, we ir.rule domain doesn't depend on active_test context key. But `_check_access` is still depending on active_test which is not consistent. Fix it.
Odoo now uses the current official code for Odisha, changing it from the outdated "OR" to "OD". This helps ensure contacts and sales documents use the correct state information for India.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
This update keeps Odoo’s code quality checks compatible with newer pylint/astroid versions and removes a few outdated compatibility paths. It also fixes a couple of test-related false alarms so the validation tools run more reliably across supported environments.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives. Forward-Port-Of: odoo/odoo#236530 Forward-Port-Of: odoo/odoo#236258
4 changes
Enhancements to existing features
The system now waits longer between homepage data refreshes when a browser tab stays open for a long time. This reduces unnecessary traffic to the IoT Box while still keeping the homepage information up to date.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min. Forward-Port-Of: odoo/odoo#236664
Resolved issues and error corrections
The planning analysis report now correctly checks whether a shift falls within working hours before counting it in a given month. This prevents hours from being wrongly assigned to the next month when a shift ends outside normal working time.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This fix restores the ability to edit timesheet entries that are linked to an invoice after that invoice has been reversed. It helps teams correct recorded hours even when the original billing document has been canceled and replaced by a credit note.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#234108 Forward-Port-Of: odoo/odoo#201921
This change fixes how Mail’s automated tests simulate browser environments. It ensures the test tool is used with the intended device/platform values, which helps keep test behavior accurate and reliable.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.1 change
Enhancements to existing features
This update ensures Odoo includes the expected application information in payment requests sent to Adyen. It helps Adyen correctly identify the external platform, improving reliability of payment processing and reducing the risk of request issues.
Original PR description
Add applicationInfo to the payload sent to Adyen, ensuring that externalPlatform is correctly transmitted. A test was added to verify that applicationInfo is present in the payload and that the payment request succeeds as expected. task-5157863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr