Daily updates from Odoo
Tuesday, April 7, 2026
8 changes · master
Resolved issues and error corrections
This update fixes a calculation error in the payroll system related to minimum hourly wages for Belgium (CP200). Previously, the system incorrectly displayed monthly wages as the minimum hourly wage. Now, the system accurately calculates the minimum hourly wage based on the employee's wage type, ensuring accurate payroll reporting.
Original PR description
Before this commit, we don't consider calculating the minimum hourly wage in CP200. Related warning was showing a wrong value (the monthly wage). After this commit, we calculate the value of the min wage depending on the wage_type Hourly wage is calculated like this: (monthly_min_wage * 3) / 13 / hours_per_week task-6074973
This update resolves an error that prevented the General Ledger consolidation feature from functioning correctly when multiple companies were selected. The fix ensures the consolidation process now handles multi-company scenarios without crashing, improving the reliability of financial reporting.
Original PR description
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the…
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the issue: 1. Select two or more companies from multi company menu 2. Accounting / Reporting / Ledgers / General Ledger 3. Posted Entries, Accrual Basis button 4. Pick Consolidation 5. Error ### Cause of the issue: When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected). However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError. ### Reason to introduce the fix: To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors. opw-5933074 Forward-Port-Of: odoo/enterprise#112738 Forward-Port-Of: odoo/enterprise#109036
This update fixes a bug where flexible schedules with different time zones were incorrectly displaying an inflated number of expected hours (48 instead of 40). The change ensures accurate hour calculations by properly accounting for time zone differences, preventing inaccurate attendance reporting.
Original PR description
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of…
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang. 2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time. 3. Open Attendances. ### Expected behavior When we hover the name of our employee, we can see in white on green background 0/40h. ### Unexpected behavior Instead, we see 0/48h. ## Origin of the issue This line: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419 is used to retrieve the correct date. We assume that `end_datetime` will be set at midnight, so subtracting one second gives us the day before, allowing us to ignore the date of `end_dt`, for which we don't need to compute the intervals. However, this doesn't take into account different time zones. Indeed, we compute `end_datetime_adjusted` from `end_datetime`, which has the user timezone, and not UTC, as defined here: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402 As a result, if we set the user timezone to Pyongyang, `end_datetime` will be set at 8am, and `end_datetime_adjusted` will lead to the same date, instead of a day before. Hence, we would compute an additional interval for an additional day, which would in the end give us 48 hours expected instead of the 40 hours indicated in the contract. Therefore, we have to take into account the time zones, hours, minutes and seconds when checking the start and end dates. __ opw-5937298 Forward-Port-Of: odoo/enterprise#111332 Forward-Port-Of: odoo/enterprise#110011
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode lookups. The fix ensures the scanner uses the correct company information, resolving the problem of incorrect product identification and enabling accurate barcode scanning across different company setups.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112783 Forward-Port-Of: odoo/enterprise#111662
This update enhances the Gantt view by adding a visual warning – a danger icon – to shifts that were created to fulfill cancelled Sales Orders. This immediately highlights potential issues and ensures that team members are aware of orders that are no longer active, improving workflow efficiency. The warning remains visible in the shift's form view for additional detail.
Original PR description
Adding warnings on the Gantt view to make it more clear at a glance when a shift had it SO cancelled. ### Before Commit Behavior : 1. A Sales Order (SO) is created for a plannable service. 2. A shift is scheduled to fulfill the SO. 3. The SO is cancelled before the shift is completed. 4. No warning or icon is displayed on the shift in the Gantt view. 5. A warning is only visible in the shift's form view. ### After Commit Expected Behavior : When a shift is created to fulfill a Sales Order, and that SO is later cancelled: - A danger icon is displayed directly on the shift in the Gantt view. - A danger message is also shown in the shift preview within the Gantt view. - A warning in the shift's form view is still showed. #### Task : [4844848](https://www.odoo.com/odoo/project/4105/tasks/4844848)
This update enhances the functionality of French financial reports by transitioning from a 'hard reload' to a 'soft reload' process. This change improves the dynamic updating of report lines, leading to a smoother and more responsive user experience. It addresses a usability issue within the l10n_fr_reports module.
Original PR description
This commit will change the hard reload for a soft one, to make the usability of dynamic lines better no task id
This update simplifies the installation process for the ActivityWatch timesheet grid by adapting instructions and adding better troubleshooting tools. It also enhances the assistant's functionality with improved rule data and clearer display of activity information, ultimately making setup and usage more straightforward.
Original PR description
This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running. It also provides a few other fixes related to the assistant in general. Task-6042434 Forward-Port-Of: odoo/enterprise#113098 Forward-Port-Of: odoo/enterprise#112127
This update corrects inconsistencies in how Odoo calculates certain fields, specifically related to employee data. By switching from `@api.onchange` to `@api.depends`, the system now accurately reflects changes in related data within the same transaction, preventing potential data errors. This ensures data integrity across multiple modules.
Original PR description
https://github.com/odoo/odoo/pull/257758