Thursday, July 2, 2026
33 changes · saas-19.4
Resolved issues and error corrections
This change makes the avatar card test more reliable by ensuring the activity counter starts from a clean state before the tour runs. It prevents earlier setup actions from being counted twice, which avoids random test failures and improves confidence in the discussion features.
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 fix prevents an error that could appear when a user removes the currency from the payment register while using the Argentine withholding setup. It improves the payment flow by allowing the form to be cleared without triggering a traceback.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272891 Forward-Port-Of: odoo/odoo#255825
This change updates HTML validation so an empty string is treated as valid content. It prevents empty knowledge articles and similar pages from being misread as broken HTML, which avoids display issues and failing tests.
Original PR description
The [related PR] introduced this santization check for invalid html in xml templates. However, it considers commits on empty knowledge articles as invalid HTML, causing an empty code view to be rendered which breaks some tests. Instead, we should consider an empty string as valid HTML. Related PR: https://github.com/odoo/odoo/pull/260405 Backport Of: https://github.com/odoo/odoo/pull/271882 runbot-937767
This change fixes an occasional issue where a task history window could open before the page had finished loading its data. As a result, users should no longer see random failures when using this flow, making the experience more reliable.
Original PR description
Sometimes the tour runner is trying to open the history dialog before Owl have received and updated the record data. This create an error, because the history dialog think there's no data to display. To avoid this issue, we add a step to ensure the Owl renderer has finished loading and populating the record data into the form view, before opening the history dialog. runbot-243510 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Ecuadorian payment methods get the correct SRI-related value when they are created. It fixes an issue where the field could be left unset, which helps keep payment configuration accurate and reliable.
Original PR description
Since bcfeed4b24f5155c111c3866e779bb2f119b9da8 the field used a default function relying on self.code, which is always falsy on creation. Make this field computed to correctly set the value.
This update prevents thin visual gaps from appearing in Chrome while users browse theme previews in the website configurator. It improves the appearance of the preview cards so the setup flow looks cleaner and more polished.
Original PR description
Steps to reproduce: - Open the website configurator in Chrome. - Choose an industry and reach the Layout step. - Look at the theme preview cards. => Thin gaps can appear between adjacent sections.…
Steps to reproduce: - Open the website configurator in Chrome. - Choose an industry and reach the Layout step. - Look at the theme preview cards. => Thin gaps can appear between adjacent sections. Before this commit, Chrome could show 1px gaps in configurator theme previews when the `iframe` was scaled down. This came from a known rendering issue with fractional transforms [1]. A similar issue was already fixed for website pages built with the Website Builder when using background shapes [2]. That fix uses JS to adjust each `.o_we_shape` size. In the configurator, previews are static and small, so a local CSS overlap is enough and avoids running layout calculations for each preview `iframe`. After this commit, configurator previews add a small overlap on sections and shapes, so Chrome no longer exposes the background seam. [1]: https://issues.chromium.org/issues/41137778 [2]: https://github.com/odoo/odoo/commit/f7fd40d619d8bc2b5edc09de3a71a1954b4f3b52 task-6340483 BEFORE THE FIX (only Chrome) <img width="706" height="544" alt="image" src="https://github.com/user-attachments/assets/93c94961-8fd3-43da-bf32-3932ee98118d" /> AFTER THE FIX (only Chrome) <img width="704" height="540" alt="image" src="https://github.com/user-attachments/assets/acfc474e-fa03-4ff5-8ab1-52070619d78f" />
This update prevents the editor’s command menu from opening when an emoji shortcut is used, avoiding unexpected popups while typing. It also makes emoji shortcuts work more reliably within a paragraph, improving the typing experience for users.
Original PR description
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler`…
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening. - Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position. - Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line. #### Desired behavior after PR is merged: - Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox. - Emoji shortcuts now works when used with a preceding space anywhere in the paragraph. Enterprise PR-https://github.com/odoo/enterprise/pull/118310 task-6243724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266284
This update corrects how two guided features simulate user actions, so they now behave more like a real user. As a result, Knowledge tours and Studio interactions work reliably again and no longer fail because of missing or incorrectly handled input steps.
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 update improves the error shown when a Point of Sale database transaction fails. Instead of a generic message, users and support teams now see the real underlying error, making it easier to understand and troubleshoot issues.
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
The UNSPSC code for organic fertilizers and plant nutrients (10171500) is now available again in the product classification list. This ensures users can correctly categorize these products in Accounting settings without missing a valid code.
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
A test failure was resolved by removing a dependency on an outdated module. This change streamlines the process of retrieving project information within the planning_field_service_sale_timesheet module, aligning it with new billing features for field service. This ensures the core functionality continues to operate correctly.
Original PR description
Currently, running test `test_fsm_flow` leads to a Attribute Error: `planning.slot' object has no attribute 'project_id'`. This happens because project_id field removed in this PR: https://github.com/odoo/enterprise/pull/113153 This field is removed to remove `project_timesheet_forecast_sale` module in the dependencies of `planning_field_service_sale_timesheet` module and add a project field in settings of planning when Billing feature of field service is enabled. Related PR: https://github.com/odoo/enterprise/pull/83012 runbot-[941219](https://runbot.odoo.com/odoo/error/941219)
This update resolves a technical issue where Chrome browsers were unable to properly display audio previews within the Documents app. The fix blocks audio file previews by default, aligning with our strategy to avoid using Odoo Enterprise as a media streaming platform. This ensures consistent functionality across browsers.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a sound file (mp3 for example, but the behavior is the same for other formats) - Share the document and copy the link - Log out - Paste the…
**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```
**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).
This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.
**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).
(Note: we don't want to be used as a media streaming platform)
[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe
opw-6235043
Forward-Port-Of: odoo/enterprise#119644This update fixes a potential issue where cron jobs in the accounting module could incorrectly record progress even when errors occurred. Now, progress is only tracked when a job completes successfully or when a specific error is handled. This enhances the reliability and accuracy of automated accounting processes.
Original PR description
The previous fix commits progress even when an unexpected exception escaped the loop iteration when _autopost_draft_entries. Now progress is only committed on success or when a UserError is explicitly handled. Reference: https://github.com/odoo/odoo/pull/271509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273115
This update resolves an issue preventing POS managers without administrative rights from modifying POS configurations, specifically background images. The fix removes a restriction that blocked access to attachments created by other users, allowing managers to make necessary changes. This improves usability and simplifies POS management workflows.
Original PR description
When editing a POS config, `_ensure_public_attachments` wrote `public=True` on the self-ordering background/home images on every write. These images are Many2many attachments created with a `res_model` but no `res_id`, so the attachment access check denies write to any non-system user who is not their creator.
As a result, a POS manager without Settings/Admin rights could not edit a config whose images were uploaded by another user (e.g. an admin during setup), getting:
AccessError: Sorry, you are not allowed to access this document.
(Operation: write) - Records: ir.attachment(...), User: ...
Steps to reproduce:
1. Enable self-ordering on a POS and select a background image
2. Set self-ordering back to disabled
3. Log in as a POS admin without Admin/Settings rights
4. Try to edit the POS -> error
opw-6331261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273299This update resolves an issue where header text on mobile was too dark against the background, making it difficult to read. The fix corrects a conversion error that prevented the correct CSS from applying to the header, ensuring optimal color 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 resolves an issue where users could select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer dropdown, ensuring users only see customers from their assigned company. This improves data accuracy and prevents incorrect customer assignments.
Original PR description
Steps to reproduce: - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - Customers from other companies are visible in the customer field, Cause: - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - Added a domain on partner_id in the ticket quick create form view. task-4971466 Forward-Port-Of: odoo/enterprise#122358 Forward-Port-Of: odoo/enterprise#121944
This update ensures that private tasks cannot be used as parents for other tasks. Previously, this could lead to confusion and inconsistencies in task management. This change improves clarity and simplifies the process of creating and organizing tasks within the system.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#272263 Forward-Port-Of: odoo/odoo#270795
This update resolves a warning that appeared during product category imports when the system used the full category name for searching, leading to multiple matches. This issue was introduced in a recent update and is now corrected, ensuring smoother and more reliable product category imports. It prevents import failures due to duplicate category names.
Original PR description
When trying to import Product Categories, importing the Parent Category may raise blocking warnings. Steps to reproduce: - Open Sales > configuration > Categories - Import records - Select a file containing the parent category name - Import category name and parent category Issue: A warning will raise Found multiple matches for value "Furniture" in field "Parent Category" (2 matches) It occurs because, while searching by name, the system will use the complete name of the category so it will match multiple times the same name. This behaviour has been introduced in https://github.com/odoo/odoo/pull/236067/changes/0f788b8105c715681d67fdac04fa82c4c4d48e5e opw-6283004 Forward-Port-Of: odoo/odoo#273147 Forward-Port-Of: odoo/odoo#271862
This update corrects a bug where users were incorrectly suggested as recipients after unfollowing a record in the chatter interface. The fix ensures that the user is no longer added to the suggested recipient list unless they re-follow the record, improving the user experience and preventing unnecessary notifications. This resolves a technical issue related to how suggested recipients are generated.
Original PR description
### Steps to reproduce: - Open any mail thread in chatter - Click the "Send To" button once - Click "Unfollow" - You will be a suggested recipient ### Cause of Issue: The suggested recipient generation did not filter out the current user. When the user unfollows, `_message_get_suggested_recipients` is called when storing the thread, and since the user is no longer on the followers list, they get added back as a suggested recipient. https://github.com/odoo/odoo/blob/b4c7247ff218fb850fd91af3e2baa726a82d439c/addons/mail/models/models.py#L467-L468 ### Fix: Since followers are excluded from suggested recipient candidates in the mail thread, and the current user should be excluded when they unfollow, the current user is excluded altogether. This means the current user will not be suggested as a recipient again unless they re-follow the record. opw-6122351 Forward-Port-Of: odoo/odoo#269611
This update fixes an issue where the activity counter in the Odoo interface was displaying incorrect values, sometimes going negative. The fix ensures the counter accurately reflects the number of outstanding activities, improving the user experience and data accuracy. The change was made to simplify the process and avoid complex server-side modifications.
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
The barcode scanner feature in our web application was experiencing an issue in the latest Brave Browser version. Specifically, the video preview would stop after the first scan. This update automatically restarts the video preview after a pause, ensuring a smooth scanning experience for users in Brave.
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 an issue where thread messages were not displaying correctly due to a technical problem with how the system tracked loading states. The fix ensures that thread messages are reliably rendered, improving the user experience when viewing conversations. This was a bug related to how the system monitored and updated the loading status of threads.
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
A test related to subscribing to the bus service was intermittently failing due to changes in how events are processed. This fix ensures the test consistently passes by ignoring the specific order of events, as the underlying functionality remains unaffected. This improves test reliability without altering core functionality.
Original PR description
Since [1], the `re-subscribe on reconnect` bus test has been failing intermittently. This is because that PR reduced `OUTGOING_BATCH_DELAY`, which is a good change since it speeds up the tests, but…
Since [1], the `re-subscribe on reconnect` bus test has been failing intermittently. This is because that PR reduced `OUTGOING_BATCH_DELAY`, which is a good change since it speeds up the tests, but it also makes the ordering of some events non-deterministic. In this particular case, the test expects the client to receive a `BUS:RECONNECT` event before the worker sends the `subscribe` request to the server. However, there is no guarantee which one will be observed first by `expect.step`: - `_sendToServer` is debounced. - Messages sent to the client pass through several asynchronous stages, such as the message port and event dispatching. In practice, the ordering does not matter as long as both events occur. This commit adds the `ignoreOrder` option to the `waitForSteps` call. [1]: https://github.com/odoo/odoo/pull/272199 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
This update resolves a technical problem where internal naming conventions within the Web Studio module were generating incorrect names. The fix ensures these names are properly formatted, preventing potential issues with system functionality. This change improves the stability and reliability of the Web Studio application.
Original PR description
The PR #119993 introduced a bug leading to technical names being named `x_studio_<type>_NaN`. This commit fixes the issue. A `_NaN` increment is only possible if the increment reach int max size. task-6353814
This update resolves a bug where the HR contract salary tour test failed when only the core HR contract salary app was installed. The fix ensures that the necessary Belgian payroll data (NISS) is correctly displayed, preventing the test from incorrectly searching for missing information. This improves the reliability of the tour test and ensures proper setup for Belgian employees.
Original PR description
[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config
Bug reproduction:
1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour
2 - When only single app is installed without installing l10n_be_hr_contract_salary, the tour test fails
Bug cause:
1 - When the employee's company's country is belgium we were showing NISS instead of identification number.
2 - But NISS field is appended in l10n_be_hr_contract_salary and if you do not install, there is no identification number and NISS.
3 - That's why the test fails (it looks for identification number or NISS but none of them is there)
Bug solution:
1 - I moved the code of hiding identification number or hiding NISS to the l10n_be_hr_contract_salary. So, when only hr_contract_salary is installed, identification number field won't get hided.
task - 6333129
runbot error link: https://runbot.odoo.com/odoo/error/941044This update resolves a technical issue that caused an error when deleting a newly created receipt. The problem stemmed from how the status bar displayed information, specifically when no item was selected. This fix ensures the status bar functions correctly during receipt deletion, preventing the error and improving overall stability.
Original PR description
# How to reproduce - Create a new Receipt - Save - Delete the new Receipt # The issue A traceback is shown : `TypeError: Cannot read properties of undefined (reading 'label')` # Cause This is caused…
# How to reproduce - Create a new Receipt - Save - Delete the new Receipt # The issue A traceback is shown : `TypeError: Cannot read properties of undefined (reading 'label')` # Cause This is caused by the custom status bar for pickings `StockPickingLockedStatusBarField`. In its template, we replace the display of the current label : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L20-L23 https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.xml#L4-L9 The issue is that the base implementation of the current label properly handles the case were no item is currently selected: https://github.com/odoo/odoo/blob/7630f8fe2d5198b7a1ed538241795dc26a497fa0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L298-L300 But the picking implementation does not : https://github.com/odoo/odoo/blob/490c355ae0bc77c1106e22b3afb2206583980324/addons/stock/static/src/fields/stock_picking_locked_statusbar_field.js#L12-L14 And it seems that the template is quickly rendered without any selected item before deletion. opw-6345192 Forward-Port-Of: odoo/odoo#273184 Forward-Port-Of: odoo/odoo#273030
This update ensures that quality checks are automatically deleted when multiple manufacturing orders are merged. Previously, these checks remained active on cancelled orders, causing confusion and unnecessary reporting. This change streamlines the process and provides accurate quality check information.
Original PR description
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that…
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that product - Create and confirm multiple Manufacturing Orders - Verify that each MO generates a quality check - From the MO list view, select the MOs and merge them from the gear menu(merge) Issue: ------ When Manufacturing Orders are merged, All MOs are cancelled but it keep their quality checks in the 'To Do' state. As a result: - The quality checks remain linked to cancelled MOs - The 'Quality Checks' smart button is still displayed on cancelled MOs Expected behavior: ------------------ - Pending quality checks should be deleted when the MO is cancelled - The 'Quality Checks' smart button should no longer be displayed Cause: ------ A previous fix introduced logic to remove pending quality checks when a Manufacturing Order is cancelled: odoo-dev@db93bd2 This logic was implemented in `action_cancel()` by unlinking quality checks associated with the cancelled MO: https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97 However, when MOs are merged, the merge flow does not call `action_cancel()`. Instead, it directly invokes `_action_cancel()` on the source Manufacturing Orders: https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480 Since the quality check cleanup is implemented only in `action_cancel()`, it is bypassed during the merge process. As a result, the source MOs are cancelled but their pending quality checks remain in place. --- opw-6260735 Forward-Port-Of: odoo/enterprise#121809 Forward-Port-Of: odoo/enterprise#119525
This update ensures that VAT displayed on exported invoices is correctly translated into the customer's chosen language, rather than the user's. Previously, invoices were defaulting to the user's language, even when the customer had selected a different language. 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 corrects a visual issue in the POS control panel. Previously, a split button was always displayed, even when bill splitting was disabled within the restaurant module. This change ensures the button is only visible when bill splitting is enabled, improving the user experience and preventing unnecessary options from being shown.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268718 Forward-Port-Of: odoo/odoo#266654
This update fixes an issue where the number of expenses linked to a sales order was inaccurate, leading to a confusing smart button experience. The change now correctly counts *all* expenses associated with a sales order, ensuring the button displays the accurate number of expenses and provides consistent data.
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 occasionally caused errors in the processing of French tax (VAT) reports. The fix ensures that a specific database query is handled correctly, preventing it from failing when a particular date value is missing. This improves the reliability of the French 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
This update fixes a visual inconsistency in Odoo's boolean fields, aligning the button styling with the previous MyLabs3 (M3) design. It also addresses a usability issue on touch devices by removing a hover effect that caused unintended activation. This ensures a more 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 Forward-Port-Of: odoo/odoo#273645
Features or functions removed from Odoo
This change removes an outdated Hong Kong HSBCNet module that had already been cleared out internally but still existed as an empty leftover file. It helps keep the codebase clean and avoids confusion about a module that is no longer in use.
Original PR description
The contents of this file were previously deleted, but the file itself was missed, leaving a dead l10n_hk_hsbcnet module in 19.4. This commit removes the file entirely to clean it up.