Daily updates from Odoo
Thursday, February 8, 2024
29 changes
Resolved issues and error corrections
Fixed a bug that prevented users from making calls through the phone field in various Odoo applications like Helpdesk and Recruitment. The system was looking for phone numbers under specific field names and would fail when applications used different naming conventions. This update allows the call feature to work correctly regardless of how each application names its phone number field.
Original PR description
Step to reproduce: 1) Install whichever app includes a phone number(Helpdesk, Recruitment, etc.) 2) Click on the 'Call' icon beside the phone field 3) It will throw a validation error Cause: There is a different name for phone/mobile number field in each application In the code, we are only going for 'mobile' and 'phone' field name which throws error Solution: Setting the current field name will solve the issue Task-3635976
This update improves the Spanish translations used in Ecuador's RIDE (electronic tax report) and adjusts the position of the date field for better usability. These changes ensure that Ecuadorian users see accurate and properly positioned information when generating their required tax reports.
Original PR description
Extra Translations for ecuadorian ride and change position of date field in v17.0
The activity inspector was incorrectly showing 0 documents and 0 MB for all activities. This fix corrects the display to accurately show the actual number of documents and their total file size. Users will now see the correct document information when reviewing activity details.
Original PR description
Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsModelMixin mixin. Task-3700259
This fix resolves an access permission error that occurred when non-admin users tried to link documents to records (such as vehicles in the Fleet app). The issue happened because the system was trying to access model information without proper permissions. The solution adjusts how the system retrieves this information, avoiding the need to grant additional access rights to users.
Original PR description
Steps to reproduce: ------------------- - install documents and fleet apps; - be a user who is not in the `base.user_admin` group; - have admin rights to fleet and document; - put a document in the "Fleet" workspace; - click on "Link to a vehicle" button; Issue: ------ - First issue: An access error is triggered when we want to get the `model` field for an `ir.model` record. - Second issue: When a `Reference` field has the `model_field` option, a read on `ir.model` is triggered and as we don't have the rights, this causes an access error. Solution: --------- Work on the `ir.model` record in sudo. Do not use the `model_field` option and use a default value for the `Reference` field which expects a string like `"model,id"`. Note: ----- This solution avoids adding a new access right for `ir.model` as follows: ```csv access_ir_model,access_ir_model,base.model_ir_model,documents.group_documents_user,1,0,0,0 ``` opw-3502558 Forward-Port-Of: odoo/enterprise#50784
The activity inspector in the Documents module was incorrectly showing 0 documents and 0 MB for file sizes. This fix corrects the display to accurately show the actual number of documents and their total file size using improved data retrieval methods.
Original PR description
Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsDataPointMixin mixin. Task-3700259 Forward-Port-Of: odoo/enterprise#56093 Forward-Port-Of: odoo/enterprise#55011
Fixed an issue where journal entries were missing when exporting the General Ledger report to Excel after unfolding accounts with the "Hierarchy and Subtotals" option enabled. The system now correctly identifies and includes all unfolded journal entries in the exported file, ensuring complete financial reporting data.
Original PR description
Summary: When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report. Steps to…
Summary: When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report. Steps to reproduce: 1. Enable debug mode 2. Create a new account group (Accounting > Configuration > Accounting > Account Groups) with a code prefix from 1 to 9 3. Open the general ledger (Accounting > Reporting > Audit Reports > General Ledger) and check the option "Hierarchy and Subtotals" 4. Unfold a line until you can see journal entries (e.g., "101000 Current Assets" on runbot) 5. Export the general ledger in XLSX, and open it: the journal entries do not appear Cause: In the local stack, there is a field "unfolded_lines" that is a list containing the unfolded lines in absolute format (e.g., if account A is in account group G, the line is noted as "G|A"). However, when checking if an account is unfolded, it checks if the name of the account is in this field (just the name and not the group/account), which is not the case if the account is in an account group. In this case, the children are not displayed because only the content of the unfolded lines is shown. Fix: Modify the check for whether an account is unfolded: check if the name in absolute format is in the unfolded_lines list. opw-3649550 Forward-Port-Of: odoo/enterprise#55753 Forward-Port-Of: odoo/enterprise#54385
This update removes the default Indian public holidays that were previously added to the payroll system. Due to issues that arose with the implementation, the team decided to revert this feature and allow organizations to manually configure their own public holidays instead.
Original PR description
We revert the below commit in this commit due to some issues that arose, so we decided to remove the default Indian public holiday. commit-https://github.com/odoo/enterprise/commit/403c8faf24afe79a533bab19d6c994ed5b5edc3a task-3693329
The payroll module's dashboard test was failing when the sign module wasn't installed, even though payroll doesn't require sign. This fix adds a check to only create sign-related test data when the sign module is actually available, ensuring tests run reliably regardless of which modules are installed.
Original PR description
Before this commit, the `test_dashboard_ui` test in payroll was relying on sign. However, `hr_payroll` does not depend on sign, which would lead to the test breaking when that module is not installed. This commit adds a check to see if sign is installed before creating the additional data related to it. Forward-Port-Of: odoo/enterprise#56051
This update fixes an issue where the spreadsheet dashboard feature would not properly handle cases when a dashboard is missing or unavailable. The fix ensures the system gracefully manages these situations, preventing errors and improving the overall reliability of the dashboard functionality.
Original PR description
Task: 3581647 Forward-Port-Of: odoo/enterprise#55828 Forward-Port-Of: odoo/enterprise#54628
This fix corrects an issue where document type assignments for Peruvian electronic invoicing were incorrectly affecting non-Peruvian countries. The change ensures that Peruvian-specific document handling only applies to Peruvian operations, preventing unintended side effects on other country configurations.
Original PR description
Avoid affect document type assignation for no Peruvian countries
This update corrects how subscription status is validated when saving sales orders. Previously, the system was incorrectly preventing subscription features from being available during the draft stage of quotations. The fix ensures subscription functionality works properly while maintaining the intended behavior for service products, with validation now occurring when orders are confirmed rather than during initial creation.
Original PR description
Original commit prevented `subscription_state` from being true if the SO wasn't a subscription. This fixed an issue with creating tasks/projects for service products. As of 4ac62c700826ce1b38307641f91b7c9ce4f91d54, keeping `subscription_state` as long as the quotation in draft status is intended behavior for saas-16.4+. Instead the issue gets resolved on in `action_confirm`. This commit was amended to only add tests to verify this behavior. opw-3709457 Forward-Port-Of: odoo/enterprise#55788 Forward-Port-Of: odoo/enterprise#55741
This update resolves a display problem in the HR Contract module where the contract quick-access button (smart button) was not functioning correctly when showing multiple contracts. The fix ensures that users can properly view and access contract information regardless of how many contracts are associated with an employee.
Original PR description
Fix the issue when the number of contract displayed on the contract smart button is greater than 1. Forward-Port-Of: odoo/enterprise#56036
Fixed an issue where switching between different email templates in the mass mailing editor would incorrectly apply the wrong theme design. When users switched from a themed email template to a basic plain text template, the editor would incorrectly display the previous template's design instead. This fix ensures each template displays with its correct design when navigating between them.
Original PR description
Steps: - Create a draft mailing based on a theme that has the snippets menu (the "Event Promo" theme, for instance). - Create another draft mailing, this time based on the basic theme ("Plain Text").…
Steps:
- Create a draft mailing based on a theme that has the snippets menu
(the "Event Promo" theme, for instance).
- Create another draft mailing, this time based on the basic theme
("Plain Text").
- Switch from the former to the latter using the form view pager.
The editor for the basic theme record is not supposed to have a sidebar
(snippets menu), as it uses the floating toolbar instead. But when
switching between records like described above, the basic theme gets
replaced by the theme of the preceding record, and the snippets menu is
added to the UI.
This happens because [1] patched the `setValue` function to handle the
case where the element for dropping snippets (.o_mail_wrapper_td) is
missing, in particular if it gets removed via the codeview. Such fix
most likely had in mind the scenario where the codeview is toggled on
and off, but not the call to `setValue` that also happens when switching
between records via the form view pager. As a result, the html content
of a record based on the basic theme, in which such "dropzone" is
absent, is added as a child of the previous record's .o_mail_wrapper_td
element. This is certainly not the desired behavior, as it ends up
overwriting the basic theme by the one from the previous record (the
theme is defined by a class in the .o_layout div, which is a parent of
the .o_mail_wrapper_td element).
This commit, besides fixing the described issue, takes the opportunity
to add a comment with the presumed reasoning behind commit [1] and
extends the test tour in order to prevent regressions.
[1]: https://github.com/odoo/odoo/commit/9be2cb538f937645be4650af1031c8a1445bb48b
task-3573951
Forward-Port-Of: odoo/odoo#148718
Forward-Port-Of: odoo/odoo#140197Fixed an issue where recurring event details (recurrence type and day names) were not being translated to the user's selected language when sending calendar invitations and updates. Now when users create recurring events and send emails, the recurrence information displays in their chosen language instead of defaulting to English.
Original PR description
### Steps to reproduce: 1. install the calendar module 2. in General settings, add the French -or any- language 3. create a new event 4. under **Options** tab choose the recurrence type to be weekly…
### Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
### Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
### Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
### Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
Forward-Port-Of: odoo/odoo#150644
Forward-Port-Of: odoo/odoo#141951This fix resolves a bug in CRM where users couldn't send emails directly from the activity preview window. When returning from the preview to the main email interface, the system wasn't properly reconnecting the email thread, causing errors. The fix ensures the email thread is correctly restored so users can send emails without encountering errors.
Original PR description
### [FIX] mail: Fix thread object transfer to chatter in CRM email preview This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window. The issue arose when returning to the chatter interface from the preview window, as the thread object was not properly passed back (to the chatter). This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue. Issue was traced back to the commit [FIX] mail: do not reload chatter when not needed https://github.com/odoo/odoo/commit/5d99de10ec09244e10e4130573ad2e0c38e8600 ### [reproduce] - install crm - create activityTypes AT with an email template specified( crm/configuration/activityTypes) - open a Lead, ( crm/sales/MyPiepline) - schedule activity with activity type AT - click "preview" on the activity - click "send" or just close the preview -> BUG traceback opw-3680600
This fix resolves a crash that occurred when users tried to add content blocks to email marketing campaigns. The issue happened because the system was trying to access properties of an empty selection when blocks were dropped into the email editor. Users can now successfully add blocks to their mailings without encountering errors.
Original PR description
Issue: ====== Adding a new block in mailing in email marketing raises an error. Steps to reproduce the issue: ============================= - Go to email marketing - Create a new mailing - Create one from scratch - Drop any block - `TypeError : Cannor read properties of null (reading 'parentElement')` Origin of the issue: ==================== When we drop the block in the iframe's document we trigger the `click` event but we don't have any selection yet in the document so `anchorNode`will be `null` thus the error. task-3724551
This update fixes an issue where invoices sent via Peppol Bis 3 would fail validation when the supplier doesn't have a VAT number. The system now uses the Peppol endpoint identifier as a fallback to meet regulatory requirements for supplier identification. This ensures invoices can be successfully transmitted to buyers even when VAT information is unavailable.
Original PR description
When using Peppol Bis 3 with a partner without VAT, use the `peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and `PartyLegalEntity/CompanyID` to avoid errors like: "[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Standard rated" shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63)." "[BR-CO-26]-In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present." Also adapt the tests, as the rules for the supplier's identifier are stricter than for customers. Forward-Port-Of: odoo/odoo#152898 Forward-Port-Of: odoo/odoo#152663
This fix resolves a bug where product quantities were incorrectly increased by 1 when users clicked the edit option in the product dropdown menu. The issue occurred because click events were being triggered globally on the product card. Now, the system properly detects when clicks happen within the dropdown menu and prevents the quantity update in those cases.
Original PR description
**Steps to reproduce:** 1- Install Field Service module 2- Create new task and click on products smart button 3- Hover over a product and click on the dropdown menu 4- Click on edit in the dropdown menu 5- Get back to the products page and check the quantity for the product you edited **Current behavior before PR:** When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated. **Desired behavior after PR is merged:** This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity. opw-3689864 Check https://github.com/odoo/enterprise/pull/54645
This fix resolves an issue where vendor information would disappear from the product variant view when adding multiple suppliers. Previously, the system was incorrectly clearing vendor data when processing empty product variant fields. The fix ensures vendor information is only updated when a valid product variant is actually selected, preventing accidental data loss.
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Go to product variants; 2. select a product; 3. add a new Vendor line in the Purchase tab; 4. save; 5. add another Vendor line; 6. save. Issue ----- Previous…
Versions
--------
- 15.0+
Steps
-----
1. Go to product variants;
2. select a product;
3. add a new Vendor line in the Purchase tab;
4. save;
5. add another Vendor line;
6. save.
Issue
-----
Previous line disappears from view.
Cause
-----
In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets the `product_tmpl_id` in `product.supplierinfo` if a `product_id` gets written without accompanying `product_tmpl_id`. Adding lines from the Product Variant views add `{'product_id': False}` to the values for every vendor in the list without a Product Variant, so their `product_tmpl_id` gets overwritten with the `product_tmpl_id` of an empty product.
Solution
--------
Only overwrite `product_tmpl_id` iff `product_id` gets written to a non-falsy value by changing `if 'product_id' in vals` to `if vals.get('product_id')`.
Related
-------
https://github.com/odoo/odoo/pull/149618
opw-3664524
Forward-Port-Of: odoo/odoo#153115
Forward-Port-Of: odoo/odoo#152881The web interface was crashing when trying to search for a large number of elements on a page due to technical limitations in how the search function was implemented. This fix updates the search method to use a more efficient approach that prevents these crashes and improves overall performance.
Original PR description
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results. Sometimes however the number of results can exceed the maximum number of arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them afterwards with the selector, we can simply use `querySelectorAll`. This will lead to the same result.
In order to respect the specification that `$from` can contain multiple elements we need to execute `querySelectorAll` on each of them. In practice however `cssFind` is always used on a single element therefore it basically serves the same purpose as `querySelectorAll`. Thus, it is marked as deprecated and should be removed in master.
opw-3703963
Forward-Port-Of: odoo/odoo#152729Fixed a bug where archived taxes were still being suggested when creating new purchase orders. The system now correctly filters out archived taxes, matching the behavior already in place for sales orders. This ensures users only see active, applicable taxes when building purchase orders.
Original PR description
Steps to reproduce: - Create a new purchase tax and archive it - Create a new PO Bug: the archived tax is still sugested on the PO Line Fix: apply same logic as for sales opw-3701429 Forward-Port-Of: odoo/odoo#152076
Users will now receive clear error notifications when printing fails, either through a pop-up in the Point of Sale system or in the IoT box logs. This fix also improves printer identifier compatibility by allowing hyphens in printer names, which are commonly used but were previously filtered out, helping prevent printing failures caused by identifier mismatches.
Original PR description
Currently, the user does not get any feedback if the printer couldn't print. This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx: https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55 After this commit, a pop-up error is displayed in the PoS as well as an error message in the IoT box logs so the user is informed that the printing failed. Also, the '`-`' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces and nothing seems to justify filtering it. opw-3458347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144325
This fix resolves an error that occurred when users tried to access a dashboard they didn't originally have permission to view, but were later granted access to. The system now properly handles cases where a dashboard URL is shared between users with different permission levels, preventing crashes and allowing authorized users to view the dashboard correctly.
Original PR description
How to reproduce 1. Log in as Mitchel and go to a Subscription dashboard 2. Copy the URL and paste in incognito 3. Log in as Marc (which does have access to the subscription dashboard) --> Traceback Task: 3581647 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152676 Forward-Port-Of: odoo/odoo#143614
This fix resolves an issue where employees would lose timesheet entries for public holidays when their overlapping leave requests were refused or cancelled. The system now automatically recreates the public holiday timesheet records when a leave is refused, ensuring accurate time tracking and payroll records.
Original PR description
…fter refusal Before this commit, if a public holiday was created on dates overlapping an existing validated leave, the timesheet entries for the public holiday would not be created as they already existed for the leave. If the leave was then refused or cancelled, the timesheet records linked to it would be removed and the employee would have missing timesheet entries for the public holiday. This commit fixes this behavior by recreating the public holiday timesheet records for the affected employees when refusing their leave. opw-3550523 linked to com: https://github.com/odoo/odoo/pull/145522 Forward-Port-Of: odoo/odoo#152367 Forward-Port-Of: odoo/odoo#151522
This fix resolves an issue where product ribbons added or modified in the shop editor were not being saved. The problem occurred because the ribbon element wasn't properly flagged as changed, preventing the save process from triggering. The fix ensures ribbons are now correctly saved when edited in the shop interface.
Original PR description
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item…
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item that is marked dirty, because the ribbon doesn't have a savable parent. Solution ======== Flag the ribbon as dirty manually to trigger saving process Note ==== the reason why this is needed in 16.0 and not before is [1]. Before that we did not check for the presence of the dirty flag (the "o_dirty" class) to determine if the page has to be saved. All of this has to be reviewed in the future, as explained by [2] and its following commits. Note that commits like [2] is probably the cause of ribbon not being savable anymore: parts of the DOM stopped being flagged with o_dirty by mistake... so the saving process was not triggered "by mistake" anymore. At the time of [1] for example: just clicking on a product image (to maybe then add a ribbon) was enough for it to be marked with the "o_dirty" class by mistake. This was probably solved later... creating the bug being solved here. [1]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70 [2]: https://github.com/odoo/odoo/commit/e8a86b860dcba5b7782fc26c4290eee48d9fcdee opw-3674520 Forward-Port-Of: odoo/odoo#152694
This fix restores the ability to display pickup locations when a delivery carrier is pre-selected during checkout. A previous code change accidentally removed this functionality, preventing customers from seeing available pickup points when the delivery option was already chosen. This update ensures the pickup location information displays correctly for customers using pre-selected delivery methods.
Original PR description
In the commit 671640c part of the commit 6ae9c9c was removed inadvertently. After this commit pickup locations will be displayed when the delivery carrier is pre-selected.
Fixed an issue where the POS preparation display would miss updates when the connection was temporarily lost. Now when the system reconnects, it automatically fetches any data that was missed during the disconnection, ensuring staff always see the most current order information.
Original PR description
The problem: The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. The problem is that the websocket messages that were send in the meantime were not captured on the client. To solve this, we make the bus_service send a `reconnect` event. That way, listeners will be notified that they have to try to fetch the data that they may have missed. https://github.com/odoo/enterprise/pull/56163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues with how lists are handled in mega menus within the website editor. It prevents unwanted list toggling in navigation menus, ensures proper attribute handling when converting elements to lists, and corrects styling issues with edited links in centered menu layouts. These fixes improve the reliability and appearance of mega menu editing.
Original PR description
I. When inserting a list to a mega menu, the closest `LI` is a nav-item within the navbar. We aim to prevent the toggling of this list. This commit ensures that lists with class nav-item in the…
I. When inserting a list to a mega menu, the closest `LI` is a nav-item within the navbar. We aim to prevent the toggling of this list. This commit ensures that lists with class nav-item in the navbar are not toggled. II. Commit [1] implemented an approach to preserve all the attributes when converting to a list. This is beneficial for `p` elements since they will no longer be in the DOM. However, elements other than `p` will always remain, requiring only dir attribute and not other attributes like href, data-name, describedby, etc.. to transfer to the list. III. The mega menu templates on the website, like `s_mega_menu_multi_menus` and `s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`. This div has multiple block type anchor nodes. When a list is added to the mega menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then adds the `oe_edited_link` class, resulting in the centering of the A tag due to the `inline-block` display of the `oe_edited_link` class. This PR fixes the issue by adding display `inline-block` when not with nav-link. [1]: https://github.com/odoo-dev/odoo/commit/c422db596d909efc5ae0ba049f8f9f5b80a90883 task-3609500 Forward-Port-Of: odoo/odoo#152902 Forward-Port-Of: odoo/odoo#144341
This fix resolves a problem where quickly hovering over colors in the color picker would accidentally deselect text. The solution improves how the editor tracks text selection, ensuring that when users rapidly switch between color options, their original text selection remains intact and properly highlighted.
Original PR description
This commit fixes the problem of selection change on colorpicker fast hover. Before this commit, hovering too fast on the colors of the colorpicker unselected text that would be on the edge of the…
This commit fixes the problem of selection change on colorpicker fast hover. Before this commit, hovering too fast on the colors of the colorpicker unselected text that would be on the edge of the selection and uncolored. This is fixed by deep ranging the selection at the moment we limit it to fonts. This improves the accuracy of the history as, in case the font tag has been removed, it saves the text node as the current selection. And since hovering updates rely on it, it prevents losing the selection when unhovering fast (which is the cause of the bug). We noticed two behavior when dealing with this bug. When hoving on a color cell and exiting out of the colorpicker altogether, no bug appears. But when switching between two cells, multiple selection issue happen. After analysis of the performance graph, we believe that this is due to the fact in the first case, onSelectionChange events are fired and the handler is called, whereas in the other case it doesn't happen. That handler particularly reacalulates the latest selection. And this doesn't happen in our pathological case. After testing this theory, we view that the problem is solved. task-3295858 Co-authored-by: Hamza Maimoune <hmai@odoo.com> Co-authored-by: Antoine Guenet <age@odoo.com> Forward-Port-Of: odoo/odoo#152937 Forward-Port-Of: odoo/odoo#130191