Tuesday, June 24, 2025
13 changes · 17.0
Enhancements to existing features
Project setup data is now protected from being overwritten when the module is upgraded. This helps preserve customer-specific adjustments and reduces the risk of losing configuration changes during maintenance updates.
Original PR description
Updated XML files to include the noupdate attribute for the data in project_data.xml. This change ensures that the records are not updated during module upgrades, preserving customizations. 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
This update adjusts the Point of Sale device configuration so it loads the correct combined driver module after recent internal module changes. It helps ensure checkout hardware continues to start with the expected services after updates.
Original PR description
To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load. Task: 4860513
Resolved issues and error corrections
UAE invoice PDFs now align the VAT column headers with the VAT amounts. This corrects a visual mismatch and makes printed invoices look cleaner and more consistent for customers.
Original PR description
**Step to reproduce:** 1. Install l10n_ae module. 2. Create and post a customer invoice with product and Taxes. 3. Print the invoice using the Invoice PDF report. **Issue:** The "VAT" columns in the…
**Step to reproduce:** 1. Install l10n_ae module. 2. Create and post a customer invoice with product and Taxes. 3. Print the invoice using the Invoice PDF report. **Issue:** The "VAT" columns in the invoice report for AE localization are left-aligned, which causes a visual misalignment. **Cause:** The header cells for the "VAT" columns use the text-start class, which left-aligns them, whereas the VAT data is right-aligned.It arises because the `<th name="th_taxes">` element is aligned with text-end in the base view account.report_invoice_document , but it is overridden for the l10n_ae module with text-start. https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account/views/report_invoice.xml#L116 **Solution:** To fix this, update the alignment of the "VAT" header columns to use text-end, ensuring consistent alignment. opw-4863313 Before fix:  After fix: 
Miscellaneous changes
Steps: - Open any views with a search bar - Press ALT + Q (hotkey used to focus search input) - Nothing happens This behavior has been introduced by https://github.com/odoo/odoo/pull/185960 This commit just adds the focus that had previously been removed to enable the input to be correctly selected so that the user can write directly on it. opw-4874194 Forward-Port-Of: odoo/odoo#215127
Original PR description
Steps: - Open any views with a search bar - Press ALT + Q (hotkey used to focus search input) - Nothing happens This behavior has been introduced by https://github.com/odoo/odoo/pull/185960 This commit just adds the focus that had previously been removed to enable the input to be correctly selected so that the user can write directly on it. opw-4874194 Forward-Port-Of: odoo/odoo#215127
This update makes stock quantity report tests use a fixed time so they do not fail around midnight. It improves reliability of automated checks without changing customer-facing stock features or workflows.
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
Creating a task stage from the Project app now keeps the Project field visible in the form. This prevents confusion and helps users correctly assign new stages to the right project.
Original PR description
<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b>…
<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b> The Project field is not visible when creating a new task stage in the form view. <b>Cause:</b> The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L46-L48 However, the action context includes `default_project_id=False`, which causes the defaulting logic to compute a `default_user_id` (based on the falsy project). As a result, `user_id` is set, hiding the project_id field from the form. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L143 https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/models/project_task_type.py#L19-L20 <b>Fix:</b> Add a key in the context to make the user_id as False when creating a new task stage from the Form view. opw-4767251
Users who can view all timesheets but do not have employee record access will now still see employee avatars in the timesheet Kanban view. This fixes a display issue by using the correct publicly accessible employee image source when needed.
Original PR description
Steps to Reproduce:
------------
- Log in with a user who has access to all timesheets but does not have access to the employee records.
- Open the Timesheet module.
- Navigate to Timesheet → All Timesheets.
- Open Kanban View
Issue:
---------
Avatars are not displayed in each line of the timesheet.
Reason:
-----------
- Currently, we are passing the hr.employee model to the kanban_image QWeb helper to generate the image source URL for all users.
- If the user doesn’t have access to employee, avatar can’t be loaded.
Fix:
-------
We pass the appropriate model ('hr.employee' or 'hr.employee.public') to the kanban_image helper to generate the image URL. This is controlled by the groups attribute in the view — if the user is in hr.group_hr_user, we use 'hr.employee' otherwise, we use 'hr.employee.public'.
task: 4461272This change fixes an automated payroll accounting test so it works consistently across different test environments. It helps prevent false build failures when only the Belgian payroll accounting test module is installed, improving confidence in release checks.
Original PR description
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account).
With this commit this test works as expected in both of them. (and with/)
Caused by:
```py
reference_year = fields.Selection(
selection='_get_years', string='Reference Year', required=True,
default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 else fields.Date.today().year))
....
def _get_years(self):
today = fields.Date.today()
current_reference_year = today.year + 1 if today.month > 5 else today.year
return [(str(i), i) for i in range(current_reference_year, current_reference_year - 5, -1)]
```
A solution was to use freezetime
runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/226389Helpdesk tickets created directly in a closed stage are now marked as closed immediately. This keeps portal ticket filters accurate, so customers do not see solved or closed tickets under their open tickets list.
Original PR description
**Steps to reproduce:** 1. Install the Helpdesk module. 2. Create a ticket directly in a closed stage (e.g., 'Solved') and add the portal user as a customer. 3. Log in as the portal user. 4. Apply the Open filter. **Issue:** - The ticket appears under Open Tickets, even though it was created in a closed stage. **Cause:** - Currently we consider a stage as closed if 'floded in kanban' is True and When a ticket is created directly in a closed stage, the close_date field is not set. Since the portal filter relies on close_date to distinguish open from closed tickets, this shows closed tickets in open filter. https://github.com/odoo/enterprise/blob/c34256932e593ac2774fa65af813d64edb70ec43/helpdesk/controllers/portal.py#L63 **Solution:** - During ticket creation, if the specified stage is a closing stage, set the close_date field to the current time. opw-4847097
This fix makes manufacturing shop floor automated tests ignore unrelated demo records when checking results. It helps keep build validation stable and prevents false failures that could slow down delivery.
Original PR description
### Issue: Certain shopfloor tests make assert on the number of records present in the shopfloor: - test_shop_floor_my_wo_filter_with_pin_user - test_automatic_backorder_no_redirect These assert can not be reliable due to demo-data's adding unrelated records e.g. https://github.com/odoo/enterprise/blob/5bfadae317ee47ac34703d4cc222677ac677cc7d/purchase_mrp_workorder_quality/data/purchase_mrp_workorder_quality_demo.xml#L79-L84 runbot-build-error-226734
Fixes an issue where some Belgian accounting report lines could hide amounts when totals below sections and unfold all were both enabled. This ensures users see the expected figures in affected financial reports, improving report reliability.
Original PR description
Some BE report lines (ex "Other Appropriations of the Year" in BE balance sheet) does not show amounts if setting "Add totals below sections" is enable and "Unfold all" option is selected on the report. This PR aims to hide amount only if the report line is foldable. opw-4640606
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Original PR description
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/e
Original PR description
Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/enterprise#88110