Thursday, July 2, 2026
22 changes · saas-19.3
Resolved issues and error corrections
This change fixes an unstable test that could sometimes misread the activity counter shown in the interface. It ensures the test starts from a clean state so the counter reflects only the activities created for that test, improving reliability of the discussion app checks.
Original PR description
The avatar card tour asserts the systray activity counter, which the browser maintains from "mail.activity/updated" bus notifications. The counter is seeded at page load with a snapshot (activityCounter) and a baseline bus id (activity_counter_bus_id), and only notifications newer than that baseline are applied. The activity unlink/create done while preparing the test emit such notifications whose bus.bus rows are only materialized at precommit, so their ids could land after the baseline and be double-counted, leaving the counter wrong. Reset the bus right before the tour so those setup notifications are dropped and the baseline starts clean, and clear only the user's own pre-existing activities so the snapshot counts just this test's activities. https://runbot.odoo.com/odoo/error/237779 Forward-Port-Of: odoo/odoo#273103
This update fixes a test in the salary configuration flow that was failing because the employee’s private address was not properly set up. It helps keep the payroll setup process stable by ensuring the test matches the expected employee data.
Original PR description
Task-6329628 Forward-Port-Of: odoo/enterprise#122091 Forward-Port-Of: odoo/enterprise#121626
This update corrects how two internal guided flows simulate user typing, so they now behave more like a real person using the interface. It helps prevent Knowledge tours from failing and makes Studio text insertion work more reliably.
Original PR description
#### Description of the issue: - Since the search powerbox plugin now checks for the actual existence of `/` in the DOM, some knowledge tours were failing because only the input event was dispatched without inserting `/`. - In web_studio, `insertText` was not positioning the selection correctly after insertion and was not dispatching beforeinput event before the DOM insertion. #### After this commit: - Adapt the `openPowerbox` utility in knowledge to insert `/` in the DOM before opening the powerbox. - Dispatch `beforeinput` before DOM insertion and `input` after it in web_studio, and move the selection after the inserted text. Community PR-https://github.com/odoo/odoo/pull/266284 task-6243724 Forward-Port-Of: odoo/enterprise#118310
This fix makes UNSPSC code 10171500, “Organic fertilizers and plant nutrients,” available again in the product accounting list. It matters because users can now correctly classify these products when setting up product accounting information.
Original PR description
The code 10171500 - Organic fertilizers and plant nutrients wasn't appearing. In the file that has the unspsc product codes this one was set to False. Steps to reproduce: - Activate module product_unspsc. - Go to product > accounting. - Verify that this code is not listed. Ticket [link](https://www.odoo.com/odoo/project.task/4461974) opw-4461974 Forward-Port-Of: odoo/enterprise#121914
The Point of Sale now shows the real underlying error when a database transaction fails instead of a generic message. This makes it easier to understand what went wrong and speeds up troubleshooting.
Original PR description
Before this commit the error "Transaction could not be created" was thrown when the transaction could not be created. This commit changes the behavior to throw the actual error that caused the transaction creation to fail, providing more context for debugging. Forward-Port-Of: odoo/odoo#273116
This change fixes an automated test in the self-order point of sale feature that could incorrectly create multiple orders for the same table. It ensures the test uses a separate table per configuration, preventing false failures in validation and build checks.
Original PR description
In the test test_self_order_table_sharing, the test could fail due to multiple orders being created for the same table on different config since the same table was used on multiple config. This commit fixes this test by creating a new table for the config. runbot-error: 240898, 240896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253862 Forward-Port-Of: odoo/odoo#253081
The translation dialog now shows translated text with a cleaner, more consistent layout in normal use. In debug mode, translations are no longer preselected when multiple options exist, which helps avoid accidental choices and makes the confirmation button stay disabled until a selection is made.
Original PR description
Before the commit: the translated text is with green background color. In debug mode, the translation generated by the last translator is selected by default. After this commit: In non-debug mode, the translated text is now wrapped in a div and with a similar style as the previous versions. In debug mode, when there are multiple translators, the translated text is no longer automatically selected. When there's no translation selected, the confirm button is disabled. The translated texts are now wrapped inside gray/dark gary background color. task-6250193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website cookie bar now keeps the intended spacing between buttons and links, even when edited in the page builder. This prevents the elements from appearing cramped or touching each other in the “Discrete” layout.
Original PR description
[FIX] website: preserve cookie bar button spacing Steps to reproduce: - Enable the cookies bar in the website settings. - Go to the website and enter edit mode. - Open the cookies bar from the invisible elements panel. - Select the "Discrete" layout in the options. => The buttons and link are rendered without the expected spacing. Before this commit, the client-side cookie bar template relied on whitespace-only text nodes to separate inline elements. Those nodes are not kept in the same way when the template is rendered by Owl, so selecting the layout could make adjacent buttons touch each other. After this commit, the spacing is carried by explicit Bootstrap spacing classes, so the rendered layout no longer depends on text nodes preserved by the XML formatting. task-6251151 Forward-Port-Of: odoo/odoo#272641 Forward-Port-Of: odoo/odoo#267488
This update fixes an unreliable test in the Viva.com POS payment flow that could sometimes hang during automated runs. It now waits for the payment step to complete before sending the simulated webhook response, making the test process more stable and dependable.
Original PR description
The Viva.com POS tour was failing intermittentely due to the mocked webhook response not waiting for the payment/refund request to finish. This would cause the tour to hang as it missed the webhook confirmation. We fix the issue by changing the `waitingCard` status to only be set after the payment request returns, and wait for this status before sending the fake webhook response. runbot-243758 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273111
This update adjusts the appearance of a key button within Odoo to align with the previous version's design (M3). Additionally, the code has been simplified by removing custom styling and leveraging existing Odoo components, and a touch device issue related to hover states has been addressed. This ensures a consistent and user-friendly experience.
Original PR description
In this commit, we adjust the margin/padding of the `boolean_icon_field` button to match the M3 design. We also remove the custom CSS and rely on existing `bootstrap` classes that provide the same behavior. Finally, we remove the hover color on touch devices, since a tap can trigger the hover state, but there isn’t a proper "unhover" afterward because the element remains focused. task-6305864 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem in the automated tests for Odoo's payroll module. The fix ensures that tests accurately reflect access permissions for different employee types, preventing potential issues with payroll calculations. This improves the reliability of the payroll system and reduces the risk of errors.
Original PR description
task-6348716
This update enhances the accuracy of clock-in and clock-out data sent to the blackbox, preventing potential errors. It also strengthens the system's stability by preventing conflicting clock entries and automatically logging cashiers out when a screen is idle.
Original PR description
Trim strings data before sending to the blackbox. Also make clock-in/out more robust: - call handleClockInOut through a Mutex to avoid concurrent races - clock the cashier out when the idle SaverScreen is shown FW of this PR: https://github.com/odoo/enterprise/pull/122471
This update resolves an issue where header text on mobile was too dark against certain background colors, making it difficult to read. The fix corrects a conversion error that prevented CSS styling from applying correctly, ensuring optimal text contrast and readability for users.
Original PR description
Steps to reproduce: - Set the header position to "Over the Content" - Set the background color to the last preset (dark) - Go to mobile view => If you are at the top of the page when opening the menu, the text is too dark to be readable. When the conversion from publicWidget to interaction was done, a mistake was made when converting HeaderGeneral. `o_top_menu_collapse_shown` was not toggled on `header#top` anymore. Therefore some css was not applied, leading to issues with the color constrasts. This commit fixes this issue by fixing the selector in dynamicContent. task-6311038 Forward-Port-Of: odoo/odoo#271410 Forward-Port-Of: odoo/odoo#270560
This update fixes an issue where the activity counter in the Odoo interface was displaying incorrect values, sometimes going negative. The root cause was a mismatch between how the counter was calculated on the server and client sides. The fix ensures the counter accurately reflects the number of relevant activities, improving the user experience.
Original PR description
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there…
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there activity counter next to the activity clock icon in the top right should be 2 - Click on the activity clock icon in the top right > Notifce the activity counter decreases to 1 - Mark as done both To-Do activites # The problem The activity counter is negative # Cause This issue is due to a desync between the activity counter client side and server side. When clicking on the activity clock icon, the front-end fetches the mail store data from the backend, which is why we see the activity counter decrease. The server computes the activity counter the following way : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457 It searches for up to 1000 activities and group them by the record they are associated to (e.g. a sale.order). Then, for each of these records, if atleast one activity is late or for today, increase the counter by 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509 Essentially, server side, we get a single +1 in the activity counter by record, not by activity On the other hand, client side, we simply add 1 in the activity counter every time a new activity is created. If an activity is deleted, then we remove 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30 https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309 # Proposed solution Both the client and server side logic were edited fairly recently Server side : https://github.com/odoo/odoo/pull/234899 Client side : https://github.com/odoo/odoo/pull/215880 According to experts, the activity counter should count records, not activities, so we should fix the client side but properly doing so would introduce too much complexity. We instead simply prevent the counter from going below 0. opw-6116821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259602
A recent issue in the Odoo barcode scanner was preventing it from working correctly in the latest Brave Browser. This update automatically restarts the video preview after the first scan, ensuring a smooth scanning experience. This fix improves usability for all users.
Original PR description
Issue: ====== - In the latest Brave Browser version (1.90+), the first scan works properly, but the video preview disappears during the second scan. Fix: ==== - During the second scan, the video is unexpectedly paused. We now automatically play the video again if it is paused. task-6218047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265436
This update fixes a bug where minimal rights employees could accidentally enter negative quantities when using the keyboard. The fix prevents users with restricted permissions from using the '-' key to modify quantities, ensuring accurate order management. This improves data integrity and reduces the risk of errors.
Original PR description
Currently minimal rights employee cannot select the "+/-" button to have a negative quantity line. However if they have a keyboard and press the "-" key they can modify the quantity to negative. Steps to reproduce: ------------------- * Modify the shop settings, give some employee minimal rights * Open shop and use the minimal employee as cashier * Add a product to the order * Press the "-" key on the keyboard > The line quantity becomes -1 Why the fix: ------------ The button on the product screen is disabled for the employee with minimal rights https://github.com/odoo/odoo/blob/4a2aa33ded628200935b22c501a5f94c21dffb1f/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L154 We extend that to the input key "-". opw-6248098 Forward-Port-Of: odoo/odoo#267748
This update ensures that VAT displayed on exported invoices is correctly translated into the customer's chosen language, rather than the user's. Previously, VAT was shown in English regardless of the customer's preferred language setting. This change improves accuracy and a better customer experience.
Original PR description
Issue: While exporting an invoice as PDF, Customer VAT is translated according to user language instead of customer chosen language. Steps to reproduce: - In a Belgian company - Install Greek language, but keep English as user language - Create a Customer and select Greek as their language - Create an invoice - Export as PDF Current behavior: - VAT is displayed in user language Expected behavior: - VAT is displayed in customer language (ΦΠΑ) opw-6264065 Forward-Port-Of: odoo/odoo#270574
This update ensures GIF functionality in Odoo continues to work smoothly. The system has switched from the now-discontinued Tenor GIF API to the Klipy GIF API. Users should update their API keys to Klipy to maintain GIF support, as the Tenor key will no longer be valid.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit makes the Tenor API key input settings use a Klipy GIF API key instead of a Tenor GIF API key. To keep GIF working after this commit, the API key must necessarily be changed to a Klipy GIF API key, as the old Tenor API key would be considered as an invalid Klipy API key. Task-5491965 Upgrade: https://github.com/odoo/upgrade/pull/10516 Forward-Port-Of: odoo/odoo#272898 Forward-Port-Of: odoo/odoo#250113
This update ensures that only complete and accurate address data is sent to Fiskaly for POS certifications. Previously, placeholder values like 'N/A' were included, which is now corrected to only send available information, streamlining the process and improving data quality. This change avoids unnecessary data transmission and potential issues with Fiskaly.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
This update fixes an issue where thread messages were not displaying properly due to a technical problem with how the system tracked loading states. The change ensures that thread messages are reliably rendered, improving the user experience when viewing conversations. This was a bug related to how the system monitored loading status and triggered updates.
Original PR description
The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces…
The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset. But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`. Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals. https://runbot.odoo.com/odoo/error/940032 Forward-Port-Of: odoo/odoo#273651
This update fixes a discrepancy in how the system counts expenses linked to sales orders. Previously, only expenses tied to specific order lines were counted, leading to inaccurate numbers displayed on the sales order form. Now, all expenses associated with a sales order are correctly counted, ensuring the smart button displays the accurate total expense count.
Original PR description
**Before this commit** Only expenses that generated a sale order line on an SO would be counted in that SO's count of expenses, introducing confusing behavior with the smart button on the SO form view that would take the user to a list of all expenses that have anything to do with the current SO. **After this commit** We return to the behavior that was present in Odoo 18.1 where all expenses that are associated with a SO show up in that SO's "expense_count", making the number in the smart button consistent with the number of expenses that will be fetched when clicking on it. opw-6309575 Forward-Port-Of: odoo/odoo#272287
This update resolves a technical problem that could have caused errors in the processing of French tax reporting (F10) for certain Odoo users. The fix prevents a faulty SQL query from being generated when a specific date calculation resulted in no data, ensuring accurate tax reporting functionality.
Original PR description
Fixes _force_update_l10n_fr_f10_moves(). It would create a SQL query that compares a date to a bool when _pdp_get_flow_10_start_date() returned None. Forward-Port-Of: odoo/odoo#273006