Monday, May 11, 2026
7 changes · 17.0
Resolved issues and error corrections
This update corrects a reporting issue where planned hours weren't correctly excluded on public holiday days. The fix ensures that only public holidays related to the employee's company are considered when generating timesheet forecasts, improving reporting accuracy and preventing over-allocation of time.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070
This update resolves a duplication issue where the contract type ID was appearing twice in the HR offer form view for the Belgian localization. The code was corrected to ensure consistent contract type definitions across modules, preventing errors and improving data accuracy. This change is specific to version 17 and will be addressed in a separate PR after that.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717
This update fixes a technical issue where Google Calendar attendees with matching email aliases were being silently removed from Odoo events. This meant events would show up with incorrect attendee counts. The change ensures all attendees, even those using aliases, are properly synchronized, maintaining accurate event information.
Original PR description
When a Google attendee's email matches a configured mail alias, the attendee is silently lost during sync — the corresponding partner is excluded from the lookup result, and the event lands in Odoo with one fewer attendee than Google shows. opw-6086240
This update fixes a discrepancy in UBL/CII e-invoice exports caused by rounding differences. The change ensures that line totals accurately match the overall document total, preventing validation failures and ensuring compliance with invoicing standards. It addresses a technical issue related to how the system calculates and distributes rounding errors.
Original PR description
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to…
The sum of individual line extension amounts in UBL/CII exports can sometimes differ from the total expected amount due to cumulative rounding differences. Steps to reproduce: - Configure rounding to Round Globally - Have a Belgium company setup - Have a customer with Peppol enabled - Create an invoice with many lines where each line amount have multiple decimals before rounding (product price precision raised to 4, fixed tax with 4 decimals) - Confirm the invoice Issue: Discrepancy between line totals and the document total in the XML, leading to validation failure `[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)` Analysis: When generating e-invoice, we calculate the total line extension amount from unrounded line amounts, after adding the fixed taxes https://github.com/odoo/odoo/blob/b71b51ce8e78970104c97f599b533bdcf36484c0/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L396-L411 However, the sum of line rounded values may not equal the rounded sum of the raw values. This change tracks the expected rounded sum and compares it to the actual accumulated sum. If a delta exists, it is distributed across the lines to ensure the XML is consistent. Minimalistic backport of d66c299cf7fb781bbba6850d0ca17831aed0475d opw-5871638 Forward-Port-Of: odoo/odoo#251155
This update resolves a visual bug where the status bar displayed duplicate information for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, improving the user experience and data consistency. It corrects a conflict in how the system handles project assignments within sub-tasks.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970
This update fixes a visual issue in the project Kanban view where custom colors weren't being applied to task statuses. The fix ensures that task statuses (identified by backend IDs) are correctly mapped to their designated colors, improving the user experience and visual clarity of the Kanban board.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106
This update resolves a confusing user experience where discount codes wouldn't apply after being discarded. Now, users can successfully re-apply discarded codes without creating new reward lines, ensuring a smoother and more intuitive process for applying loyalty discounts. This improves the overall customer experience.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198