Daily updates from Odoo
Tuesday, April 8, 2025
23 changes · master
Enhancements to existing features
The rental order test now selects an available lot from the list instead of typing a fixed lot number. This makes the automated check more reliable and helps prevent false test failures without changing customer-facing behavior.
Original PR description
In this commit:
===
- Replaced `enterLotNumber("123456789")` with `selectNthLotNumber(1)` to ensure proper lot selection in the test case.
task-4572186
related-https://github.com/odoo/odoo/pull/199730Indian payroll setup no longer assigns a default partner to TDS under company contributions. This aligns payroll records with the fact that TDS is deducted from employees, not contributed by the company, helping avoid misleading contribution reporting.
Original PR description
TDS is always deducted from the employee side and is not part of the company's contribution. Hence, the default partner has been removed from the TDS record under company contribution. Key Changes: - Removed the default partner from the TDS company contribution rule. Task - 4667917
This update standardizes how internal messaging-related data fields are defined across Odoo apps. It helps keep mail, approvals, VoIP, and WhatsApp features more consistent and easier to maintain, with little direct change for end users.
Original PR description
https://github.com/odoo/odoo/pull/204634
The spreadsheet comment side panel was updated to match recent menu behavior changes. This helps menus appear in the right place and keeps the commenting experience consistent for users.
Original PR description
The `Menu` component changed props in o-spreadsheet. Task: [4655815](https://www.odoo.com/odoo/2328/tasks/4655815)
Resolved issues and error corrections
A small issue in the Brazilian electronic invoicing point-of-sale receipt logic was corrected. This prevents an automated testing error and helps ensure receipts continue to display reliably for Brazilian POS users.
Original PR description
In receipt override in l10n_br_edi_pos module we were trying to access config_id from order but the access need to be done through config. runbot error: 162185
This fixes an issue in the Swedish Point of Sale module where receipts checked the wrong source for fiscal device settings. It helps prevent receipt display or validation errors for Swedish POS configurations using fiscal data modules.
Original PR description
Module l10n_se_pos was trying to access to `useBlackBoxSweden` method from the order in the receipt. But since the receipt do not have the order instance, we need to use config.iface_sweden_fiscal_data_module Which is done in the commit. runbot error: 161626
A small typo was corrected in the manufacturing planning code that checks replenishment status. This helps ensure planning information is interpreted consistently and avoids minor errors in the master production schedule.
Original PR description
Typo from 94586ddbf05befe0b202d1efa971a225344f9ef5.
The employee search popup in appraisals no longer shows the Launch Campaign button, preventing users from starting appraisal campaigns from the wrong place. The appraisal employee list now uses the intended view so search results behave consistently.
Original PR description
After this commit, the `Launch Campaign` button is removed from the employee search modal. The newly inherited `view_employee_tree` mode is modified to be `primary` to create a separate list view. Then, the `open_view_employee_list_my` action view is updated with the newly created list view. By default, `Search more...` selects the first available list view if none has a priority, so it now uses the original `view_employee_tree` list view." task-4675979
Features or functions removed from Odoo
This change removes unused internal code from the Quality Control module. It has no functional impact for users, but helps keep the system easier to maintain and reduces future cleanup work.
Original PR description
The '_compute_show_validate' method in `stock.picking` was overridden in the quality_control module. However, this logic is unused and has no functional impact. - `show_validate` is already removed in this PR [Upgrade](https://github.com/odoo/upgrade/commit/8c4525d82559b00166efc1c79dcd7e8ed903e865#diff-a3e12f1aaf1abb34cce970e54be2476f58de074f6e2418267ec1818268a06a37R12). - `_compute_show_validate` method is removed in this PR [Community](https://github.com/odoo/odoo/pull/137864/files#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L498). This commit removes the dead code to keep the codebase clean.
Miscellaneous changes
PR https://github.com/odoo/enterprise/pull/82924 makes use of the field l10n_ar_currency_rate. But that field is not present in Odoo versions above 17.0 This field was removed in favor of invoice_currecy_rate from account_move, that stores the currency rate used for a document in Odoo 17 and above. This fix adapts the l10n_ar module to use that field instead. opw-4708505 Forward-Port-Of: odoo/enterprise#82974
Original PR description
PR https://github.com/odoo/enterprise/pull/82924 makes use of the field l10n_ar_currency_rate. But that field is not present in Odoo versions above 17.0 This field was removed in favor of invoice_currecy_rate from account_move, that stores the currency rate used for a document in Odoo 17 and above. This fix adapts the l10n_ar module to use that field instead. opw-4708505 Forward-Port-Of: odoo/enterprise#82974
Partial revert of the odoo/enterprise#78827 fix. The payment due date is in facts the payment date itself. This way we are able to handle different lines each with a different due date. The user will have to put it correctly manually in the Register Payment wizard even if the Payment Terms are specified on the invoice. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4703520) opw-4703520 Forward-Port-Of: odoo/enterprise#82950
Original PR description
Partial revert of the odoo/enterprise#78827 fix. The payment due date is in facts the payment date itself. This way we are able to handle different lines each with a different due date. The user will have to put it correctly manually in the Register Payment wizard even if the Payment Terms are specified on the invoice. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4703520) opw-4703520 Forward-Port-Of: odoo/enterprise#82950
Before, when sending a reminder for the followup via the send and print wizard, the customer statement, or the followup report, were only included if you checked email, but if only print was selected, the report was missing in the PDF. Now, when selecting print, email, or both, you get the report. opw-4570715 Forward-Port-Of: odoo/enterprise#82498 Forward-Port-Of: odoo/enterprise#81463
Original PR description
Before, when sending a reminder for the followup via the send and print wizard, the customer statement, or the followup report, were only included if you checked email, but if only print was selected, the report was missing in the PDF. Now, when selecting print, email, or both, you get the report. opw-4570715 Forward-Port-Of: odoo/enterprise#82498 Forward-Port-Of: odoo/enterprise#81463
Before this commit, the `ProjectEnterpriseTestUi.test_01_ui` test fails without demo data because the user is not considered as overloaded. The reason is because the user has more than one task assigned to him when the demo data is installed and so when a new task is planned for him, the system will see the sum of the allocated_hours of all tasks assigned to him inside the period displayed in the gantt is higher than the hours he can do. This commit makes sure the test does not depend on the
Original PR description
Before this commit, the `ProjectEnterpriseTestUi.test_01_ui` test fails without demo data because the user is not considered as overloaded. The reason is because the user has more than one task assigned to him when the demo data is installed and so when a new task is planned for him, the system will see the sum of the allocated_hours of all tasks assigned to him inside the period displayed in the gantt is higher than the hours he can do. This commit makes sure the test does not depend on the demo data and increase the allocated hours of the task creates inside the test. runbot-111415 Forward-Port-Of: odoo/enterprise#80334
pos*: pos_blackbox_be, pos_restaurant_preparation_display, pos_self_order_iot, pos_urban_piper In this commit, we adapt the point of sale modules to be compliant with the belgian restaurant certification. Community PR: https://github.com/odoo/odoo/pull/201979 Forward-Port-Of: odoo/enterprise#81348
Original PR description
pos*: pos_blackbox_be, pos_restaurant_preparation_display, pos_self_order_iot, pos_urban_piper In this commit, we adapt the point of sale modules to be compliant with the belgian restaurant certification. Community PR: https://github.com/odoo/odoo/pull/201979 Forward-Port-Of: odoo/enterprise#81348
- Replacing all special characters in generated EFT files with normal ascii counterparts to fit the requirements of the CPA005 standard. - Adding an assert for it in tests. task-4609483 Forward-Port-Of: odoo/enterprise#81015
Original PR description
- Replacing all special characters in generated EFT files with normal ascii counterparts to fit the requirements of the CPA005 standard. - Adding an assert for it in tests. task-4609483 Forward-Port-Of: odoo/enterprise#81015
Before this commit, the fetch error was not correctly caught, leading to a crash of the runbot when the server was not reachable. runbot: 160959 Forward-Port-Of: odoo/enterprise#82431
Original PR description
Before this commit, the fetch error was not correctly caught, leading to a crash of the runbot when the server was not reachable. runbot: 160959 Forward-Port-Of: odoo/enterprise#82431
In studio, editing a kanban, activate show invisible elements if needed Before this commit, when the footer had many items, those were not wrapped so, they overflew under the next card and were unreachable and unclickable. After this commit the overflowing elements are reachable and clickable, but still outside of the kanban box. They just have a z-index high enough to be visible and reachable. The motivation behind this choice is that we cannot really apply targetted visual rules as th
Original PR description
In studio, editing a kanban, activate show invisible elements if needed Before this commit, when the footer had many items, those were not wrapped so, they overflew under the next card and were unreachable and unclickable. After this commit the overflowing elements are reachable and clickable, but still outside of the kanban box. They just have a z-index high enough to be visible and reachable. The motivation behind this choice is that we cannot really apply targetted visual rules as those would betray the actual visual on the view in normal mode. task-4609581 Forward-Port-Of: odoo/enterprise#81820
Forward-Port-Of: odoo/enterprise#82941
Original PR description
Forward-Port-Of: odoo/enterprise#82941
Before this commit, the `Europe/Brussels` timezone was applied 2 times on the calculation of the end_datetime when the slot is linked to a template and so the end date time of the slot could suddenly be before the start date time, which should not be possible. The timezone is applied 2 times, because the start date time computed already got the right timezone, so it is not needed to apply again the timezone since the timezone is already defined thanks to the start date time used in the co
Original PR description
Before this commit, the `Europe/Brussels` timezone was applied 2 times on the calculation of the end_datetime when the slot is linked to a template and so the end date time of the slot could suddenly be before the start date time, which should not be possible. The timezone is applied 2 times, because the start date time computed already got the right timezone, so it is not needed to apply again the timezone since the timezone is already defined thanks to the start date time used in the computation. This commit makes sure the timezone is applied once during the calculation of the end datetime, to be sure the difference between UTC and the timezone to apply is not applied 2 times on the end date time. runbot-error-162055 Forward-Port-Of: odoo/enterprise#82529
Currently inter-company kit transactions aren't working: 1) Selling a kit product to another internal company (intercompany) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine`: Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit pro
Original PR description
Currently inter-company kit transactions aren't working: 1) Selling a kit product to another internal company (intercompany) and validating the delivery will not update the `qty_delivered` field on the corresponding `SaleOrderLine`: Currently the filters to capture moves which informs the delivered quantity of the line do not account for moves with `location_dest_id` pointing to the inter-company transit location (which should count towards the delivered value) 2) Receiving a kit product via intercompany will result in an inaccurate update on the `qty_received` field on the corresponding `PurchaseOrderLine`: Tests added here due to inter-company rule modules being enterprise only. opw-4267210 Forward-Port-Of: odoo/enterprise#82883 Forward-Port-Of: odoo/enterprise#78170
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:** Accurate price per unit of component. **Steps to reproduce:** 1. Create a finished product with a BoM: * has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final) * make component cost $100 for sake of example * has a workorder with a workce
Original PR description
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:**…
**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:** Accurate price per unit of component. **Steps to reproduce:** 1. Create a finished product with a BoM: * has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final) * make component cost $100 for sake of example * has a workorder with a workcenter with capacity sufficient to handle full BoM quantity producing (so 2 if used 2 -> 2 on BoM) 2. Create & process MO for finished product 3. Open the Production Analysis pivot view in the mrp app 4. In the `Measures` dropdown, check the `Expected Component Cost / Unit` field -> see that it shows `$50 / unit` instead of the expected `$100 / unit` **Cause of the issue:** This per unit value is divided by the BoM `product_qty` 2x: 1: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_account_enterprise/reports/mrp_report.py#L184 2: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_workorder_hr_account/report/mrp_report.py#L32 **Fix:** Remove the additional division operation in `mrp_workorder_hr_account` opw-4474710 Forward-Port-Of: odoo/enterprise#82913 Forward-Port-Of: odoo/enterprise#80560
When you apply a journal entry action (e.g. Create Vendor Bill) to several documents at once, you should be redirected to the journal list view. Since version 18.0, you're redirected to the form view of the last entry you've just created. The corresponding actions have several sub-actions and cannot be launched on several records at the same time. The selected documents are processed individually and the last sub-action returns systematically a form view. To fix this, we inject a con
Original PR description
When you apply a journal entry action (e.g. Create Vendor Bill) to several documents at once, you should be redirected to the journal list view. Since version 18.0, you're redirected to the form view of the last entry you've just created. The corresponding actions have several sub-actions and cannot be launched on several records at the same time. The selected documents are processed individually and the last sub-action returns systematically a form view. To fix this, we inject a context key containing the ids of the selection.Then the last sub-action uses it to determine the appropriate view(s) to return. task-4606751 Forward-Port-Of: odoo/enterprise#80273
This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715
Original PR description
This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715