Daily updates from Odoo
Navigate
Branch
Sunday, July 13, 2025
9 changes
5 changes
Enhancements to existing features
This update adjusts internal testing rules so localization modules do not repeatedly fail a view-field check that is not run in their normal test flow. It helps keep automated validation cleaner and reduces unnecessary maintenance work without changing user-facing behavior.
Original PR description
Most l10n modules are only installed during the standalone l10n job, which does not run `test_uncommented_invisible_field`. As a result they fail the test in every version where it was introduced. - sort the whitelisted modules - add the l10n that currently fail, as we don't want to fix them - revert change adding a bunch of comments in views
Resolved issues and error corrections
This fixes an issue where newly created, automatically validated attendance records could show zero extra hours even when an employee worked longer than expected. The correction ensures overtime is calculated immediately when the record is saved, giving HR and payroll users accurate attendance information from the start.
Original PR description
Introduced by cc81bb59f87540cf4dd8da65510417d8023ef65b **Steps to reproduce** 1. Create a new automatically validated attendance. 2. Set the employee, check in and check fields before saving the form. Issue: the "Extra hours" field is not computed. e.g.: if the employee has worked 1 hour more than expected, "Worked Extra Hours" equals 1:00 (ok), but "Extra hours" appears as 0:00. **Cause** The previous fix intended to avoid recomputation of the `validated_overtime_hours` field. No better way was found than to exclude records where the `overtime_hours` was different than the `validated_overtime_hours` (meaning it had been manually modified by the user). The problem comes from the fact that at creation, `validated_overtime_hours` was sent in the `vals_list` to the create with a value of 0. **Solution** Force the computation of the field at creation. Forward-Port-Of: odoo/odoo#217967
Marketing cards now display date and time fields using the timezone that is relevant to the underlying record, such as an event's local timezone, instead of defaulting to UTC. This makes shared cards clearer and prevents recipients from seeing misleading event or schedule times.
Original PR description
When possible we want to fetch a date field in its relevant timezone not in UTC. As that is generally what you want people to share. task-4936298 Forward-Port-Of: odoo/odoo#218721 Forward-Port-Of: odoo/odoo#218633
Creating an invoice from a sales order could fail if a related auto-created project had been deleted first. The fix safely ignores missing linked distribution accounts, allowing invoicing to continue instead of showing a deletion error.
Original PR description
When creating an invoice from a sales order linked to a service-type product that auto-generates a project, deleting the project before invoicing caused an error: "Record does not exist or has been deleted." This fix filters `browse()` result using `exists()` to ensure that the linked distribution account still exists. Steps to reproduce: - Create a service product that creates a project on order - Add it to a sales order and confirm - Delete the project - Try to create an invoice → error occurs opw-4891937 Forward-Port-Of: odoo/odoo#217870
This change makes stock quantity report tests use a fixed time so they no longer fail around midnight. It improves the reliability of automated checks without changing customer-facing stock features.
Original PR description
The tests: - `test_report_stock_quantity` - `test_report_stock_quantity_with_product_qty_filter` can fail if the test class was instantiate at midnight and the tests launched at 00:01. The issue has…
The tests: - `test_report_stock_quantity` - `test_report_stock_quantity_with_product_qty_filter` can fail if the test class was instantiate at midnight and the tests launched at 00:01. The issue has been explained extensively in d1e11dc2b41e66709ddd89beded32872af4118b9 Here is a modest retranscription of its holy analysis: The Test class `TestReportStockQuantity` inherit from `TransactionCase`. So, once initialized, a SQL transaction is started and is the same for all the tests of the class: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/odoo/tests/common.py#L775-L778 Also, in a SQL request, the method `now()` does not really return the current date: > Notice that NOW() and its related functions return the start time of the current transaction. In other words, the return values of the function calls are the same within a transaction. (https://www.postgresqltutorial.com/postgresql-date-functions/postgresql-now/) So, if we we start all the tests of the class `TestReportStockQuantity` at the end of D01. The SQL transaction is created and the tests are executed one by one with a NOW() corresponding to D01. However, certain indiviual tests might be launched on the following day D02 because it takes time to run the rest of the tests of the class: In particular, the python "today()" will notgive the same date as the SQL NOW and the queries of the test will simply not perform the expected. E.g: https://github.com/odoo/odoo/blob/d86409d93e096126b32cbb35f442db332628375d/addons/stock/tests/test_report_stock_quantity.py#L105-L110 runbot-226726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216984 Forward-Port-Of: odoo/odoo#215424
1 change
Resolved issues and error corrections
This change reverses a previous broad update that was creating repeated conflicts during forward ports without preventing future errors. The project will instead handle the issue through targeted test whitelisting, reducing maintenance friction with minimal business impact.
Original PR description
Change is noisy, conflicts on every forward port, and doesn't preclude adding more errors. Whitelist on the test side instead.
3 changes
Enhancements to existing features
Several country-specific localization modules are now excluded from a technical validation that was not being run for them consistently. This prevents repeated automated test failures without changing how users work with these localizations.
Original PR description
Most l10n modules are only installed during the standalone l10n job, which does not run `test_uncommented_invisible_field`. As a result they fail the test in every version where it was introduced. - sort the whitelisted modules - add the l10n that currently fail, as we don't want to fix them - revert change adding a bunch of comments in views
Resolved issues and error corrections
The Post button on accounting entries will now be hidden when posting is not allowed, such as for already posted or auto-scheduled entries. This removes a confusing option from the screen and better aligns the interface with the system's actual rules.
Original PR description
[FIX] account: ensure `hide_post_button` is declared in form view The `hide_post_button` field is used in the `invisible` condition of the "Post" (`action_post`) button on `account.move` form views. However, it was not explicitly declared in the view, which caused the button to be always visible even when it should be hidden. This commit adds the missing field to the form view (invisible), so the `invisible` condition is properly evaluated by the client UI. This fixes a UI inconsistency where the Post button appears for posted or auto-scheduled entries, despite backend logic preventing their posting. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Code cleanup and technical improvements
This pull request reverts a previous broad change that was creating repeated maintenance conflicts during version updates. The intended checks will instead be handled in tests, reducing disruption while keeping room for future improvements.
Original PR description
Change is noisy, conflicts on every forward port, and doesn't preclude adding more errors. Whitelist on the test side instead.