Friday, May 29, 2026
8 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where commission plans were incorrectly shown in a salesperson's 'Other Plans' list even when their assignment periods didn't overlap. The system now accurately checks for overlapping assignment dates, ensuring that only relevant plans are displayed, improving the accuracy of commission reporting.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118559 Forward-Port-Of: odoo/enterprise#112694
This update resolves an issue where Odoo Enterprise would generate a traceback when attempting to mark workorders as done in scenarios with no open workorders. The fix ensures the system handles empty recordsets gracefully, preventing errors and maintaining stability.
Original PR description
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety…
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 Inside button_finish, it retrieves all open workorders and marks them as done: - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 - mark them as done: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678 Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 -> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback. opw-6239910 Forward-Port-Of: odoo/enterprise#118403
This update ensures that General Ledger exports accurately reflect search filters applied in the user interface. Previously, the export didn't consistently include all accounts matching the search criteria due to a difference in how the UI and backend search functions were implemented. This change aligns the export with the standard account search behavior, providing more reliable reporting.
Original PR description
When applying a search filter in the General Ledger, the lines displayed in the UI differ from the ones exported. The discrepancy comes from the fact that the UI search bar filters lines using a simple "contains" logic on the displayed line name, while the backend export relies on the account model’s `_name_search` behavior, just as in the chart of accounts. For example, searching for "40" displays the accounts 400000, 400010, and 124000 but the last one (124000) is not is in the export results. task: 5917435 Forward-Port-Of: odoo/enterprise#117002 Forward-Port-Of: odoo/enterprise#107928
This update resolves a bug where formatting applied to inline code selections (like bold or italics) couldn't be consistently removed. The fix ensures that formatting nodes are correctly considered when checking for existing formatting, leading to accurate removal of applied styles. This improves the user experience when working with inline code within the To-Do module.
Original PR description
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching…
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching `is_formattable_node_predicates` are ignored. However, when checking whether the selection is already formatted, those nodes are not ignored, so the selection is erroneously considered to be only partially formatted. Solution: Take `is_formattable_node_predicates` into account when checking whether a selection is formatted. Steps to reproduce: - Go to To-Do → Create New. - Type some text and add inline code on the same line. - Select all content using Ctrl + A. - Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U). - Press the same shortcut again to remove the formatting. - Observe that the formatting is not removed. task-6229228 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265183
A recent test failure in the link tracker module was resolved by correcting a logic error. The fix ensures that searches for short URLs with overlapping code patterns (like 'b') return the correct, distinct links. This prevents duplicate results and improves the accuracy of link searches.
Original PR description
Problem ------ The test was trying to search for links that has specific code patterns in their short_url and distinguish links using this logic. However, it did not consider the case where the same code pattern might exist in two different urls. i.e `example/r/AbC` and `example/r/DbE` both contains `b`, so when searching for `b`, both urls will be returned. FIX ------ Testing the search on different code combinations for the short_url is not the subject of that unit test, it is sufficient to search for the exact codes and see if there are conflicting results. task-6254039 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a test in the account_payment module was unreliable due to dependencies on a module not always present. The test has been updated to use a more direct method, ensuring consistent and predictable results. This improves the overall stability of our payment processing tests.
Original PR description
The set_line_bank_statement_line method is defined in account_accountant, meaning we can't use it in account_payment as it will automatically break if enterprise is not installed. Replace it with direct call to _get_partial_amounts, which is the purpose of this test anyway. runbot-939260
This update keeps a previously removed setting in Odoo, allowing a warning message to be displayed during AI development. This change was necessary due to limitations in earlier versions of Odoo and ensures continued monitoring for potential issues. It's a minor adjustment to support ongoing development.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#262841
This update fixes a visual issue in the Project Kanban view where custom colors weren't being displayed correctly. The fix ensures that the Kanban status colors accurately reflect the backend data by correctly applying modulo calculations and mapping to the appropriate color variables.
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 Forward-Port-Of: odoo/odoo#266386 Forward-Port-Of: odoo/odoo#256023