Thursday, July 10, 2025
24 changes · saas-18.3
Enhancements to existing features
Tax-related test helpers were moved into a shared invoicing test setup so they can be reused across accounting test areas. This reduces duplicate test code and helps keep tax behavior checks more consistent, with no expected direct impact on daily users.
Original PR description
…tInvoicingCommon --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217767 Forward-Port-Of: odoo/odoo#215588
The POSBox homepage now shows clearer database connection actions by renaming the disconnect button and hiding new database setup when one is already configured. This reduces on-screen clutter and makes the connection status easier for users to understand.
Original PR description
We renamed the "Disconnect from current" button to "Disconnect", and removed the possibility to configure a new database if one is already configured. This eases user experience, by reducing the amount of information on the screen. Task: 4922634 Forward-Port-Of: odoo/odoo#217706
Resolved issues and error corrections
This fix updates website shop tests so old demo sales data does not interfere with the expected results. It helps keep automated checks stable when demo data is installed, reducing false failures during release validation.
Original PR description
Archive previously sold products to make sure they do not make the test fail when demo data are installed. runbot build error 163667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close produ
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [1]: 10ed12241365942914885dff953049303b9ed94f Enterprise: https://github.com/odoo/enterprise/pull/86905 opw-4800147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215223 Forward-Port-Of: odoo/odoo#212885
The mail app test was updated so adding the same emoji reaction twice correctly checks that the reaction is removed. This prevents intermittent test failures and helps keep message reaction behavior consistent and reliable.
Original PR description
Before this commit, test "Add the same reaction twice from the emoji picker" may fail non-deterministically in 18.1 on last step: the message reaction is sometimes kept, sometimes removed. The feature in 18.0 was keeping the emoji, whereas in 18.1 it now toggles the add / remove of reaction. This change of behaviour felt best with the addition of QuickReactionMenu, and for consistency this also works that way in emoji picker of message reaction. The test was not adapted but passed because the bus notifications were coming later than the burst of user actions to add emoji, thus there's flicker of showing message reaction at end when it's only temporarily and would be removed a fraction of seconds later. This commit fixes the test with the newer behaviour that it should toggle the reaction. Fixes runbot error 229340 Forward-Port-Of: odoo/odoo#218160
This update fixes an unreliable automated test in the HTML editor related to link popovers. It helps keep development and release validation more consistent by reducing false test failures, with no expected change for end users.
Original PR description
The fix at [1] did not fix the issue. This is another attempt. runbot-227759 [1]: https://github.com/odoo/odoo/pull/215168/commits/9a3c9ecca14fb8701e4f934cf5285297cbe26310 Forward-Port-Of: odoo/odoo#218114
Manufacturing users can once again update multiple work orders at the same time from the list view. This fixes an accidental restriction and helps teams make routine production updates more efficiently.
Original PR description
Multi-edit was disabled from the WO list view by mistake in commit: https://github.com/odoo/odoo/commit/5767cf0c0cbf2a4130430cd92a3cba8891b84510 Therefore, it has been re-enabled. Task: 4900236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Products configured to keep selling when out of stock now correctly show as available for regular delivery options. This prevents customers from seeing an incorrect unavailable message when pickup in-store is also enabled.
Original PR description
Steps to reproduce: 1) Configure a product and allow selling when out of stock 2) Publish any delivery method 3) Publish the Pickup in-store delivery method 4) Check the product page of the created product Problem: It is shown that the product is not available for delivery even though we allow selling it when out of stock This commit shows that a product is available for delivery (not for in_store one) if allow selling when out of stock is enabled. opw-4792024
This fix adjusts the two-factor authentication login flow tests so they only wait for a page unload when the login form is no longer present. This reduces false test failures and helps keep the login and portal sign-in experience stable.
Original PR description
In this commit, we change the login page step by a step with isActive property. So this step is only active when the input#login is not on the page and then expectUnloadPage will be only listen when this step is active. 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#217972
This fix makes public discussion tests wait until a newly posted message is fully saved before trying to add a reaction. It prevents intermittent failures in automated checks, improving release reliability without changing the user experience.
Original PR description
Before this commit, tour "test_discuss_channel_public_page_as_guest" would crash in test after posting a message in which we attempt to add a reaction. This happens because the step is a `hover &&…
Before this commit, tour "test_discuss_channel_public_page_as_guest" would crash in test after posting a message in which we attempt to add a reaction. This happens because the step is a `hover && click 'Add a reaction'`, so it hovers on selector `o-mail-Message:contains(cheese)` then clicks on the 'Add a reaction' action. In discuss channels, when sending a message, the message is immediately shown on UI before there's a genuine message that is created in DB. This optimistic behavior gives impression the app is fast, but some actions require a genuine message like 'Add a reaction'. The problem of test is that selector `.o-mail-Message:contains(cheese)` passes with temporary / transient message of optimistic behavior, so the `hover` step would be triggered on the temporary / transient message and 'Add a reaction' action is awaited for click. Problem is that when genuine message data is received, implementation detail deletes the temporary / transient message and then shows the genuine message. Because the genuine message is different, component identity is different (it uses message.localId in `t-key`), thus it awaits `Add a reaction` on UI but it's not visible because we need to hover again, this time on genuine message. This commit fixes the issue by awaiting message is shown on UI is the persistent, i.e. non-temporary and non-transient, so that hover and click on the 'Add a reaction' action works without issue. fixes runbot errors 181660 fixes runbot errors 222093 fixes runbot errors 227756 Forward-Port-Of: odoo/odoo#218053 Forward-Port-Of: odoo/odoo#217982
User presence updates now avoid changing the user's last modified date. This prevents routine logins or activity status changes from making user records appear recently edited when no profile information actually changed.
Original PR description
Before this commit, when user presence changes, it was updating the write_date of user. This happens because any change of presence what doing a `Command.create()` on the presence_id field of user model. The presence object is automatically unlinked after 12 hours of inactivity, thus most users had their write_date changed every day because of the presence_ids being updated when logging in at least once a day. This commit fixes the issue by creating the presence rather than write on the user field, so that this is not considered a write on user object and thus it doesn't change the write_date of user. Other than not updating the write_date, the code behavior is functionally unchanged. Forward-Port-Of: odoo/odoo#218182
The E-Waybill report option is now only shown after an E-Waybill has been successfully generated. This prevents users from accidentally printing an unavailable report and encountering an error during invoice processing.
Original PR description
Currently, an error occurs when users print the E-Waybill without generating it. Steps to replicate: - Install `l10n_in_ewaybill` and switch to IN company. - Change the `Zipcode` on IN company to…
Currently, an error occurs when users print the E-Waybill without generating it. Steps to replicate: - Install `l10n_in_ewaybill` and switch to IN company. - Change the `Zipcode` on IN company to `aa`. - Go to `Invoicing > Customer > Invoices`. - Create an invoice, confirm and click Send E-WayBill. - Click on the Gear icon and Click on the report `Ewaybill`. Error: `ValueError: invalid literal for int() with base 10: ''....` `QWebException: Error while render the template ValueError: invalid literal for int() with base 10: '' Template: ir.ui.view(2614,) Path: /t/t/t/t/div/t[3] Node: <t t-if='doc.state in ewaybill_states'/>` The error occurs because the report printing is available even when the `E-Waybill` is not yet generated. This causes the execution flow to skip all the necessary validations, leading to a `ValueError` at line [1]. [1] - https://github.com/odoo/odoo/blob/aa7dac87a3eebce1b300e1e3d04398d680325b5d/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py#L640 This commit solves this issue by adding a domain to the report, so that it appears only after the EwayBill is generated. sentry-6695761066 https://github.com/user-attachments/assets/81e5a8eb-4c0c-4dc5-a65b-e22bc11098d2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215515
Mobile dialog headers no longer use back-end theme colors that could appear unexpectedly on website pages. This keeps front-end popups visually consistent with the current design and avoids confusing branding differences for visitors.
Original PR description
Before this PR: header color of `Dialog` on mobile was "community color" or white, depending on the version of Odoo the database is running. This was creating issues in in the front-end, where the user of the website would see back-end specific colors in different `Dialog`s. This PR removes the color customization of `Dialog`'header as it was fitting a design line we had before we introduced MILK. task-4001365 Example of the issue (mobile front-end): <img width="376" alt="Screenshot 2024-06-20 at 10 54 04" src="https://github.com/odoo/odoo/assets/110090660/dad6a4b2-6164-45dd-9e16-0160e2989607"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170087
The font size input in the HTML editor now uses the correct text color when dark mode is active. This improves readability and gives users a more consistent editing experience in dark-themed interfaces.
Original PR description
Purpose of this PR: - Backport a [PR #206008](https://github.com/odoo/odoo/pull/206008), which ensures that the font-size input now changes its color appropriately in dark mode. task-4897771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215865
This fixes an intermittent failure in an automated website live chat test by waiting for the chatbot's delayed response handling to actually complete. It helps keep release validation more stable without changing the live chat experience for customers.
Original PR description
Before this commit, the `website_livechat_chatbot_flow_tour` tour was sometimes failing. The intent it to ensure the chat bot stops until the user fully wrote his answer. The flow is the following: -…
Before this commit, the `website_livechat_chatbot_flow_tour` tour was sometimes failing. The intent it to ensure the chat bot stops until the user fully wrote his answer. The flow is the following: - User sends a message (first part of his answer) - User starts typing: the chat bot waits - After some time, the user didn't finish his answer afterall, the chat bot continues. The chat bot uses the `_processAnswerDebounced` function to delay the processing of the step. However, the tour relies on `setTimeout`, expecting to come after the debounce delay. However, multiple messages are sent, and the debounce delay is postponed. As a result, the assertion is made too early, making the test fail. This commit fixes the issue by awaiting a deferred, resolved when the chat bot actually executes the debounced function. fixes runbot-113948,227675 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#218153
This fixes an intermittent issue in an automated mail test where the form could still be saving after a message appeared. The test now waits for the save to finish, reducing false failures in validation pipelines without changing user-facing behavior.
Original PR description
Before this commit, tour "test_mail_composer_autosave_tour" could fail at end with the following error: ``` Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies. ``` This happens because test creates a new record and posts a message in full composer. It checks that message is present in chatter and then leave the form view. When posting the message, the form view is saved, but this can happen with a small delay after message is visible on chatter like after tour has ended. This commit fixes the issue by awaiting form view is saved, so that tour doesn't panic at end there's a form view with unsaved changes, as the form view is properly saved with sending a message. Fixes runbot error 198583 Fixes runbot error 222676 Fixes runbot error 226772 Fixes runbot error 222676 Forward-Port-Of: odoo/odoo#218145
This fixes a small display issue in the HTML editor where the remove icon for media dialog attachments could be hidden. Users can now reliably see and use the icon when managing attachments.
Original PR description
Description of the issue this PR addresses: - The remove icon in the media dialog attachment was not visible due to the use of an invalid `z-index-1` class. This commit c5a98c76ea1cce4acb55faf4768388b94255508f removed custom `z-index` utilities. Replaces `z-index-1` with Bootstrap's default `z-1` class. Before this commit: - The icon used `z-index-1`, which is not a valid Bootstrap class. After this commit: - Replaced with `z-1`, the correct Bootstrap 5 utility class for `z-index: 1`. task-4903381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216261
The VoIP softphone now uses a clearer minimize icon instead of a minus icon. This aligns the interface with designer feedback and makes the control easier for users to recognize.
Original PR description
Following feedback from the designers.
This fix makes shop floor automated tests more reliable by avoiding assumptions about the exact number of records shown. It prevents unrelated demo data from causing false test failures, helping keep build validation stable without changing user-facing behavior.
Original PR description
### Issue: Certain shopfloor tests make assert on the number of records present in the shopfloor: - test_shop_floor_my_wo_filter_with_pin_user - test_automatic_backorder_no_redirect These assert can not be reliable due to demo-data's adding unrelated records e.g. https://github.com/odoo/enterprise/blob/5bfadae317ee47ac34703d4cc222677ac677cc7d/purchase_mrp_workorder_quality/data/purchase_mrp_workorder_quality_demo.xml#L79-L84 runbot-build-error-226734 Forward-Port-Of: odoo/enterprise#89556 Forward-Port-Of: odoo/enterprise#88005
Amazon order shipping now correctly recognizes DPD, Hermes, and the renamed Royal Mail carrier values used in the UK. This helps prevent carrier-matching errors when Sendcloud provides those delivery services.
Original PR description
For DPD and Hermes (not the others), Sendcloud adds an unnecessary ISO code. In order to keep it should it be necessary (e.g. rml_gb), we map them to the Amazon const instead of stripping the code. While testing, it was also found that royal mail seems to have been renamed and was thus not working. Forward-Port-Of: odoo/enterprise#87745
This fix prevents users from opening Odoo Studio on the Bank Reconciliation screen. It avoids unsupported customizations in a sensitive accounting workflow, reducing the risk of accidental configuration issues.
Original PR description
- Install `web_studio` and `account_accountant` - Open Accounting -> Bank You can open studio on this view but this should not be possible opw-4859464 Forward-Port-Of: odoo/enterprise#89181 Forward-Port-Of: odoo/enterprise#89146
This fixes an issue where payment references ending with a backslash could cause bank reconciliation matching to fail. The change helps accountants process affected payments without query errors during reconciliation.
Original PR description
If a payment ref end with '\\', this '\\' will be interpreted as an escape operator in the query, which leads to an error. This commit add the '\\' to the list of char to escape. no-task
PDF reports generated from Studio now show table headers in bold as intended. This makes printed stock reports match their on-screen formatting and improves readability for users.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380 Forward-Port-Of: odoo/enterprise#89836 Forward-Port-Of: odoo/enterprise#87852
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be m
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#88165 Forward-Port-Of: odoo/enterprise#86905