Tuesday, May 27, 2025
38 changes · saas-18.1
Miscellaneous changes
Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This causes unwanted dark mode styles (e.g., `background-color`, `border-color`, and `color`) to persist even after switching back to light mode, especially in email signatures. Solution: Skip stylesheets that only affect `color`, `background-color`, or `border-color` on `table` elements. This av
Original PR description
Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This…
Problem: When in dark mode, additional styles are applied to improve display. However, these styles are inadvertently preserved during `convert_inline`, which processes HTML for email rendering. This causes unwanted dark mode styles (e.g., `background-color`, `border-color`, and `color`) to persist even after switching back to light mode, especially in email signatures. Solution: Skip stylesheets that only affect `color`, `background-color`, or `border-color` on `table` elements. This avoids incorrect rendering in light mode without removing essential formatting styles. Note: Skipping all styles caused layout issues, so the fix targets only problematic styles. Fixed in `web_editor`: https://github.com/odoo/odoo/commit/d076dbcc273be5c8f337de9263effa82c9d9c0c8 Steps to reproduce: 1. Switch to dark mode. 2. Add an email signature in user preferences. 3. Switch back to light mode. 4. Open the mail composer. → The signature table shows a dark background. 5. Send the email. → The table in the mail thread still has a dark background. opw-4713718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210834
Scenario: add a popup on a website page with enough text above the button so the button is not visible on the page without scrolling. Display the popup. Result: the popup is opened scrolled at the bottom (depends on if we are logged in or not), this usually works in incognito. Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the first tabbable element in the modal, but if that element is not in the view, the browser automatically scrolls to it. So there is this side effect tha
Original PR description
Scenario: add a popup on a website page with enough text above the button so the button is not visible on the page without scrolling. Display the popup. Result: the popup is opened scrolled at the bottom (depends on if we are logged in or not), this usually works in incognito. Issue: in 89e2513f577e9455d5bfd933d7e479b295d45a26 we focused on the first tabbable element in the modal, but if that element is not in the view, the browser automatically scrolls to it. So there is this side effect that happen if the first tabbable element is hidden by the scroll. Fix: after we focus to the element, we reset the scrollTop to 0 to ensure we stay at the top of the popup. opw-4647172 Forward-Port-Of: odoo/odoo#209910 Forward-Port-Of: odoo/odoo#206318
Currently, an error occurs when sorting is applied again on a different related field after sorting another related field first. Steps to reproduce: - Install `accountant` module - Navigate `Accounting > Accounting > Assets (list view)` - Apply Sorting on column `Fixed Asset Account` - Try to sort the column `Depreciation Account` - Observe the error Error: `AssertionError` The issue occurs when attempting to add a JOIN on an SQL query without verifying whether it has already been
Original PR description
Currently, an error occurs when sorting is applied again on a different related field after sorting another related field first. Steps to reproduce: - Install `accountant` module - Navigate `Accounting > Accounting > Assets (list view)` - Apply Sorting on column `Fixed Asset Account` - Try to sort the column `Depreciation Account` - Observe the error Error: `AssertionError` The issue occurs when attempting to add a JOIN on an SQL query without verifying whether it has already been included. - [1] This commit resolves the issue by adding a conditional check before adding a join in the query, ensuring that duplicate joins are not added. [1] - https://github.com/odoo/odoo/blob/b2e564f07f6883111da4581bccfb0f45c7588063/addons/account/models/account_account.py#L150-L152 Sentry-6039417751 Forward-Port-Of: odoo/odoo#196754
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun
Original PR description
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`) - upgrade to Odoo 17.0 By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company. Enterprise PR: odoo/enterprise#80812 opw-4781045 Forward-Port-Of: odoo/odoo#211526 Forward-Port-Of: odoo/odoo#200420
Steps to reproduce the issue: - Enter website edit mode. - Drag and drop a "Social Media" snippet into the footer. - Click on it. - In the options, click the "Add New Social Network" button. - Save the page. - Re-enter edit mode. - Click the pencil icon of the newly added item. - In the options, click the "Replace" button. - Bug: the media dialog does not open. The bug was introduced by commit [1], where the double-click on the icon, which was triggered when clicking the "Replace"
Original PR description
Steps to reproduce the issue: - Enter website edit mode. - Drag and drop a "Social Media" snippet into the footer. - Click on it. - In the options, click the "Add New Social Network" button. - Save…
Steps to reproduce the issue: - Enter website edit mode. - Drag and drop a "Social Media" snippet into the footer. - Click on it. - In the options, click the "Add New Social Network" button. - Save the page. - Re-enter edit mode. - Click the pencil icon of the newly added item. - In the options, click the "Replace" button. - Bug: the media dialog does not open. The bug was introduced by commit [1], where the double-click on the icon, which was triggered when clicking the "Replace" button, was replaced with a direct call to the `openMediaDialog` function. After this change, in the steps described above, the function is called when there is no selection on the page. As a result, `openMediaDialog` does not execute completely. This commit fixes the issue by selecting the icon if no selection is already present. [1]: https://github.com/odoo/odoo/commit/3c89439a16c41d553322893761a35592b73a5338 opw-4734855 Forward-Port-Of: odoo/odoo#211246 Forward-Port-Of: odoo/odoo#210813
Versions -------- - saas-17.4+ Earlier versions displayed each variant seperately. Steps ----- 1. Have 2 product template attributes A and B; 2. have one of B's attribute values be excluded for one of A's values; 3. have a product template using these values; 4. ensure product template is available in POS; 5. sell product template in POS. Issue ----- The attribute combination that should be excluded isn't displayed as such. Cause ----- When checking for product attribute
Original PR description
Versions -------- - saas-17.4+ Earlier versions displayed each variant seperately. Steps ----- 1. Have 2 product template attributes A and B; 2. have one of B's attribute values be excluded for one of A's values; 3. have a product template using these values; 4. ensure product template is available in POS; 5. sell product template in POS. Issue ----- The attribute combination that should be excluded isn't displayed as such. Cause ----- When checking for product attribute exclusions, it currently only considers attribute combinations of archived products to be unavailable for sale. Solution -------- In the `_get_archived_combinations_per_product_tmpl_id` method, factor in attribute exclusions, and treat them as archived product variants. In master, rename the method & references to it to reflect more general unavailable attribute combinations instead of specifically archived products. opw-4521198 Forward-Port-Of: odoo/odoo#199042
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
Original PR description
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with…
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs).
This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
According to the Fetch specification, the user agent may terminate an ongoing fetch if that termination cannot be observed through script. In our case, however, the fetch cannot be terminated because the termination can be observed through the promise and a TypeError is thrown[1].
Here a sample to reproduce the errors with firefox on github:
```js
window.onbeforeunload = () => console.log("beforeunload");
fetch("https://github.com/").then(() => console.log("fetch"));
window.location = "https://github.com/";
```
Should log inside the Firefox console:
```log
beforeunload
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
```
Another errors can occur when we unload a page, if we manipulate the DOM when it's unload a DOMException can be trowed[2], we also handle these case inside this commit.
This commit prevents displaying these errors on dialog inside Odoo.
task-4457865
[1]: https://fetch.spec.whatwg.org/#http-network-fetch
[2]: https://webidl.spec.whatwg.org/#dom-domexception-abort_err
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210854
Forward-Port-Of: odoo/odoo#210786Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earl
Original PR description
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for…
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earlier are thus also added as `default_type` in the context. But when creating a record, the ORM checks for all `default_*` key in the context and try to use it as additional values for the created record. Since the key-value combination `type` and `purchase` is not valid in an `ir.attachment` record, it throws this error. Solution: Before passing the context, we have to make sure to clean all the `default_*` contexts to avoid these kind of behaviors. In python, usually we use `clean_context` method before calling `create`. But since this is in JS, we manually filter all key-value item that starts with "default_" in the context object. opw-4512697 Forward-Port-Of: odoo/odoo#210423 Forward-Port-Of: odoo/odoo#201628
In this PR: - A `Print` button allows users to generate the E-Waybill or Challan PDF. - The PDF is attached to the chatter and gets downloaded. - Applies only when the document is marked as an E-Waybill or Challan. Task-4807694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210998
Original PR description
In this PR: - A `Print` button allows users to generate the E-Waybill or Challan PDF. - The PDF is attached to the chatter and gets downloaded. - Applies only when the document is marked as an E-Waybill or Challan. Task-4807694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210998
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Processing the backorder wizard will create and confirm moves for the backorder picking: https://github.com/odoo/odoo/blob/a7
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of…
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Processing the backorder wizard will create and confirm moves for the backorder picking: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1916-L1919 However, as these moves are `make_to_order` they are planned to create and run procurements in their respective `_action_confirm`'s: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1379-L1388 opw-4633920 opw-4713650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210364 Forward-Port-Of: odoo/odoo#209442
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes
Original PR description
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was…
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes no issue in standard odoo. However, as reported in [2], there is a world where `options` is undefined. I couldn't really find how, as it works fine even with the suggested culprit [3]. So this commit simply adds a fallback, which makes sense in stable in case there would be custom code calling those `listViewWidths` functions without options. In master though, we expect from people to adapt their code with respect to this change. [1] https://github.com/odoo/odoo/pull/210584 [2] https://github.com/odoo/odoo/issues/211243 [3] https://github.com/OCA/web/tree/18.0/web_remember_tree_column_width closes #211243 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#211722
This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211426
Original PR description
This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211426
Currently the show quantity setting visible on /product page does not apply on the product and combo configurator. We want to uniformize the behavior and if the setting is enabled then view the quantity selector everywhere depending on whether its visible on /product opw-4716312 opw-4781159 Backport of https://github.com/odoo/odoo/pull/209116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209934
Original PR description
Currently the show quantity setting visible on /product page does not apply on the product and combo configurator. We want to uniformize the behavior and if the setting is enabled then view the quantity selector everywhere depending on whether its visible on /product opw-4716312 opw-4781159 Backport of https://github.com/odoo/odoo/pull/209116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209934
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202220
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_mov
Original PR description
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_amount_currency_balance_sign" It occurs because, as we don't have `amount_currency` in the view, for line 2 the write operation will only store the updated values of `debit`,`credit`,`balance`, leaving the old amount of `amount_currency`. This creates an inconsistency as: - old `amount_currency` sign is negative - new `balance` sign is positive opw-4430334 Forward-Port-Of: odoo/odoo#211076 Forward-Port-Of: odoo/odoo#200566
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inhe
Original PR description
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is…
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inherited `display: block` from a floated parent, which added a `<br>` in empty blocks. Solution: Preserve the ZWS for inline empty elements with `data-oe-field="arch"`, ensuring the element remains editable after save. Steps to reproduce: 1. Navigate to `/jobs/experienced-developer-4`. 2. Open the web editor. 3. Delete the text inside the "Apply Now!" button. 4. Save the page. 5. Reopen the web editor. → The button is no longer editable. opw-4737255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209301
Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211448
Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I hav
Original PR description
Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210545
*: account, partner_autocomplete, web --- This PR is a backport of [this PR](https://github.com/odoo/odoo/pull/203522) Some changes have been made to it for retro compatibility while allowing the change in stable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207449
Original PR description
*: account, partner_autocomplete, web --- This PR is a backport of [this PR](https://github.com/odoo/odoo/pull/203522) Some changes have been made to it for retro compatibility while allowing the change in stable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207449
Description of the issue/feature this PR addresses: Steps to reproduce - Create and open POS, set it up with online payment (Demo) - Enter the payment (online payment), don't pay and refresh the page - After refresh, go to payment screen again - You'll get the error in my attachment  Current behavior before PR: - After selecting online payment, refresh the page, then
Original PR description
Description of the issue/feature this PR addresses: Steps to reproduce - Create and open POS, set it up with online payment (Demo) - Enter the payment (online payment), don't pay and refresh the page - After refresh, go to payment screen again - You'll get the error in my attachment  Current behavior before PR: - After selecting online payment, refresh the page, then you cannot cancel the payment line and error pop up appear Desired behavior after PR is merged: - Can cancel the payment line after refresh opw-4608951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199526
The adaptations from [1] and [2] added some code to the snippet preview dialog, mainly to adapt text highlights in the snippets content (starting from `18.0`) and enable the snippets preview interactions (starting from `18.3`) [A]. In a runbot test context, the snippet selection happens too fast that the code from [A] (linked to the async behaviour of `insertSnippets`) can still process the snippets dialog `iframeDocument` (lost after the dialog being closed on snippet selection). Th
Original PR description
The adaptations from [1] and [2] added some code to the snippet preview dialog, mainly to adapt text highlights in the snippets content (starting from `18.0`) and enable the snippets preview…
The adaptations from [1] and [2] added some code to the snippet preview dialog, mainly to adapt text highlights in the snippets content (starting from `18.0`) and enable the snippets preview interactions (starting from `18.3`) [A]. In a runbot test context, the snippet selection happens too fast that the code from [A] (linked to the async behaviour of `insertSnippets`) can still process the snippets dialog `iframeDocument` (lost after the dialog being closed on snippet selection). The goal of this commit is to fix this behaviour by simply taking into consideration the fact that the preview content can be lost (since in a real use case, a user will select a snippet in a reasonable time). [1]: https://github.com/odoo/odoo/commit/1aaf483c5d3b8e8816cfbea7da96ac007a42d492 [2]: https://github.com/odoo/odoo/commit/e008c92fcad2b8cc160586ba6ab94bc077b9bf3d Remark: This commit will be adapted on `18.3` to fix the code from [2]. runbot-190596 Forward-Port-Of: odoo/odoo#210295
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
Original PR description
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249 Forward-Port-Of: odoo/enterprise#85693
Original PR description
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249 Forward-Port-Of: odoo/enterprise#85693
When a quotation is loaded into the POS, a down payment is made, and then the order is settled, if the order has a discount that causes the total amount to become negative, the system prevents payment and raises an error. However, if the discount line is removed, the payment attempt also raises the same error. This happens because, even though the `pos.order.line` was removed, the values of the `pos.order` were not updated. Since it is required to validate the amount to be paid in the inherit
Original PR description
When a quotation is loaded into the POS, a down payment is made, and then the order is settled, if the order has a discount that causes the total amount to become negative, the system prevents payment and raises an error. However, if the discount line is removed, the payment attempt also raises the same error. This happens because, even though the `pos.order.line` was removed, the values of the `pos.order` were not updated. Since it is required to validate the amount to be paid in the inherited `pay` method, the error occurs. This commit fixes the issue by recomputing the amounts before the validations that require them. Forward-Port-Of: odoo/enterprise#81444
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#86107 Forward-Port-Of: odoo/enterprise#82292
Original PR description
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#86107 Forward-Port-Of: odoo/enterprise#82292
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data
Original PR description
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data is sorted to ensure import order is correct, but for inter-record dependencies on a same model many2one_reference fields are not taken into account. This PR fixes that. Also while analyzing this issue another small issue was spotted regarding base.automation.url field. See commits. Forward-Port-Of: odoo/enterprise#86204
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
Original PR description
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
The failed WhatsApp message icon turns green after 15 days or once the message is deleted. PROBLEM: WhatsApp messages are deleted after 15 days, leading to data loss and causing the default green icon to be displayed. SOLUTION: Introduced `getWhatsappStatusClass` to display appropriate icons based on the message state: - Green icon for `sent`, `delivered`, `read`, and `received` states. - Orange icon for the `outgoing` state. - Red icon for the `error` and `cancel` states. - Grey ico
Original PR description
The failed WhatsApp message icon turns green after 15 days or once the message is deleted. PROBLEM: WhatsApp messages are deleted after 15 days, leading to data loss and causing the default green icon to be displayed. SOLUTION: Introduced `getWhatsappStatusClass` to display appropriate icons based on the message state: - Green icon for `sent`, `delivered`, `read`, and `received` states. - Orange icon for the `outgoing` state. - Red icon for the `error` and `cancel` states. - Grey icon for the `undefined` state (i.e., deleted WhatsApp message). Also introduced was `getWhatsappStatusTitle`, which returns the correct title based on the message state. Task-4481123 Forward-Port-Of: odoo/enterprise#86289 Forward-Port-Of: odoo/enterprise#77739
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error. Steps to reproduce: ------------------- * Head to the sign app. * Upload a document or use pre-existing document * Click on the 3 dots and click on details. * Add a validity date save and then attempt to remove it. > Observation: TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' Why the fix: ------------ When removing the date, `write(
Original PR description
If you try to remove the Valid Until date to make the sign request valid without expiration, you get an rpc error.
Steps to reproduce:
-------------------
* Head to the sign app.
* Upload a document or use pre-existing document
* Click on the 3 dots and click on details.
* Add a validity date save and then attempt to remove it.
> Observation:
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
Why the fix:
------------
When removing the date, `write()` gets `vals{'validity': False}` `fields.Date.from_string(False)` returns `<class 'NoneType'>` which can not be compared with the operator `<`
opw-4795212
Forward-Port-Of: odoo/enterprise#85891**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#832
Original PR description
**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#83261
Prior to this commit, the creator box used the old version of the app icon (with gradients). This commit updates this icon to use the last version. task-4709035 | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/enterprise#861
Original PR description
Prior to this commit, the creator box used the old version of the app icon (with gradients). This commit updates this icon to use the last version. task-4709035 | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/enterprise#86191 Forward-Port-Of: odoo/enterprise#83242
For languages with longer terms than the English ones, the labels in the date filter would overflow because they had a fixed width. We now change it to use a minimal width and expand with the content. Also, the quarter label was not translatable in other languages that do not use the notation "Q1 2025". It's made translatable now. Lastly, some padding caused custom date inputs to be too narrow, meaning a horizontal scroll was necessary to see the whole value. This was fixed as well. [ta
Original PR description
For languages with longer terms than the English ones, the labels in the date filter would overflow because they had a fixed width. We now change it to use a minimal width and expand with the content. Also, the quarter label was not translatable in other languages that do not use the notation "Q1 2025". It's made translatable now. Lastly, some padding caused custom date inputs to be too narrow, meaning a horizontal scroll was necessary to see the whole value. This was fixed as well. [task-4770592](https://www.odoo.com/odoo/project.task/4770592) Forward-Port-Of: odoo/enterprise#85523 Forward-Port-Of: odoo/enterprise#84662
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows w
Original PR description
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows work fine with SEPA, we should also match transactions and statement lines whose partners names match when there is no partner_id set on the bank statement line. opw-4536189 Forward-Port-Of: odoo/enterprise#85965
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution -------- Remove the `parent` checks. opw-4788215 Forward-Port-Of: odoo/enterprise#86384
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#70683 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#70683 Forward-Port-Of: odoo/enterprise#57781
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `accoun
Original PR description
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct `account.journal` for the moves (and `account.account` for the lines). To reproduce: - initialize an Odoo 16.0 database with `account_accountant` and NO demo data. (There will be no country_id set on the default company, so the `post_install` hook in `account` won't install `l10n_generic_coa`) - install demo data (the `post_install` hook in `account` is then not fired, still no `l10n_generic_coa`) - upgrade to Odoo 17.0 By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company. Community PR: odoo/odoo#200420 opw-4781045 Forward-Port-Of: odoo/enterprise#86341 Forward-Port-Of: odoo/enterprise#80812
**Current behavior:** Scanning a package type in an MO in barcode while having a raw move line (component line) selected will result in a traceback. **Expected behavior:** Put the comp line in a new pack of that package type. **Steps to reproduce:** 1. Make a packge type 2. Make a new MO -> open it in barcode 3. Scan some component, select the new line 4. Scan the barcode of the package type -> traceback **Cause of the issue:** We end up calling `action_put_in_pack` when `
Original PR description
**Current behavior:** Scanning a package type in an MO in barcode while having a raw move line (component line) selected will result in a traceback. **Expected behavior:** Put the comp line in a new pack of that package type. **Steps to reproduce:** 1. Make a packge type 2. Make a new MO -> open it in barcode 3. Scan some component, select the new line 4. Scan the barcode of the package type -> traceback **Cause of the issue:** We end up calling `action_put_in_pack` when `this.resModel` is `MrpProduction` (which does not define this method). **Fix:** Define the method for the barcode MRP model to display a notification to, rather, scan a product (scanning a package here doesn't make sense). opw-4564834 Forward-Port-Of: odoo/enterprise#84467 Forward-Port-Of: odoo/enterprise#81374
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable,
Original PR description
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable, but non-trade. That way users can easily reconcile bank transactions with the tax authorities. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/enterprise/pull/85693 Forward-Port-Of: odoo/odoo#201249