Sunday, April 19, 2026
5 changes · 19.0
Resolved issues and error corrections
This fix prevents the color picker from closing unexpectedly when users hover over colors while editing an inserted icon. It restores smooth icon color selection in the HTML editor, reducing friction when formatting notes and other editable content.
Original PR description
Commit [1] did already fix this problem, but commit [2] broke it again. This commit restores the condition that was removed by [2] but adapts it slightly in order to only take into account the direct children of the node, instead of any sub-node when checking for the presence of icons. Steps to reproduce: - Go to a "To do" note - Insert an icon with /media - Select the icon - Open the color picker - Hover a color => Color picker closed right away [1]: https://github.com/odoo/odoo/commit/1adfd9b9daf09c26ad642faf411574123110b9be [2]: https://github.com/odoo/odoo/commit/85688ffd11a3a988bf32c8c923a4628a89b57f87 task-6128069
Voiding a Stripe payment that was authorized but not captured no longer creates a refund payment entry. This keeps sales and payment records accurate when no money was actually collected.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924 Forward-Port-Of: odoo/odoo#259230
This update resolves an issue where copying a user also duplicated their assigned tasks, leading to shared task assignments. The fix ensures that new users have independent task assignments, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both.
This update resolves an issue where menu visibility in the Timesheet module didn't immediately update after changing the 'Billing Rate Indicators' setting. The fix ensures that menu changes are reflected correctly, improving the user experience and eliminating the need to clear the cache or restart the server. This change is specific to version 19.0.
Original PR description
Steps to reproduce: - 1. Only install 'sale_timesheet_enterprise'. 2. Go to Timesheets > Configuration > Settings. 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) on and off and save. 4.…
Steps to reproduce: - 1. Only install 'sale_timesheet_enterprise'. 2. Go to Timesheets > Configuration > Settings. 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) on and off and save. 4. Check the menus. Issue: - Menu visibility does not update immediately after saving the setting. Menus that should appear (e.g., "Employee Billing Time Targets") remain hidden, or vice versa, until the cache is cleared or the server is restarted. Cause: - The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because timesheet_show_rates is not included in cache_invalidation_fields(). As a result, the stale old menu remains in memory. Fix: - Override cache_invalidation_fields in res.company to include timesheet_show_rates so that toggling this setting clears the Registry cache and forces recomputation of the menu. Note: - This fix is required only for 19.0. From saas-19.1, it will be solved in odoo/enterprise#106464. task-5428010
This update resolves an issue where dropdowns within knowledge articles weren't closing when clicking outside the embedded view. The fix adjusts the way the system detects clicks to ensure dropdowns close consistently, regardless of where the user clicks. This improves the overall usability of the knowledge article feature.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082