Tuesday, December 17, 2024
22 changes · 17.0
Enhancements to existing features
Date and time fields can now show placeholder suggestions based on another field's value instead of only fixed text. This helps forms provide more relevant guidance to users, such as suggesting a date that changes with the record context.
Original PR description
See commit Enterprise PR: https://github.com/odoo/enterprise/pull/72121
The deferred end date field now shows a dynamic hint that helps users understand the selected deferral period. This makes it clearer that both the start and end dates are included, reducing confusion during accounting entries.
Original PR description
We now add a dynamic placeholder to the deferred end date which allows the user to better understand what a deferred period is, and that both the start and end dates are included. task-id: none Community PR: https://github.com/odoo/odoo/pull/183946
Resolved issues and error corrections
A new automated test was added to help ensure down payment invoicing works correctly in Point of Sale sales flows. This reduces the risk of regressions in a customer-facing payment and invoicing scenario.
Original PR description
This test is linked to this commit: https://github.com/odoo/odoo/commit/42eb159b6adb668d26cfb31aec2a59a1fd4d3a00 Related PR: https://github.com/odoo/odoo/pull/188204 opw-4352799
Code cleanup and technical improvements
Attendance overtime calculation logic has been reorganized so it can be reused and customized more easily. This does not change current behavior, but it helps support customer-specific rules such as counting only overtime worked after the scheduled end of the day.
Original PR description
The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the start of the working day. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This is a regression since 48ef812a. Before, the field's views were rendered directly, getting all the decoration classes on them. Since 48ef812a, they are rendered as a child of a parent `Field` component (a `div`), which gets the decoration classes instead [^1]. The issue was partially fixed by 2f99f7dc, but only for `<input/>` and `<textarea/>` elements. The same fix is now applied to the `<select/>` element. [^1]: https://github.com/odoo/odoo/blob/60c7b65f/addons/web/static/src/
Original PR description
This is a regression since 48ef812a. Before, the field's views were rendered directly, getting all the decoration classes on them. Since 48ef812a, they are rendered as a child of a parent `Field` component (a `div`), which gets the decoration classes instead [^1]. The issue was partially fixed by 2f99f7dc, but only for `<input/>` and `<textarea/>` elements. The same fix is now applied to the `<select/>` element. [^1]: https://github.com/odoo/odoo/blob/60c7b65f/addons/web/static/src/views/fields/field.xml#L4-L8 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190763
This fix updates the Estonian localization upgrade process so an existing tax report is renamed rather than deleted and recreated. It helps preserve users' current report setup during module upgrades and reduces the risk of disruption.
Original PR description
In odoo/odoo#180856, a new version of the Estonian tax report is added with the xmlid tax_report, in order to not overwrite the tax report for users in stable who didn't update their modules. When upgrading the module, to avoid dropping and recreating the report, we add this upgrade script to rename the xmlid of the tax report. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update backports fixes to automated tests for the import feature. It helps keep quality checks reliable without changing how users import records in Odoo.
Original PR description
backport test fixes from https://github.com/odoo/odoo/pull/190453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The inventory error message now shows the relevant lot name when a lot is linked to another product, instead of incorrectly showing a location name. This makes the message clearer for users and helps them identify the right stock lot when resolving the issue.
Original PR description
Description of the issue/feature this PR addresses: - On the error message when we check the lot and it's linked to another product it displays the location_id instead of the lot_id which isn't correct. Current behavior before PR: - Incorrect displayed value in the error message. Desired behavior after PR is merged: - Replace the location name with the lot name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the planning module's search capabilities by adding a filter for 'Properties'. This allows users to more effectively narrow down their planning searches within the planning.slot and planning.analysis.report modules, improving efficiency and data access.
Original PR description
Before this commit there was no groupby Properties. In this commit we add a filter for groupby properties in planning module. The search view is being used by two modules`planning.slot` and `planning.analysis.report` thus solution resulted in adding the filter in `planning_view_search` as it is a primary inherited view of search view base in planning.slot. task-3801551
A recent update to Luxembourg tax rates in the Odoo Enterprise system caused some tests to fail. This commit adjusts the tests to reflect the new rates, ensuring accurate reporting and financial calculations. This update is part of ongoing improvements to our tax reporting functionality.
Original PR description
Description of the issue this commit addresses: The community commit linked to this one changed the rates of luxembourgian taxes used in the oss fiscal positions. Because of that, some tests are failing. --- Desired behavior after this commit is merged: Said tests are not failing anymore. --- Community PR: https://github.com/odoo/odoo/pull/189444 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/enterprise#75650
This update resolves a visual issue on the Helpdesk dashboard where a sample ribbon was obscured by the main banner. The fix adjusts the loading order to ensure the ribbon displays correctly, providing a cleaner and more functional user experience. This improves the overall appearance of the dashboard.
Original PR description
Steps to Reproduce: - Install the Helpdesk app without demo data. - Navigate to the dashboard. - Observe the `SAMPLE` ribbon in the top-right corner. Cause: - The issue occurs because the SAMPLE ribbon for "Fake Data for Demo" is rendered before the helpdesk banner. Due to this loading order, the banner displays on top of the ribbon, obscuring it. Solution: - By adjusting the loading order so the ribbon loads after the helpdesk banner, we ensure the ribbon displays clearly above the banner without additional adjustments. task: 4209920
This update resolves an issue where comparison cells in the consolidation report were incorrectly marked as auditable, potentially causing confusion. The fix sets the 'auditable' flag to false specifically for the ComparisonBuilder, ensuring compliance with audit rules. As the consolidation module is being decommissioned, this is a low-impact change.
Original PR description
Steps to reproduce: [l10n_be_us_consolidation_demo] - go to consolidation > Test Chart > Consolidated Balance > Comparison > Test Chart - click on a cell to proceed to an audit Issue: Stacktrace…
Steps to reproduce: [l10n_be_us_consolidation_demo] - go to consolidation > Test Chart > Consolidated Balance > Comparison > Test Chart - click on a cell to proceed to an audit Issue: Stacktrace Cause: Journal id is not defined. When there are multiple periods we use the `ComparisonBuilder` https://github.com/odoo/enterprise/blob/4367042c8c7f2190d23019e591c332045b7d4993/account_consolidation/report/trial_balance.py#L139 Which, contrarily to the DefautBuilder, journals is not defined. In the AbstractBuilder (inherited in the two builders), `auditable` is set to True without consideration of the builder's definition https://github.com/odoo/enterprise/blob/3e5ac3554f4fded90fd37c56c7c60723aec59404/account_consolidation/report/builder/abstract.py#L278 On the front side, whenver we click on a auditable cell, we call the action_open_audit but journal_id is defined https://github.com/odoo/enterprise/blob/2d774344109c2f9b55d9ea6160ae99aeca4f0420/account_consolidation/static/src/components/consolidation_report/line_cell/line_cell.js#L19-L38 -> error Solution: Asusming that `auditable` is the rule and the case for the comparison builder is the exception, auditable is set to False only in the ComparisonBuilder Since `consolidation` is meant to be decommissioned, the least impacting fix is being applied. Note: in 16.0, the cells are not auditable when using comparison periods. opw-4265031
This update fixes a display issue where the 'remaining' value on project budgets was incorrectly shown as a surplus. Now, it accurately reflects the difference between the budget's forecast and actual spending. This ensures project managers have a clear and correct view of budget status.
Original PR description
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872
This update resolves a testing issue within the l10n_pe_edi module related to handling 'NOT_EU_VAT' scenarios in Peru. The fix ensures accurate test results, improving the reliability of the module's functionality for Peruvian businesses. This addresses a technical detail that contributes to the overall stability of the Odoo Enterprise platform.
Original PR description
Community: https://github.com/odoo/odoo/pull/189421 task-4374458
This update resolves an issue where invoices couldn't be confirmed when a country lacked VAT information. The fix ensures that missing VAT country data is handled gracefully, treating it as '0' to allow invoice creation and confirmation. This prevents errors related to incorrect XML formatting.
Original PR description
This fix is to avoid the an error that occurs when a country does not have the VAT information set. Before this fix, when that situation happened the method get_vat_country returned False as those…
This fix is to avoid the an error that occurs when a country does not have the VAT information set. Before this fix, when that situation happened the method get_vat_country returned False as those fields values and therefore the XML could not be processed since it was expected an integer and it got a boolean. After this fix, if a country does not have VAT information, the field will be process as 0 and the XML will be created, so the invoice will be confirmed. We already had this approach in the past, inside the method wsfex_get_cae_request, but it was lost in a refactor made on the module. So what I did was just to recover that approach. https://github.com/odoo/enterprise/commit/33ea78a5bb34e657c16bcbb704eeb71897ae642d#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318L741. Steps to reproduce the error: - Create a test contact based on Uruguay. - Go to Contacts/Configuration/Localization/Countries and delete all VAT information from Uruguay (Natural Person VAT, Legal Entity VAT, Other VAT) . - Create an invoice for the test client created before, add a product and all needed fields and try to confirm the invoice. - An error will pop up, saying that the server was unable to read request because of an error in the XML document. Forward-Port-Of: odoo/enterprise#75501
This update corrects a technical issue preventing the l10n_ee_rounding module from automatically installing when the related l10n_ee_reports module is installed. Removing a specific country designation from the module's configuration ensures proper dependency management and simplifies the installation process.
Original PR description
In odoo/enterprise#70371, the manifest file for l10n_ee_rounding specifies the country 'ee'. However, since the module depends on l10n_ee_reports, adding 'countries' interferes with auto_install, leading to the module l10n_ee_rounding not being auto installed when l10n_ee_reports is installed. This commit removes the country specification from the manifest. no-task
This update corrects a visual issue in the Field Service Gantt View within Dark Mode. Previously, half-day off times displayed with a white background, now they match the background color of the full working day. This ensures a consistent and professional appearance across all views.
Original PR description
**Issue:** In dark mode, for current day, half days off are displayed with white background in the Field Service Gantt View for the working part.…
**Issue:** In dark mode, for current day, half days off are displayed with white background in the Field Service Gantt View for the working part.  **Expected:** In dark mode, worked half days should have same background as entire worked day for current date. **Steps to reproduce:** - Activate Time Off and Field Service apps and activate Dark Mode; - In `Time Off / Management / Time Off` create a new half day off time for any employee under contract (e.g. Mitchell Admin) for the current day; - Approve and validate; - Move to `Field Service / Planning / By User`; - Remove all search filters and display using Gantt View by week or by month; - *(opt) Create a new task for the chose user if does not appear*; - Look at the current day cell of the user. **Cause:** No dark theme background color is set to override the light theme. **Fix:** Setup background color for dark theme by overriding hard coded light theme color: https://github.com/odoo/enterprise/blob/7778a8e45502da89e27910efab401d3556d8c7f7/web_gantt/static/src/gantt_view.scss#L21   opw-4368966
As creating/obtaining a registry does not set the `dbname` context variable on the current thread, it must be set manually for the standalone tests to run correctly. Forward-Port-Of: odoo/odoo#190330
Original PR description
As creating/obtaining a registry does not set the `dbname` context variable on the current thread, it must be set manually for the standalone tests to run correctly. Forward-Port-Of: odoo/odoo#190330
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% ---
Original PR description
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% --- Enteprise PR: https://github.com/odoo/enterprise/pull/75650 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/odoo#189444
Any computed fields that depend on `customer_rank` or `supplier_rank` were not being recomputed when the ranks changed. This isn't noticeable on standard Odoo code, but downstream modules that use such feature wouldn't work. @moduon MT-8208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189127
Original PR description
Any computed fields that depend on `customer_rank` or `supplier_rank` were not being recomputed when the ranks changed. This isn't noticeable on standard Odoo code, but downstream modules that use such feature wouldn't work. @moduon MT-8208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189127
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field
Original PR description
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given…
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions. #### speedup Test database with account_accountant and sale. Trying to create batches of account.moves | Batch size | Before PR | After PR | |:----------:|:---------:|:--------:| | 1 | 70ms | 58ms | | 50 | 150ms | 100ms | | 100 | 275ms | 188ms | | 250 | 660ms | 450ms | | 1000 | 2.43s | 1.75s | | 3000 | 7.55s | 5.33s | Average speedup: 68%. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159983 Forward-Port-Of: odoo/odoo#157887
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190693
Original PR description
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190693