Daily updates from Odoo
Wednesday, October 1, 2025
116 changes
21 changes
Resolved issues and error corrections
Free products added through sales loyalty rewards now use the reward description as the order line name instead of the product’s default name. This makes sales orders clearer and keeps the behavior consistent with point of sale rewards when teams customize reward descriptions.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#229152 Forward-Port-Of: odoo/odoo#223755
The cohort report export button is now disabled when there is no data to export. This prevents users from triggering an error on empty reports, such as Helpdesk Ticket Analysis without records, and provides a smoother reporting experience.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426 Forward-Port-Of: odoo/enterprise#93050
Customers viewing an online order that includes a manufactured product will now see the manufacturing date only once. This keeps the order portal cleaner and avoids confusion caused by repeated information.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009** Forward-Port-Of: odoo/odoo#227997
Saving a view or editing a report with an attribute tag missing its name no longer triggers an unexpected error. The system now skips these incomplete attributes safely, improving stability for users working with views or Web Studio reports.
Original PR description
Currently, an error occurs when user tries to save a view with an attribute node without name. **Steps to replicate:** - Initialize a DB and open Views. - Create a new view and fill in random values…
Currently, an error occurs when user tries to save a view with an attribute node without name.
**Steps to replicate:**
- Initialize a DB and open Views.
- Create a new view and fill in random values for name and give a View Type.
- In the Architecture give value as `<attribute></attribute>`.
- Save and you will get the error.
(Same error can also be produced with Web Studio report editor.)
**Error:**
`AttributeError: 'NoneType' object has no attribute 'endswith'`
**Cause:**
- The error occurred because we received **key** as `None` at [1], as it was called from an attribute node with no name [2].
- In `saas-18.2`, we only checked if `node.get('name') not in TRANSLATED_ATTRS`. Since `node.get('name')` was `None` and `None` was not included in the `TRANSLATED_ATTRS` list, no error occurred.
**Solution:**
- Added a conditional check, so that attributes with no name skip the function call.
[1]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L83
[2]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L190
[3]: https://github.com/odoo/odoo/blob/0b700ec3c08ecd9c6f1597f9d10f6c1eee06bcee/odoo/tools/translate.py#L255
sentry-6877030439
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227221Swedish payment export files now identify bankgiro accounts with the correct account type instead of treating them as standard bank accounts. This helps Swedish credit transfer files meet banking requirements and reduces rejected or incorrect payments.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
The online shop now handles invalid category values in product page URLs more gracefully. Instead of triggering an unexpected server error, it returns a clearer validation message, improving reliability when links are mistyped or tampered with.
Original PR description
Currently, an error occurs when the `category` is received as a `string` and the code tries to evaluate `int(category)`. **Steps to reproduce:** - Install the `website_sale` module. - Open a product page in the website with an `invalid category` parameter, for example: `http://localhost:8069/shop/warranty-39?category=1;` **Error:** `ValueError: invalid literal for int() with base 10: '1;'` **Root Cause:** At [1], the code directly calls `int(category)` without validating the input. When the parameter contains `non-numeric` characters, Python raises an `error`. **Fix:** This commit ensures raising a `ValidationError`, improving the `error message` clarity, when users manually input `invalid or tampered` category values in the `URL`. [1]: https://github.com/odoo/odoo/blob/d32f98dd199f80d2b0031bd52a6ff74411c3e7e0/addons/website_sale/controllers/main.py#L1827 sentry-6658317828 Forward-Port-Of: odoo/odoo#226207
Nuvei payments no longer fail when a customer has a first or last name longer than Nuvei allows. The payment details are shortened automatically to meet Nuvei's limits, helping customers complete sales orders without errors.
Original PR description
Steps: - Install sales and payment Nuvei. - Set up payment Nuvei. - Set customer long name and last name. - Try to pay that SO with Nuvei. Issue: - Error. Cause: - Nuvei only accept 30 character for first_name and 40 for last name Fix: - Truncate first and last name to only take required character. opw-5083827 Forward-Port-Of: odoo/odoo#227191
The project dashboard now clearly prevents editing milestone quantity percentages when there is no linked sales order line. This avoids confusing behavior and helps users understand when milestone billing values can be changed.
Original PR description
**Steps to Reproduce:** - Install sale_project. - Go to the project dashboard. - Click on Edit milestones. **Isuue:** When a sales order line exists, the quantity percentage can be updated. When no sales order line exists, the quantity percentage cannot be updated. **Fix:** Make the field readonly when no sales order line is linked. task-5068312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227922
A test for the HTML editor was updated to wait properly for the toolbar before continuing. This reduces intermittent automated test failures, helping keep releases and validation pipelines more reliable without changing user-facing behavior.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090 Forward-Port-Of: odoo/odoo#227989
The mobile chatter now keeps the send button visible when users edit a message, preventing confusion and failed attempts to finish edits. The discard option has also been moved above the composer, making the editing controls clearer and easier to use on small screens.
Original PR description
**Purpose of this PR:** This PR addresses UI issues in the mobile view of the chatter during message editing. - Ensures the send button is properly displayed while editing messages on mobile. - Moves the "Discard Editing" action above the composer. **Before this PR:**  **After this PR:** <img width="446" height="132" alt="image" src="https://github.com/user-attachments/assets/1842f341-268a-40e3-8915-dc08fb9162b3" /> task-[4780731](https://www.odoo.com/odoo/project/1519/tasks/4780731) Forward-Port-Of: odoo/odoo#213943
Animated text and other elements in website footers now appear correctly when the footer is configured to slide over the page. This fixes a display issue where those animated elements could remain hidden while visitors scrolled, improving the reliability of website presentation.
Original PR description
Before this commit, using animation on text within the footer elements would not work if the footer was set on "slide over". The formula used to compute when to start the animation was incorrect. This commit fixes the formula. Steps to reproduce: - Set the Footer slideout to "Slide Over" - Set the Animation of an element to "On Appearance" - Save (when scrolling down, the animated element stay hidden) Forward-Port-Of: odoo/odoo#226562
This fix ensures the IoT Box browser keeps using the web address set in its configuration file, even after orientation settings are saved. This prevents the browser from unexpectedly reverting to an older database-stored page after reopening or rebooting.
Original PR description
The browser on the IoT Box was always reopening on the url saved in the database instead of the one saved in odoo.conf. When opening the browser, we used to set the orientation and save it in the configuration. As we only set the orientation and not the url at this point, we were mistakenly removing the url from odoo.conf. As it was not set anymore, when reopening the browser later (e.g. after reboot), no url was available in conf, so we fell back on the db's one. Task: 5103536 Forward-Port-Of: odoo/odoo#229002
This fixes an internal purchase and inventory test so it works reliably even when localization settings change the default product type. It helps prevent false test failures and keeps purchase stock validation stable across module combinations.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228583 Forward-Port-Of: odoo/odoo#221042
The HTML editor toolbar now correctly disables the link button when users select table cells, preventing unsupported link actions on cell selections. It also improves single-cell selection behavior so a cell is only selected when its full content is selected, making table editing more predictable.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select first column. The link button in toolbar is enabled and it should not. This happens because after merging this commit [1], `isLinkAllowedOnSelection` method returns true if selected cells are not adjacent. **Desired behaviour after PR is merged:** Now, selecting cells open toolbar with disabled link button. [1]: https://github.com/odoo/odoo/commit/c0d07fdcf4cc139177524eb4ea22ab341b3da7fb task-4965270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when Odoo runs on Arch Linux systems where a standard operating system detail is not provided. It improves reliability for deployments on Arch Linux without changing business workflows or user-facing features.
Original PR description
The `platform.freedesktop_os_release()` function returns the content of the `/etc/os-release` file as a `dict[str, str]`. The entry `ID` is the name of the OS (`linuxmint` on Linux Mint) and `ID_LIKE` is the name of the OS `ID` is derived from (`ubuntu debian` on Mint). In ArchLinux the `ID` is `arch` and `ID_LIKE` entry is missing. Reported-By: Muhammad Al-Habib Ouadhour <houadhour@yandex.com> 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
Project-related guided walkthroughs now handle cases where the New button opens a template selection menu instead of directly opening the creation form. This prevents setup walkthroughs from failing when project templates are present, making onboarding and demos more consistent.
Original PR description
Before this commit, the project tours could fail at the project creation step because the 'New' button might open a dropdown menu instead of the project creation form, depending on whether project templates exist in the DB or not. After this commit, we add a conditional step to handle that case. version: saas-18.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
The chatter follower menu now stays open after removing a follower, making it easier to remove several followers in one session. The subscription edit action now closes the menu as expected, creating a more consistent user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Removing multiple followers from the chatter is cumbersome because the followers dropdown closes immediately after each removal. Additionally, clicking 'Edit Subscription' next to 'Unfollow' did not close the dropdown, which was inconsistent with expected behavior. **Current behavior before PR:** --------------------------------- - Removing a follower from the chatter closes the followers dropdown immediately - Clicking 'Edit Subscription' next to 'Unfollow' leaves the dropdown open **Desired behavior after PR is merged:** ----------------------------------------- - The followers dropdown remains open after removing a follower, allowing multiple removals without interruption - Clicking 'Edit Subscription' next to 'Unfollow' closes the dropdown as expected **Task:** 4943867 Forward-Port-Of: odoo/odoo#222154
This update corrects a sales test so it checks the currently configured order confirmation email template instead of assuming a fixed one. This helps ensure partial payment order confirmation works reliably when businesses customize their email settings.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226240
This fixes an issue in the HTML editor where opening the color picker from a link popover could create an extra button and leave preview colors in the wrong state. Users can now adjust or reset button colors without unexpected duplicate buttons or incorrect color previews.
Original PR description
Before this commit: the onchange is applied when the color picker closes, it has a few issues, 1. adding duplicate button cause the reference of the link element is not passed correctly 2. the preview color isn't reset when mouse no longer hovering on the colors After this commit: The onchange is applied when on color reset. No more additional button inserted and color of the button is properly restored after the cursor is out of color picker task-4966317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes incorrect buyer document type values used on Indonesian e-Faktur invoices. It ensures customers marked with Other ID or National ID are reported with the right document label, reducing tax document errors.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222346
22 changes
Resolved issues and error corrections
This update corrects an internal sales and manufacturing test so it reflects that kits can be invoiced before delivery when configured to invoice ordered quantities. It helps keep automated checks aligned with expected business behavior and reduces the risk of false build failures.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796 Forward-Port-Of: odoo/odoo#227870
The website shop now handles invalid category values in product page URLs more gracefully. This prevents a server error when someone opens or tampers with a link containing malformed category information, improving reliability for visitors.
Original PR description
Currently, an error occurs when the `category` is received as a `string` and the code tries to evaluate `int(category)`. **Steps to reproduce:** - Install the `website_sale` module. - Open a product page in the website with an `invalid category` parameter, for example: `http://localhost:8069/shop/warranty-39?category=1;` **Error:** `ValueError: invalid literal for int() with base 10: '1;'` **Root Cause:** At [1], the code directly calls `int(category)` without validating the input. When the parameter contains `non-numeric` characters, Python raises an `error`. **Fix:** This commit ensures raising a `ValidationError`, improving the `error message` clarity, when users manually input `invalid or tampered` category values in the `URL`. [1]: https://github.com/odoo/odoo/blob/d32f98dd199f80d2b0031bd52a6ff74411c3e7e0/addons/website_sale/controllers/main.py#L1827 sentry-6658317828
The chatter follower menu now stays open when a user removes a follower, making it easier to remove several followers in one session. The related edit subscription action now closes the menu consistently, reducing confusion in day-to-day record collaboration.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Removing multiple followers from the chatter is cumbersome because the followers dropdown closes immediately after each removal. Additionally, clicking 'Edit Subscription' next to 'Unfollow' did not close the dropdown, which was inconsistent with expected behavior. **Current behavior before PR:** --------------------------------- - Removing a follower from the chatter closes the followers dropdown immediately - Clicking 'Edit Subscription' next to 'Unfollow' leaves the dropdown open **Desired behavior after PR is merged:** ----------------------------------------- - The followers dropdown remains open after removing a follower, allowing multiple removals without interruption - Clicking 'Edit Subscription' next to 'Unfollow' closes the dropdown as expected **Task:** 4943867
This fixes a crash that could happen in Discuss calls when an update arrived for a session that had already been removed. It improves reliability for users by safely ignoring outdated session updates instead of interrupting the experience.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed. Forward-Port-Of: odoo/odoo#229166 Forward-Port-Of: odoo/odoo#229073
This fixes an issue where packaging details could be missing on products with a single variant. It ensures product packaging information is correctly applied, helping avoid incorrect or incomplete product setup in daily operations.
Original PR description
e158730ba16e898a13dd9a98ed96fa30fa95ab6f recently fixed a situation where one-variant products had duplicated packagings. In the aforementioned commit, we concluded that the logic to write (again) the templates values for variant-stored fields was useless because already applied to the generated variants. Nevertheless, while trying to remove in master this logic, we noticed that those varlues are only applied to variants of templates having at least one attribute line, whose creation will trigger the variants creation. This commit therefore partially reverts the previous commit, bringing back the first solution that is still the best approach in the end. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229080
This fix prevents manufacturing planning from failing when work orders have extremely small duration values. It ensures schedules can still be calculated reliably, avoiding errors that could block production planning.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227253
A website sales test was updated so it prepares price lists before checking GeoIP-based cart pricing. This prevents false test failures in databases without demo data, improving reliability without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a database without demo data; 2. run `test_cart_new_pricelist_from_geoip`. Issue ----- Test fails, due to the order not having a pricelist. Cause ----- Pricelists aren't enabled by default without demo data. Solution -------- Call `self._enable_pricelists()` at the start of the test. runbot-232989
This fixes an issue where highlighted design effects in website page templates could be carried into newly created pages in the wrong internal format. Business users creating new website pages from templates should now see highlights render correctly and consistently.
Original PR description
Starting from [1], the code from the "Snippets Preview" and the "New Page Templates Preview" was adapted to be able to build a highlight using its simplified format when provided in XML. The goal of this PR is to fix the new page DOM when a template with highlights is selected. The DOM will be simply cloned and used for the created page, so we need to reset the inner highlights to their minimal format. [1]: https://github.com/odoo/odoo/commit/4a29fa66003ce1f42a7011bc56fc019f34a887f5 task-4215788 Forward-Port-Of: odoo/odoo#185820
Free products added through loyalty rewards now use the reward description set by the business instead of the product's default name. This makes sale orders clearer and keeps loyalty behavior consistent with point-of-sale flows.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#229152 Forward-Port-Of: odoo/odoo#223755
Users can now create actions in Documents that generate journal entries for journals marked as Credit Card. This fixes a blocker for creating credit card statements through automated document workflows.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868
Swedish Bankgiro accounts are now marked with the correct account type in payment XML files instead of being treated like standard bank accounts. This helps ensure payment files comply with expected banking formats and reduces the risk of rejected or misclassified payments.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
Customers viewing an online order that includes a manufactured product will no longer see the manufacturing date repeated. This keeps the order portal clearer and avoids confusion when checking manufacturing information.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009** Forward-Port-Of: odoo/odoo#227997
This update fixes an unreliable automated test for the HTML editor toolbar by ensuring the toolbar is fully ready before the test continues. It helps keep quality checks stable and reduces false failures during release validation.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090 Forward-Port-Of: odoo/odoo#227989
This fix makes the lot selection field read-only in cases where entering a lot there would not actually apply it to the stock transfer. Users are prevented from thinking a lot was provided when the receipt would still fail validation, reducing confusion in warehouse operations.
Original PR description
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the…
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the move in the picking form - Click Validate #### > Invalid operation: you need to provide Lot/Serial numbers of the product ### Cause of the issue: The set method of the `lot_ids` field of the `stock.move` model does nothing for product tracked by lots: https://github.com/odoo/odoo/blob/7a8f9b7fe4dded4cfa140103d51b52e08149cadb/addons/stock/models/stock_move.py#L575-L579 In particular, while the lot appears on the move in the view, none of the move lines refer to it and the transfer can not be validated as indeed no lots are provided to these reservations. ### Fix: The feature of writing `lot_ids` for lots has been introduced in https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e https://github.com/odoo/odoo/blob/1c52e2e9e8e00a19e2db00bf70d658496f9a0f29/addons/stock/models/stock_move.py#L596-L600 But this major refactoring can of course not be backported in 18.0. Therefore, it was decided put the field in readonly when its set method is inefficient. opw-5093217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228840
This update makes an internal purchase inventory test independent of country-specific settings that could change product behavior. It helps keep automated checks reliable when Kenyan localization modules are installed, reducing false test failures without changing business workflows.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228583 Forward-Port-Of: odoo/odoo#221042
The project dashboard now prevents editing a milestone's quantity percentage when it is not linked to a sales order line. This avoids confusion by making the field clearly unavailable in cases where changes cannot be applied.
Original PR description
**Steps to Reproduce:** - Install sale_project. - Go to the project dashboard. - Click on Edit milestones. **Isuue:** When a sales order line exists, the quantity percentage can be updated. When no sales order line exists, the quantity percentage cannot be updated. **Fix:** Make the field readonly when no sales order line is linked. task-5068312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227922
This fixes an issue where the IoT Box browser could reopen using an outdated page from the database instead of the address set in its configuration file. The browser settings now preserve the configured URL when saving display orientation, helping devices return to the expected page after reopening or rebooting.
Original PR description
The browser on the IoT Box was always reopening on the url saved in the database instead of the one saved in odoo.conf. When opening the browser, we used to set the orientation and save it in the configuration. As we only set the orientation and not the url at this point, we were mistakenly removing the url from odoo.conf. As it was not set anymore, when reopening the browser later (e.g. after reboot), no url was available in conf, so we fell back on the db's one. Task: 5103536 Forward-Port-Of: odoo/odoo#229002
Long category names in the online shop sidebar no longer disrupt the category list layout. This keeps product browsing pages visually consistent and easier to navigate for customers using categories with lengthy names.
Original PR description
__Issue:__ In the product categories sidebar (`#products_grid_before`), nested `<li>` elements could become wider than their parent `<ul>` when the category names were long (e.g., "Untersuchungshandschuhe"). This caused the parent <ul> to expand in height before the child and broke the visual layout. __Fix:__ Force `<li>` elements inside the `#categories_recursive` list to respect their parent width by applying `width: 100%` This keeps the sidebar layout consistent even with long category names. - opw-5075226
This fix prevents subscription invoices from overwriting correct combo section information or adding unnecessary section values. It helps keep invoice lines organized accurately, reducing confusion for customers and sales teams.
Original PR description
This commit improve fix of PR https://github.com/odoo/enterprise/pull/90989 to avoid overriding right combo section values and avoid setting unnecessary values on the section. opw-5069278 Forward-Port-Of: odoo/enterprise#94776
This fixes incorrect buyer document values on Indonesian e-Faktur invoices. Contacts using “Other ID” or “National ID” will now produce the expected document labels, helping avoid invoice reporting mistakes.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222346
This update corrects an internal sales test so it uses the configured sale confirmation email template instead of assuming a fixed one. This helps ensure payment confirmation behavior is tested accurately when businesses customize their email settings.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226240
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
2 changes
Resolved issues and error corrections
The cohort reporting view now disables the download option when there is no data to export. This prevents users from encountering an error in Helpdesk ticket analysis and makes empty reports behave more predictably.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426 Forward-Port-Of: odoo/enterprise#93050
Swedish Bankgiro accounts are now identified with the correct account type in payment files instead of being treated as standard BBAN accounts. This helps ensure Swedish credit transfer files are accepted and processed correctly by banks.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
10 changes
Resolved issues and error corrections
This fix ensures Swedish non-EU purchase VAT with a non-zero amount is correctly included as deductible input VAT. It improves the accuracy of Swedish tax reports and restores related automated checks.
Original PR description
The taxes "EX G" (VAT Purchase of goods outside EU) with a non-zero amount should have the tag se_48 (Input VAT to be deducted). This PR fixes the tests that were broken because of it: odoo/odoo#227513 opw-4916405 Forward-Port-Of: odoo/enterprise#95751
The cohort report export button is now disabled when there is no data to export. This prevents users from hitting an error when downloading empty Helpdesk ticket analysis reports and makes the reporting experience smoother.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426 Forward-Port-Of: odoo/enterprise#93050
Users with viewer access can now mark or unmark documents as favorites using the keyboard shortcut without encountering an access error. This makes the Documents experience more consistent between shortcut-based and manual favoriting.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - Adapted the `toggle_favorited` to handle multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
This update makes a Planning app test more reliable when demo data is present. It clears existing records before counting them, preventing false test failures and helping maintain stable quality checks.
Original PR description
Reason: - In the test case we check for record count, so we get the count of all the demo data installed too. Fix: - Remove all the records before hand to check for the count. https://runbot.odoo.com/odoo/runbot.build.error/231599 runbot-231599 Forward-Port-Of: odoo/enterprise#95736
This fixes an issue in Sales Commission reporting that could prevent grouped report data from being formatted properly. It helps ensure commission achievement and commission reports display reliably for users reviewing sales performance.
Original PR description
runbot-89585061 Forward-Port-Of: odoo/enterprise#95263
A Turkish payroll employee field is now only visible to authorized HR/payroll users. This prevents non-HR internal users from encountering access errors when viewing employee public profile data.
Original PR description
The test test_employee_fields_groups crashed with: AccessError: The fields “l10n_tr_is_net_to_gross”, which you are trying to read, are not available for employee public profiles. This field exist without HR group restriction as a result, a non-HR internal user calling .read([]) triggered the AccessError. This commit adds groups="hr.group_hr_user" to this field so it is only accessible to HR users, resolving the error. [RB-231736](https://runbot.odoo.com/odoo/error/231736) Forward-Port-Of: odoo/enterprise#94796
The timesheet grid now avoids making invalid requests when a row has a project but no task. This prevents errors in timesheet planning views and helps users continue working without interruptions.
Original PR description
If there are rows in the grid view with a project but no task, we call `get_planned_and_worked_hours` on a `False` id, which is not allowed since https://github.com/odoo/odoo/pull/227477
Swedish payment export files now identify Bankgiro accounts with the correct account type instead of treating them as standard BBAN accounts. This helps ensure bank payment files are accepted and processed correctly for companies using Bankgiro accounts.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
The OSS report can now open correctly when a fiscal position uses a country group instead of a directly selected country. This helps businesses handle VAT reporting setups such as mainland Spain excluding the Canary Islands without report access errors.
Original PR description
To be able to deal with Spain with Canary Islands and mainland, we have a country group that is Mainland Spain VAT, with Spain minus several states (Canary basically). People want to be able to use it for OSS. But currently, if you have an entry with a tax with a fp with this country group (and no country), you can't open your OSS Report. So take the countries of the country group if there is none in the fiscal position. Forward-Port-Of: odoo/enterprise#95795
The Sign app’s “Try a sample contract” button now displays with the correct color in dark mode. This makes the empty-screen action easier to read and keeps the interface visually consistent for users.
Original PR description
The "Try a sample contract" button was implemented with the `text-white` class, which is inverted to black in dark mode, making it inconsistent and not very readable. This commit removes that class. task-5129727 __________ | Before | After | |--------|--------| | <img width="488" height="351" alt="Screenshot 2025-10-01 at 13 18 02" src="https://github.com/user-attachments/assets/c5d00f6a-a086-48e2-b0f9-62828e8801e7" /> | <img width="414" height="350" alt="Screenshot 2025-10-01 at 13 17 39" src="https://github.com/user-attachments/assets/f8fc9707-f520-4c6f-838a-59ee77ae9cb9" /> |
31 changes
Resolved issues and error corrections
The customer order portal no longer shows the same manufacturing date twice for made-to-order manufactured products. This keeps the order details clearer for customers and avoids confusion when they review purchases online.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009** Forward-Port-Of: odoo/odoo#227997
The cohort reporting view now disables the download option when there is no data to export. This prevents users from running into an error in reports such as Helpdesk Ticket Analysis when the database has no matching records.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426 Forward-Port-Of: odoo/enterprise#93050
This fixes a crash that could happen when saving a view or editing a report in Web Studio if the view contained an attribute entry without a name. The system now skips those incomplete entries safely, helping users save views without encountering an unexpected error.
Original PR description
Currently, an error occurs when user tries to save a view with an attribute node without name. **Steps to replicate:** - Initialize a DB and open Views. - Create a new view and fill in random values…
Currently, an error occurs when user tries to save a view with an attribute node without name.
**Steps to replicate:**
- Initialize a DB and open Views.
- Create a new view and fill in random values for name and give a View Type.
- In the Architecture give value as `<attribute></attribute>`.
- Save and you will get the error.
(Same error can also be produced with Web Studio report editor.)
**Error:**
`AttributeError: 'NoneType' object has no attribute 'endswith'`
**Cause:**
- The error occurred because we received **key** as `None` at [1], as it was called from an attribute node with no name [2].
- In `saas-18.2`, we only checked if `node.get('name') not in TRANSLATED_ATTRS`. Since `node.get('name')` was `None` and `None` was not included in the `TRANSLATED_ATTRS` list, no error occurred.
**Solution:**
- Added a conditional check, so that attributes with no name skip the function call.
[1]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L83
[2]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L190
[3]: https://github.com/odoo/odoo/blob/0b700ec3c08ecd9c6f1597f9d10f6c1eee06bcee/odoo/tools/translate.py#L255
sentry-6877030439
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227221Opening a Knowledge article activity now shows only the relevant articles with assigned activities instead of the full article list. This helps users quickly find the article that needs their attention and avoids confusion in the activities menu.
Original PR description
Currently, when the user tries to open any activity of the knowledge article, it opens all articles instead of the one which has an activity assigned to them. **Steps to reproduce this issue:** 1) Install the Knowledge module 2) Set up an activity for yourself on a Knowledge article 3) Open the activities from Activities (top left corner) **Issue:** You will end up in the all articles list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied on the view. But in the knowledge article, we don't have any search filters for the activities. Therefore, it renders all knowledge article records. **Solution:** Add search filters for the knowledge articles. opw-4997201 Forward-Port-Of: odoo/enterprise#93609
The website shop now handles invalid category values in product page URLs more gracefully. Instead of causing a server error, it returns a clearer validation message, improving stability when links are mistyped or tampered with.
Original PR description
Currently, an error occurs when the `category` is received as a `string` and the code tries to evaluate `int(category)`. **Steps to reproduce:** - Install the `website_sale` module. - Open a product page in the website with an `invalid category` parameter, for example: `http://localhost:8069/shop/warranty-39?category=1;` **Error:** `ValueError: invalid literal for int() with base 10: '1;'` **Root Cause:** At [1], the code directly calls `int(category)` without validating the input. When the parameter contains `non-numeric` characters, Python raises an `error`. **Fix:** This commit ensures raising a `ValidationError`, improving the `error message` clarity, when users manually input `invalid or tampered` category values in the `URL`. [1]: https://github.com/odoo/odoo/blob/d32f98dd199f80d2b0031bd52a6ff74411c3e7e0/addons/website_sale/controllers/main.py#L1827 sentry-6658317828 Forward-Port-Of: odoo/odoo#226207
The POS now correctly recognizes when a self-order has already been sent for preparation, so the Order button is no longer incorrectly highlighted after loading it. This reduces confusion for staff and helps avoid mistakenly thinking an already-submitted order still needs action.
Original PR description
In the POS UI, the "Order" button was wrongly highlighted when loading a self-order, even though it had already been sent Steps to reproduce: - Create an order using self-order mobile (or kiosk). - Open the related POS terminal. - Load the self-order from the ticket screen. - Notice the "Order" button remains highlighted. Fix: - Ensure the last order changes updated when loading self-order in pos Task: 5005161 Forward-Port-Of: odoo/odoo#229246 Forward-Port-Of: odoo/odoo#223560
Nuvei payments could fail when a customer's first or last name was longer than Nuvei allows. The checkout process now shortens those names automatically so affected sales orders can be paid without error.
Original PR description
Steps: - Install sales and payment Nuvei. - Set up payment Nuvei. - Set customer long name and last name. - Try to pay that SO with Nuvei. Issue: - Error. Cause: - Nuvei only accept 30 character for first_name and 40 for last name Fix: - Truncate first and last name to only take required character. opw-5083827 Forward-Port-Of: odoo/odoo#227191
This update fixes an unreliable automated test for the HTML editor by ensuring the editor toolbar is fully ready before the test continues. It helps prevent false test failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090 Forward-Port-Of: odoo/odoo#227989
The HTML editor now handles tables pasted from tools like ChatGPT when their first row is formatted as a table header. This prevents an error when users delete rows, making pasted table editing more reliable.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Copy a table from chatGPT's response containing first row wrapped in `<thead>`. - Paste it in editor. - Select last row. - Pressing backspace leads to traceback. This issue happens because the copied table is pasted with first row wrapped in a thead element. Due to this, rows are wrongly calculated leading to traceback in removeRow method. **Desired behavior after PR is merged:** - This commit ensures that if a table has first row wrapped inside a `thead`, the row is moved from `thead` to the start of `tbody` ensuring that rows are calculated correctly. task-5048339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226990 Forward-Port-Of: odoo/odoo#224784
The project dashboard now prevents users from editing milestone quantity percentages when no sales order line is linked. This avoids confusing failed edits and makes milestone billing data behave consistently with the underlying sales order setup.
Original PR description
**Steps to Reproduce:** - Install sale_project. - Go to the project dashboard. - Click on Edit milestones. **Isuue:** When a sales order line exists, the quantity percentage can be updated. When no sales order line exists, the quantity percentage cannot be updated. **Fix:** Make the field readonly when no sales order line is linked. task-5068312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227922
The website builder tooltip for the footer visibility option has been corrected so it no longer describes the opposite behavior. This helps users understand whether the footer will be shown or hidden when adjusting page visibility settings.
Original PR description
A tooltip message was added to the option for the visibility of the footer in e0474c19d212d9c19fd1c3bbc9546b4258770018. The message indicates the opposite of the effect. This commit changes the message to match the behavior of the checkbox. Steps to reproduce: - Open website builder - Click on footer - Hover "Page Visibility" - Bug: the message "Enable to hide...", but enabling actually shows task-4991435
This fixes an issue in the HTML editor where images added from an empty formatted line could disappear after the user clicked elsewhere. The change preserves the inserted image during editor cleanup, helping users avoid lost content while composing pages or messages.
Original PR description
Problem: When an image is added inside a `data-oe-zws-empty-inline`, it is removed along with its parent during normalization. Solution: During normalization, replace `data-oe-zws-empty-inline` with the image inside instead of removing both. Steps to reproduce: - Press CTRL+B in an empty line - Press Enter - Click on "Insert image, ..." from the placeholder - Choose an image - Click in the previous paragraph - The image disappears without this fix task-5051343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228620 Forward-Port-Of: odoo/odoo#224922
The website and HTML editing tools now use Odoo’s slimmer close icon for a cleaner, more consistent interface. Some button layouts and dropdown behavior were also corrected so controls align better and remain usable on smaller screens.
Original PR description
This commit replaces occurrences of `fa-times` in the html builder and editor with our own `oi-close` icon, which is less bulky and more elegant. It also corrects button structures where icon classes were placed directly on the `button`, ensuring they are applied to a child `<i>` element as intended. It also ensures `.o-hb-selectMany2X-wrapper` has `min-w-0` so the dropdown is truncated properly without pushing the remove button out of the screen. task-5090805 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swedish bankgiro accounts are now correctly marked as BGNR instead of BBAN in payment XML files. This helps ensure Swedish credit transfer files use the expected account type and are accepted by banking systems.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
The Swedish SIE4 export now uses the character encoding required by the official SIE specification. This helps ensure exported accounting files handle Swedish characters correctly and are accepted by systems expecting the standard format.
Original PR description
The SIE4 specification (page 8, section 5.8) requires the file character set to be IBM PC 8-bit extended ASCII (Codepage 437). Previously, 'ISO-8859-1' was used, which does not comply with the standard and may cause issues with Swedish characters. This commit updates the SIE4 export to use codepage 437, ensuring full compliance with the specification. Specification can be found here: https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_080930.pdf
The field service onboarding guide now works correctly even when a project already contains task templates. This helps new users complete setup without being blocked by pre-existing configuration.
Original PR description
This commit's purpose is to allow the fsm onboarding tour to work even if there are existing task template within the fsm project. note : This commit has to be edited in the 19.0 forward port, since its IsActive selector was updated. It should be ["body:has(.o-kanban-button-new.o-dropdown-caret"] instead. task-5088820 Forward-Port-Of: odoo/enterprise#94904
This fixes an issue where engineering change orders rounded very small bill of materials quantity updates to two decimal places instead of using the product unit precision. Businesses using precise measurements can now record and review small component quantity changes correctly.
Original PR description
Steps to reproduce the bug:
- Go to Decimal Accuracy → Product Unit of Measure → set digits to 4
- Go to Units of Measure Categories → select a unit → set rounding to 0.0001
- Create a storable product “P1” with a BoM:
- Component C1: 1.0000 unit
- Create an ECO for the BoM with type BoM update
- Start the revision
- Go to V2
Problem:
You cannot update the quantity of C1 to 1.0003 (for example) because the system uses the default 2 digits instead of the UoM digits.
opw-5082488
Forward-Port-Of: odoo/enterprise#95470
Forward-Port-Of: odoo/enterprise#95180This update ensures that errors in automated tests are correctly detected instead of being overlooked. It improves internal quality checks for the website helpdesk live chat area, helping teams catch issues earlier before they affect users.
Original PR description
This commit follows a community fix that restores proper error handling within and outside of unit tests. As such, it fixes tests reporting errors that were previously not picked up. Community PR: https://github.com/odoo/odoo/pull/228836 Forward-Port-Of: odoo/enterprise#95797
This fixes an issue in Indian payroll where the system could incorrectly check whether total allowances stay below the wage amount. The correction helps payroll teams avoid incorrect validation errors and improves confidence in salary rule checks.
Animated text and other elements in slide-over footers now trigger when visitors scroll to them. This prevents footer content from staying hidden and helps website pages display as intended.
Original PR description
Before this commit, using animation on text within the footer elements would not work if the footer was set on "slide over". The formula used to compute when to start the animation was incorrect. This commit fixes the formula. Steps to reproduce: - Set the Footer slideout to "Slide Over" - Set the Animation of an element to "On Appearance" - Save (when scrolling down, the animated element stay hidden) Forward-Port-Of: odoo/odoo#226562
This fixes an issue where entering a font size in the website editor could automatically change the value by adding unexpected decimals. Users can now set sizes such as 19px without seeing them altered, while the displayed value remains clean and readable.
Original PR description
__Current behavior before commit:__ When typing an integer value in the font size input, some decimals are added automatically because the value entered in `px` is first converted to `rem` then it's converted back to `px` but some precision is lost in `convertNumericToUnit` because `toFixed(3)` is called on the result. __Description of the fix:__ `toFixed` is removed from `convertNumericToUnit` to avoid any loss of precision on the value saved. However it's now used in `formatRawValue` so that the value displayed to the user is stays clean. This way we keep the behavior intended by [this PR]. __Steps to reproduce the issue on runbot:__ 1. Open the website builder. 2. Go to the *Theme* tab. 3. In Paragraph section, set the Font Size to 19px. => It gets changed to 19.008px automatically. [this PR]: https://github.com/odoo/odoo/pull/221754 Forward-Port-Of: odoo/odoo#224633
This fixes a purchase stock test so it consistently uses a consumable product, regardless of defaults introduced by localization modules. It prevents false test failures when Kenyan localization is installed, improving reliability without changing user-facing purchase or inventory behavior.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228583 Forward-Port-Of: odoo/odoo#221042
The chatter follower menu now stays open after removing a follower, making it easier to remove several followers in one session. The subscription edit action now closes the menu consistently, reducing confusion for users managing followers.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Removing multiple followers from the chatter is cumbersome because the followers dropdown closes immediately after each removal. Additionally, clicking 'Edit Subscription' next to 'Unfollow' did not close the dropdown, which was inconsistent with expected behavior. **Current behavior before PR:** --------------------------------- - Removing a follower from the chatter closes the followers dropdown immediately - Clicking 'Edit Subscription' next to 'Unfollow' leaves the dropdown open **Desired behavior after PR is merged:** ----------------------------------------- - The followers dropdown remains open after removing a follower, allowing multiple removals without interruption - Clicking 'Edit Subscription' next to 'Unfollow' closes the dropdown as expected **Task:** 4943867 Forward-Port-Of: odoo/odoo#222154
This update adjusts an internal sales test so it uses the configured sales confirmation email template instead of assuming a fixed one. It helps ensure payment and order confirmation behavior is tested accurately when businesses customize their email settings.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226240
Creating a salesperson from a converted lead no longer copies unrelated lead phone details into the new salesperson record. This prevents incorrect contact information from being saved and reduces manual cleanup for sales teams.
Original PR description
To reproduce: ============= 1- add a lead 2- add a phone and a mobile number 3- convert it to opportunity 4- create salesperson from that view 5- salesperson contains lead number Problem: ========= Before this fix, creating a Salesperson inherited the global context, which included unrelated values as active_model was set to crm.lead. This led to incorrect default values being applied. https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/web/models/models.py#L872C13-L872C21 The default values contained the lead phone and lead number and was applied in the creation of salesperson. Solution: ========== Since we have some synchronization of some fields (email, phone) that is automatically done normally, it's reasonable to remove the code and see what it gives. opw-4871069 Forward-Port-Of: odoo/odoo#229171 Forward-Port-Of: odoo/odoo#217545
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
Website editors are now protected from errors when entering an invalid progress bar value. The progress bar input also displays percentages more cleanly, avoiding confusing duplicate percent signs.
Original PR description
Before this commit, putting an invalid input in the progressbar value would lead to a traceback. Moreover, the input could display "0%%" (one being in the input, the other being the displayed unit). This commit solves this issue by defining a saveUnit for the input and using the defaultValue when an input is invalid. Forward-Port-Of: odoo/odoo#227249
This update adjusts how Odoo's web test framework classifies and reports errors and warnings, so test issues are neither hidden nor treated as more severe than intended. It improves reliability of automated testing and helps developers catch real problems without unnecessary test interruptions.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228836 Forward-Port-Of: odoo/odoo#228674
This fixes an issue where selecting only a space in the HTML editor caused the color picker to close unexpectedly. Users can now apply font color consistently, including to spaces between words, improving text formatting reliability.
Original PR description
Problem: When trying to apply font color on a space, the color picker suddenly closes. Solution: Allow adding styles on space characters. Steps to reproduce: 1. Add text "A B". 2. Select the space only. 3. Try to change font color. 4. Observe that the color picker suddenly dismisses. task-5111480 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
OSS reports can now open correctly when a fiscal position uses a country group, such as Mainland Spain VAT, instead of a directly assigned country. This helps businesses handle regional VAT setups like mainland Spain versus the Canary Islands without report access errors.
Original PR description
To be able to deal with Spain with Canary Islands and mainland, we have a country group that is Mainland Spain VAT, with Spain minus several states (Canary basically). People want to be able to use it for OSS. But currently, if you have an entry with a tax with a fp with this country group (and no country), you can't open your OSS Report. So take the countries of the country group if there is none in the fiscal position. Forward-Port-Of: odoo/enterprise#95795
This fixes the hover animation for the website categories showcase snippet, which had stopped responding when visitors moved their mouse over it. Restoring this visual feedback helps storefront pages feel interactive and polished again.
Original PR description
Since commit [1], the hover effect on the "categories showcase" snippet is no longer working. Nothing happens when it’s hovered with the mouse. This is caused by a missing comma in the CSS rule that handles the effect. [1]: https://github.com/odoo/odoo/commit/dea725a4e45b584689813bdbf09e51070a3c55d3
12 changes
Resolved issues and error corrections
This fix narrows a checkout test so it focuses on confirming public access for click and collect orders. It reduces inconsistent automated test behavior where very fast test steps could accidentally create two orders instead of reusing the first one, helping keep future updates safer and more dependable.
Original PR description
Tours are too fast for imitating the user actions that led to sometimes creating 2 orders in parallel instead of reusing the first created. The test was added for b395f984b13eb83310024b9fa94d7822211ef8c1 fix, so with this commit, we keep the test more specific to the fix and avoid inconsistent behavior.
This fixes the stock quantities list so regular stock users no longer see every product highlighted in red. Red highlighting now appears only for products that have an expired removal date, making the list easier to read and helping users focus on items that need attention.
Original PR description
Description of the issue/feature this PR addresses: For stock users (not admins), the stock quantities list view display red lines for every product. Current behavior before PR: <img width="2243" height="217" alt="image" src="https://github.com/user-attachments/assets/330c591c-6ef4-46cb-8336-fa39fb483333" /> Desired behavior after PR is merged: Red lines are only displayed for products with a removal date and a removal date < current date <img width="2241" height="290" alt="image" src="https://github.com/user-attachments/assets/fe37adc7-e736-447e-a21e-e2fae984e074" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swedish domestic payment files will now include the creditor bank agent information when required. This helps ensure payment files meet Swedish banking expectations and reduces the risk of payment processing issues.
Original PR description
CdtrAgt should not be skipped when generating swedish domestic payments.
Customers viewing an online order that includes a manufactured product will no longer see the same manufacturing date twice. This keeps the order portal cleaner and avoids confusion when checking order and production details.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009** Forward-Port-Of: odoo/odoo#227997
This fix ensures the mailing list merge wizard correctly identifies the destination list when starting a merge. It prevents an error during merge setup, making list consolidation more reliable for marketing teams.
Original PR description
When merging mailing lists, the logic for pre-filling the destination list
ID ('dest_list_id') was incorrectly retrieving and checking 'src_list_ids'
(source lists) instead of the list of potentially active/destination IDs.
This change modifies the assignment to use 'dest_list_id' (or the active
context IDs) for determining the default value, resolving an error when
initiating the merge wizard.
Closes #228958
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-prFixes an issue in the HTML editor where the color picker closed unexpectedly when previewing background colors for a table cell. This keeps the editing flow stable so users can choose table cell colors without interruption.
Original PR description
Problem: When applying a background color to a `td`, the color picker dismisses unexpectedly. Cause: After c810b0c17b2f882b0ab5d073ba38464bffb0617e, we rely on the class `o_selected_td` to check if…
Problem: When applying a background color to a `td`, the color picker dismisses unexpectedly. Cause: After c810b0c17b2f882b0ab5d073ba38464bffb0617e, we rely on the class `o_selected_td` to check if we are in a selected `td` to keep the toolbar open. However, in another fix (254efd86cd1ce871807fdc25479ebc5beeb4eab3), we removed that class during the color preview operation. Previewing a color on a `td` triggers a selection change, which runs `shouldBeVisible`. Since `o_selected_td` is not found, the toolbar closes along with the color picker. Solution: Update https://github.com/odoo-dev/odoo/commit/254efd86cd1ce871807fdc25479ebc5beeb4eab3. A better fix is to use `o_selected_td_bg_color_preview` which will undo the `box-shadow` when we preview a color. Steps to reproduce: 1. Add a table. 2. Select a cell. 3. Apply a background color. 4. Select the cell again. 5. Hover a color to preview. → The color picker dismisses once a color is hovered. opw-5066309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting discount allocation settings now allow other income and other expense accounts to be selected. This fixes missing account options so businesses can configure discounts more accurately for their accounting setup.
Original PR description
With this PR: - Updated the domain of discount allocation fields to include `income_other`/`expense_other` account types. Task-5121917
Image changes made in the HTML editor now return to their original state with a single undo action. This makes editing content more predictable and reduces frustration when correcting image rotation, resizing, or positioning.
Original PR description
**Current behavior before PR:** - When rotating, resizing, or dragging an image using the transform container, pressing Ctrl+Z did not revert the image to its initial state (when the transform container was opened). - Instead, it required multiple undo operations to return to the initial state. **Desired behavior after PR is merged:** - Pressing Ctrl+Z now correctly reverts the image to its initial state in a single undo, after a transformation. task-5114320
This update adjusts an internal sales test so it uses the configured sales confirmation email template instead of assuming a fixed one. This helps ensure the test reflects real customer configurations and reduces the risk of false test results when email settings are customized.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226240
This removes a redundant database rule in the Discuss channel setup that could conflict with newer PostgreSQL versions. It helps future Odoo databases migrate or restore cleanly on PostgreSQL 18, without changing how users work with Discuss channels.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229274This fixes an automated accounting test that could finish before the merge wizard had fully completed its final step. The change improves test reliability, helping prevent false failures in quality checks without changing user-facing accounting behavior.
Original PR description
The last check of the tour is always true. So it sometimes closes too early. Wait really for the last operation for the last check runbot-error-108440
Fixes an issue that could make the mail app crash when a new message arrived while the browser tab was not active. This helps keep messaging reliable and avoids unnecessary disruption for users.
Original PR description
Backport of #213607. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
The favorite star in Documents spreadsheets now immediately shows the correct selected or unselected state on mobile devices. This avoids confusion when users mark or unmark a spreadsheet as a favorite and keeps the behavior consistent with the rest of Odoo.
Original PR description
The star icon on mobile would have a strange behaviour. After clicking it, the star would not change between filled/not filled until clicking elsewhere. It turns out that on mobile, after a click the hover rule is applied. And our hover rule would modify the icon to be the opposite of what it should be. This commit changes the CSS to use the same css as `BooleanFavoriteField` to stay consistent with the rest of Odoo. Task: [5092945](https://www.odoo.com/odoo/2328/tasks/5092945)
Removes a redundant database rule in the Mail app that could conflict with newer PostgreSQL versions. This helps newly created databases remain compatible with PostgreSQL 18 and reduces the risk of restore or upgrade failures.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229274