Saturday, May 9, 2026
11 changes · saas-19.3
Resolved issues and error corrections
This update fixes a bug in how tax reports calculate balances. Previously, a leading hyphen in a tax tag formula caused incorrect results, often returning a value of 0. Now, the system correctly interprets hyphens to negate balances, ensuring accurate tax report calculations.
Original PR description
When writing a new formula on a tax_tags expression, if the tag is not shared by other expressions, the tag should be renamed accordingly. Before this commit, when the new formula started with a '-' sign, the tag ended up with that same '-' at the beginning of its name. This was wrong: from 19.0 on, a tax tags formula starting with '-' means we want to negate the balance of the move lines having that tag. Because of that, when computing the report, the expression would look for a tag without the '-' in its name, not find it and essentially always compute a result of 0. Forward-Port-Of: odoo/odoo#262371 Forward-Port-Of: odoo/odoo#262059
This update resolves an issue that caused errors when closing all conversations in the chat application. The fix prevents a re-render from triggering a traceback by adding optional chaining to access channel data. This ensures a smoother and more reliable chat closing experience for users.
Original PR description
When closing all conversations from ChatHub, setting `confirmCloseResolver` to `null` in `_canClose()` starts a re-render of ChatHub and ChatWindow, but the render does not complete and `requestClose()` continues. During this flow, `close()` deletes the chat window, and when the re-render of ChatWindow actions continues, the call and camera-call action name callbacks try to access `channel.hasRtcSessionActive`, causing a traceback. This commit fixes the issue by adding optional chaining on channel in the name functions of the call and camera-call thread actions. Task-[6120744](https://www.odoo.com/odoo/project/1519/tasks/6120744) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260308
This update fixes an issue where some UBL invoices were being processed incorrectly. The system now intelligently checks for a specific 'CustomizationID' to determine if an invoice is a BIS3 format, improving the accuracy of invoice processing. A fallback mechanism remains in place for unknown formats.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263527 Forward-Port-Of: odoo/odoo#263285
This update resolves a bug where users with limited permissions experienced errors when accessing task details within subscription timesheets. The fix involves simplifying data retrieval to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update resolves an issue where a single error during website editing would lock the editor, preventing users from making changes. The fix ensures that errors during interaction cleanup are handled gracefully, allowing the editor to recover and continue functioning correctly. This improves the overall reliability and usability of the website editing feature.
Original PR description
When entering website edit mode, `websiteEditService.handleEditPage()` calls `InteractionService.stopInteractions()`. Currently, a failure while destroying a single interaction aborts the entire stop sequence. This prevents the editor from loading, leaving users unable to modify or delete the element that caused the failure. Any errors encountered during destruction are caught and stored so the remaining cleanup can complete, and then they are rethrown. This ensures the transition to edit mode is not blocked by a single element's failure. task-5180598 Forward-Port-Of: odoo/odoo#263098
This update fixes a minor usability issue in the Helpdesk module. Previously, users couldn't easily delete a stage in a Kanban view due to a missing keyboard shortcut. This commit adds the necessary shortcut, streamlining the stage deletion process and improving user efficiency.
Original PR description
Before this commit, when the user tries to delete a kanban column in ticket kanban view when the group by is stage_id. A pop-up appears when there is at least one ticket in that stage to notify the user it would be better to archive the stage or remove all tickets from that stage before deleting it. The Confirm and Discard buttons of that wizard does not have keyboard shortcut as the other discard button in the other views/wizards. This commit makes sure the keyboard shortcut is correctly assigned to those buttons. task-4885677 Forward-Port-Of: odoo/enterprise#116297 Forward-Port-Of: odoo/enterprise#89141
This update fixes an issue where taxes were incorrectly assigned to the wrong company due to a change in how the system cached tax information. By partitioning the cache based on company ID, we ensure that taxes are now correctly associated with the appropriate business, improving data accuracy and financial reporting.
Original PR description
Details and steps to reproduce are in Issue #262709 Cause: In #248680 the cache was changed to be global (per cr), meaning it is shared across companies. We need to partition the cache by company_id to prevent the assignment of taxes from the wrong company. OPW-6189579 Forward-Port-Of: odoo/odoo#262779
This update resolves issues with the WPS report generated for Saudi payroll, specifically ensuring accurate data submission. It now requires necessary identification documents and automatically maps bank information based on the employee's location, improving compliance and report reliability.
Original PR description
this commit includes the following fixes for the WPS report in SA: - Make the Saudi National / IQAMA ID required for generating the WPS file. - Remove the condition on the field [57 - BANK] and have it always filled if the SARIE code is set. - If the employee bank account is from a different country (other than KSA or null), map the field [57 - BANK] to the swift code. task-6144299 Forward-Port-Of: odoo/enterprise#116725 Forward-Port-Of: odoo/enterprise#116419
This update significantly speeds up the calculation of employee rate warnings by optimizing how the system checks for missing sales order links. The previous method was inefficient and slow, especially with large projects. This change uses a more targeted SQL query, resulting in a 33x performance improvement.
Original PR description
Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map. This…
Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map. This approach had two major flaws: 1- Iterating over all accessible tasks is highly inefficient for large projects, especially since many tasks do not even have associated analytic lines. 2- Fetching analytic lines blindly by task_id could pull in lines linked to a completely different project_id adding performance issues. **Solution**: Since the compute method for the `project_id` field for the `account.analytic.line` model is making sure that the field `project_id` equal the project for the task, then we can remove the domain matching for the `task_id`. We now can replace the `_read_group` with a simple SQL query, filtering out the unmapped projects directly. The benchmark done below was on a database that had around 10M analytic lines, 2K `project_sale_line_employee_map` records and 1M tasks with the top 80 projects in terms of the number of `analytic.lines` + projects that had the most records in the `project_sale_line_employee_map`. | Before | After | | :--- | :--- | | 33.0s | 170.0ms | Forward-Port-Of: odoo/odoo#260935
This update resolves an issue where standard users couldn't create projects from templates due to restricted access permissions. Adding 'sudo' ensures the necessary changes to project settings can be made correctly, preventing errors and maintaining the functionality for all users. This improves the overall user experience and avoids disruptions.
Original PR description
Steps to reproduce: - Ensure: - Marc Demo is a “Project” admin - All projects have “allow_task_dependencies” set to false. This will remove the “Use Task Dependencies” group from Role / User, so the…
Steps to reproduce: - Ensure: - Marc Demo is a “Project” admin - All projects have “allow_task_dependencies” set to false. This will remove the “Use Task Dependencies” group from Role / User, so the order of these steps is important - Add Role / User implies “Use Task Dependencies” - Sign in as Marc Demo and attempt to create a new project from the “Product Launch Campaign” template Description: `_inverse_allow_task_dependencies()` uses `_check_project_group_with_field()` to determine if task dependency features should be enabled/disabled by modifying the `hidden` field on `mail.message.subtype` records (e.g. `mt_task_waiting`). This occurs whenever a project is created from templates. However write access to these records are restricted to admins, so we need elevated permissions when attempting to do so. Without `sudo`, access errors are thrown if non-admin users attempt to create projects under specific scenarios (i.e. when `_check_project_group_with_field()` adds or removes a group from the user base group). The search within `_check_project_group_with_field()` also needs elevated permissions to prevent false negatives. Without `sudo`, this search is restricted by the user's record rules. If the user cannot see the specific projects where dependencies are active, the system may incorrectly assume that no projects use these dependencies, and will forcefully unlink the dependency group from `base.group_user`, breaking the feature globally for all users. Applying `.sudo()` to the subtype modification and the project search ensures standard users can create projects from templates without crashing and prevents the accidental global removal of the dependency group. opw-6099425 Forward-Port-Of: odoo/odoo#263203 Forward-Port-Of: odoo/odoo#258996
This update fixes an issue where portal users couldn't view timesheet information associated with tasks. The change adjusts how timesheet visibility is managed within the system, aligning with a recent portal refactor. Now, portal users correctly see the timesheets linked to their tasks.
Original PR description
Steps to reproduce: - Install `website_timesheet` - Enable timesheets from website - Share a task with a portal user - Log in as the portal user - Open the tasks on the portal Issue: The Timesheets is not visible. Root cause: Earlier, portal card visibility and existence were controlled directly in the QWeb template. After the portal refactoring, their visibility and existence are now managed by `portal.entry` records. Fix: Determine timesheet visibility using the corresponding `portal.entry` record. task-5455588 Forward-Port-Of: odoo/odoo#241832