Monday, June 23, 2025
30 changes · saas-18.3
Enhancements to existing features
Accounting demo data installation now skips creating statement PDF attachments when the PDF service is unavailable. This prevents unnecessary warnings during demo setup without affecting normal statement attachment creation.
Original PR description
In the enterprise commit, we create a pdf at the creation of the statement. But for demo data, the connection to wkhtml2pdf is unreachable and it makes a warning. This will add a context key to avoid the pdf to be created when installing demo data task-4866269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The spreadsheet boolean multi selector now prevents users from typing free text that would not affect the filter. This makes the filter interaction clearer and avoids confusion when setting spreadsheet filters.
Original PR description
Before this commit, users could enter free text in the boolean multi selector. It has no impact on the filter, but it's not a good user experience. This commit prevents users from entering free text in the boolean multi selector. Task: 4878579 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
Miscellaneous changes
Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the fie
Original PR description
Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object…
Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the field. Note that the default value and its presence in internal code of JS models happened for all tests that use `@mail` static files. That means this PR `[1]` fixed a retained memory for all `@mail` and related tests. While this fixed many tests, we still observed this retained memory on all discuss call tests. This happens because while the default value no longer uses this shared object, the computed value still does. Therefore call tests were sharing the const and thus retaining the window object. Note that the computed method is implicitly lazy, so this is only invoked in code that actually uses this `iceServers` field, hence why only discuss call tests were still affected by the issue. This commit fixes the issue by replacing the DEFAULT_ICE_SERVERS object by GET_DEFAULT_ICE_SERVERS function. This ensures each test use a different object, thus preventing retaining the window object after test has ended. [1]: https://github.com/odoo/odoo/pull/204521 Forward-Port-Of: odoo/odoo#215305 Forward-Port-Of: odoo/odoo#215208
This fixes how the Time Off calendar chooses the default employee when opening related actions. It now uses the employee already selected in the calendar instead of relying on the active record, helping avoid requests being created for the wrong person.
Original PR description
take default_employee_id from the employee_id not from active_id task-4885649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Hiring users who are allowed to refuse applicants can now complete that action even when related offers are linked to contracts they cannot normally manage. This prevents an unnecessary permission error and keeps recruitment workflows moving while handling the associated offer update automatically.
Original PR description
Change: Skip access rights of `hr.contract` when refusing an applicant. Reasoning: If you have the right to refuse an applicant, you should be able to refuse an applicant and retrospectively, **sudo** refuse the associated offer(s). Task-4868368
A test setup for the Mexican e-invoicing landing module was corrected so it can create the needed sales order when demo data is not installed. This helps prevent false build failures and keeps automated quality checks reliable.
Original PR description
steps to reproduce: 1- install l10n_mx_edi_landing 2- without demo data 3 - run test_make_cfdi_report_carry_over_canceled_invoice missing sudo in test case to create sale order in the test build_error-226771
Following non-deterministic test failure happens on runbot: ``` [HOOT] Test "@mail/message/message/Can edit message comment in chatter" failed: [HOOT] Error: Failed to find 1 of ".o-mail-Message .o-mail-Composer-input" with value "edited again" (Timeout of 3 seconds). Found 0 instead. ``` We couldn't reproduce in practice to see why this fails, and we are not helped from HOOT tests on runbot being run in headless mode thus screenshots are useless. One theory of failure is race conditio
Original PR description
Following non-deterministic test failure happens on runbot: ``` [HOOT] Test "@mail/message/message/Can edit message comment in chatter" failed: [HOOT] Error: Failed to find 1 of ".o-mail-Message…
Following non-deterministic test failure happens on runbot:
```
[HOOT] Test "@mail/message/message/Can edit message comment in chatter" failed:
[HOOT] Error: Failed to find 1 of ".o-mail-Message .o-mail-Composer-input" with value "edited again" (Timeout of 3 seconds). Found 0 instead.
```
We couldn't reproduce in practice to see why this fails, and we are not helped from HOOT tests on runbot being run in headless mode thus screenshots are useless.
One theory of failure is race condition of composer input still containing the trailing `\n` character when we'd expect it to be removed. The `contains({ value })` of mail test helpers checks for exact match of value thus the error.
This commit attempts to fix the issue by using relaxing the condition for input containing at least the expected character. In other words: it replaces the `{ value }` (exact match) by `:value()` (includes match). That way if the value still has the `/n` trailing character, assertion `edited again` would pass with `edited again/n`.
Note that `:value` seems to not see newlines `\n` in inputs. This is a bit annoying so we had to relax the other value assertion too. There's plan to use web selectors rather than mail ones, which is another reason to not improve mail_test_helpers further and instead put effort to migrate to web test helpers.
runbot-181952
Forward-Port-Of: odoo/odoo#214626- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215285 Forward-Port-Of: odoo/odoo#204742
Original PR description
- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215285 Forward-Port-Of: odoo/odoo#204742
Before this commit, printing images in receipt with the web print could not show the images if they are not loaded. This is now waiting for the images to be loaded. Before this commit, if an order preset time was from yesterday, the order could not be cancelled. This is now fixed by changing the condition to accept cancelling orders with a preset time in the past --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213988
Original PR description
Before this commit, printing images in receipt with the web print could not show the images if they are not loaded. This is now waiting for the images to be loaded. Before this commit, if an order preset time was from yesterday, the order could not be cancelled. This is now fixed by changing the condition to accept cancelling orders with a preset time in the past --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213988
Issue: Before this commit, sometimes we might have different accounts with the same type, which throws a singleton error Fix: Check if all the accounts are not reconciled oes-4798698 Forward-Port-Of: odoo/odoo#214535
Original PR description
Issue: Before this commit, sometimes we might have different accounts with the same type, which throws a singleton error Fix: Check if all the accounts are not reconciled oes-4798698 Forward-Port-Of: odoo/odoo#214535
**Current behavior before PR:** When the chatbot redirects a visitor to a webpage on mobile, the chat window remains open, covering the redirected page. Making it difficult for the visitor to interact with the redirected page. **Desired behavior after PR is merged:** The conversation is automatically folded when the chatbot redirects a visitor to a webpage on mobile. **Task**-4630719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward
Original PR description
**Current behavior before PR:** When the chatbot redirects a visitor to a webpage on mobile, the chat window remains open, covering the redirected page. Making it difficult for the visitor to interact with the redirected page. **Desired behavior after PR is merged:** The conversation is automatically folded when the chatbot redirects a visitor to a webpage on mobile. **Task**-4630719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201132
This commit fixes an issue in the datetime_picker where clicking on an already selected start date would not initiate the selection of an end date. As a result, users were forced to select a different date first before being able to reselect the same start date. With this fix, clicking the start date again now correctly triggers the end date selection phase, improving the overall usability of the daterange picker. task-4845373 Forward-Port-Of: odoo/odoo#215037
Original PR description
This commit fixes an issue in the datetime_picker where clicking on an already selected start date would not initiate the selection of an end date. As a result, users were forced to select a different date first before being able to reselect the same start date. With this fix, clicking the start date again now correctly triggers the end date selection phase, improving the overall usability of the daterange picker. task-4845373 Forward-Port-Of: odoo/odoo#215037
We introduce a new systemd service that automatically starts on boot, trying to enable a remote access using ngrok. This will fail most of the time as users don't configure a ngrok token. When one is configured, the tunnel will open. When we'll remove it, we'll stop the service and its automatic startup will fail again on next boot. task: 4848368 Forward-Port-Of: odoo/odoo#215074 Forward-Port-Of: odoo/odoo#213409
Original PR description
We introduce a new systemd service that automatically starts on boot, trying to enable a remote access using ngrok. This will fail most of the time as users don't configure a ngrok token. When one is configured, the tunnel will open. When we'll remove it, we'll stop the service and its automatic startup will fail again on next boot. task: 4848368 Forward-Port-Of: odoo/odoo#215074 Forward-Port-Of: odoo/odoo#213409
**PROBLEM** In the user menu, the text of dropdown item sometimes overlap with the checkbox next to it when it's too long. **STEP TO REPRODUCE** (happened with the italian localization of the onboarding module, but it's no longer the case because the text was shortened) 1. In `enterprise/web_enterprise/i18n/it.po`, for the msgid "Dark Mode" set the translation to something long. 2. click on the user menu and notice the text for the dark mode dropdown item is overlapping with the checkbox
Original PR description
**PROBLEM** In the user menu, the text of dropdown item sometimes overlap with the checkbox next to it when it's too long. **STEP TO REPRODUCE** (happened with the italian localization of the onboarding module, but it's no longer the case because the text was shortened) 1. In `enterprise/web_enterprise/i18n/it.po`, for the msgid "Dark Mode" set the translation to something long. 2. click on the user menu and notice the text for the dark mode dropdown item is overlapping with the checkbox next to it. **CAUSE** The checkbox in the user_menu.xml template use d-flex and flex-row-reverse, which doesn't work well with the class form-switch. form-switch add a negative left-margin of -2.5em to the <input> inside the checkbox template. **FIX** Put the description text before the checkbox in a flex div, and remove the flex-row-reverse on the checkbox. opw-4654405 Forward-Port-Of: odoo/odoo#214851 Forward-Port-Of: odoo/odoo#214127
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784 Forward-Port-Of: odoo/odoo#215066 Forward-Port-Of: odoo/odoo#214757
Original PR description
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784 Forward-Port-Of: odoo/odoo#215066 Forward-Port-Of: odoo/odoo#214757
When the connection to the replica database fails, the worker failover to the primary database and keeps on connecting to the primary database until the worker is recycled. This makes any hicups to the replica connection degrades the system for a very long time, as workers are only recycled once/twice a week. In this work, we makes so it attempts to reconnect to the replica database once every 20 minutes. This makes to the system recovers more quickly. Description of the issue/feature t
Original PR description
When the connection to the replica database fails, the worker failover to the primary database and keeps on connecting to the primary database until the worker is recycled. This makes any hicups to the replica connection degrades the system for a very long time, as workers are only recycled once/twice a week. In this work, we makes so it attempts to reconnect to the replica database once every 20 minutes. This makes to the system recovers more quickly. 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#214279 Forward-Port-Of: odoo/odoo#214032
With a Spanish company and `l10n_es_edi_facturae`: - Create an invoice with a Spanish contact and confirm it. - Create a credit note for this invoice. Send and print it. In the Facturae XML, the `InvoiceClass` uses `OO` instead of `OR` (as specified on page 24 of [the specifications](https://www.facturae.gob.es/formato/Versiones/Esquema_castellano_v3_2_x_06_06_2017_unificado.pdf)). This commit also removes the hard-coded `'FC'` for `InvoiceDocumentType`, writing `'FA'` instead in the c
Original PR description
With a Spanish company and `l10n_es_edi_facturae`: - Create an invoice with a Spanish contact and confirm it. - Create a credit note for this invoice. Send and print it. In the Facturae XML, the `InvoiceClass` uses `OO` instead of `OR` (as specified on page 24 of [the specifications](https://www.facturae.gob.es/formato/Versiones/Esquema_castellano_v3_2_x_06_06_2017_unificado.pdf)). This commit also removes the hard-coded `'FC'` for `InvoiceDocumentType`, writing `'FA'` instead in the case of a simplified invoice. opw-4806099 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#214732 Forward-Port-Of: odoo/odoo#211649
`l10n_eg_long_edi` is set by two different computes. This is completely useless as it will trigger a write and the actual compute will still be called when the field is read. Forward-Port-Of: odoo/odoo#215134
Original PR description
`l10n_eg_long_edi` is set by two different computes. This is completely useless as it will trigger a write and the actual compute will still be called when the field is read. Forward-Port-Of: odoo/odoo#215134
The field 'account_tax_periodicity_journal_id' is required but not set in the test. This commit adds the missing field to ensure the test runs successfully. build-error-226482 Forward-Port-Of: odoo/odoo#213581
Original PR description
The field 'account_tax_periodicity_journal_id' is required but not set in the test. This commit adds the missing field to ensure the test runs successfully. build-error-226482 Forward-Port-Of: odoo/odoo#213581
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purcha
Original PR description
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purchase.bill.line.match` model is defined with `_auto = False`, meaning it is a non-storable model, does not have a corresponding database table, and therefore cannot be updated directly. [1] - https://github.com/odoo/odoo/blob/5977da2c93d522ece984d2fa8a31624f4b612eca/addons/purchase/models/purchase_bill_line_match.py#L10-L12 This commit makes fields read-only in the model, avoiding unintended write attempts on a non-storable view model. Sentry-6629713332 Forward-Port-Of: odoo/odoo#212383
From saas-18.2, some account changes on Swedish CoA when other module(s) are installed have been breaking the test for the export (that exports all the available account). This commit adapts the expected test file to ignore this changes and ensures the result always stays the same, no matter what modules are installed on the database. This fixes the currently recurring runbot errors from saas-18.2 and up: [runbot-159821](https://runbot.odoo.com/odoo/error/159821) Forward-Port-Of: o
Original PR description
From saas-18.2, some account changes on Swedish CoA when other module(s) are installed have been breaking the test for the export (that exports all the available account). This commit adapts the expected test file to ignore this changes and ensures the result always stays the same, no matter what modules are installed on the database. This fixes the currently recurring runbot errors from saas-18.2 and up: [runbot-159821](https://runbot.odoo.com/odoo/error/159821) Forward-Port-Of: odoo/enterprise#86752
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#88187 Forward-Port-Of: odoo/enterprise#82864
Original PR description
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#88187 Forward-Port-Of: odoo/enterprise#82864
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87511
Original PR description
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87511
This reverts commit b9745a5 - The fix is no longer needed, as the original validation error is no longer reproducible in 17.0. - This change resulted in extra document creation and is reverted to avoid duplicates. opw-4681311 Forward-Port-Of: odoo/enterprise#87270
Original PR description
This reverts commit b9745a5 - The fix is no longer needed, as the original validation error is no longer reproducible in 17.0. - This change resulted in extra document creation and is reverted to avoid duplicates. opw-4681311 Forward-Port-Of: odoo/enterprise#87270
When fuzzy matching the partner name, we were checking that `supplier_rank > 0`, but this should apply for vendor bills, not for customer invoices. For those, we need to check `customer_rank > 0`. [opw-4824010](https://www.odoo.com/odoo/project.task/4824010) Forward-Port-Of: odoo/enterprise#88144 Forward-Port-Of: odoo/enterprise#87869
Original PR description
When fuzzy matching the partner name, we were checking that `supplier_rank > 0`, but this should apply for vendor bills, not for customer invoices. For those, we need to check `customer_rank > 0`. [opw-4824010](https://www.odoo.com/odoo/project.task/4824010) Forward-Port-Of: odoo/enterprise#88144 Forward-Port-Of: odoo/enterprise#87869
When creating a SEPA Direct Debit (SDD) mandate for a contact, mandates linked to a child contact are not recognized as valid at payment registration. It should be but it suggests a configuration issue so it needs a warning but not an error. task-4507135 Forward-Port-Of: odoo/enterprise#85882
Original PR description
When creating a SEPA Direct Debit (SDD) mandate for a contact, mandates linked to a child contact are not recognized as valid at payment registration. It should be but it suggests a configuration issue so it needs a warning but not an error. task-4507135 Forward-Port-Of: odoo/enterprise#85882
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and tha
Original PR description
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and that partner. - Select it, and select the invoice we created, and click on Validate. - Notice that the partner is not set (removed) from the transaction. Fix: Add another condition to check if the statement line company matches the partner company before trying to unset the partner if its company isn't a root company. opw-4809740 Forward-Port-Of: odoo/enterprise#88034 Forward-Port-Of: odoo/enterprise#87440
**Steps to reproduce:** 1. Install contact and l10n_be_reports 2. Export any contact with external_id and tag (category_id) columns. 3. Edit the exported file and set category_id to blank. 4. Attempt to import the modified file. **Issue:** - Import fails with the error: TypeError: 'bool' object is not iterable **Cause:** - The write method is overrided in l10n_be_reports for checking removal of the protected tag '281.50' using: https://github.com/odoo/enterprise/blob/e157890
Original PR description
**Steps to reproduce:** 1. Install contact and l10n_be_reports 2. Export any contact with external_id and tag (category_id) columns. 3. Edit the exported file and set category_id to blank. 4. Attempt…
**Steps to reproduce:**
1. Install contact and l10n_be_reports
2. Export any contact with external_id and tag (category_id) columns.
3. Edit the exported file and set category_id to blank.
4. Attempt to import the modified file.
**Issue:**
- Import fails with the error:
TypeError: 'bool' object is not iterable
**Cause:**
- The write method is overrided in l10n_be_reports for checking removal of the protected tag '281.50' using:
https://github.com/odoo/enterprise/blob/e1578908a53652603a58f8b7a594c198deb47e7a/l10n_be_reports/models/res_partner.py#L29
However, when category_id is False (as in the import case),
vals.get('category_id', []) returns False, causing the iteration to fail with a TypeError.
**Solution:**
- https://github.com/odoo/enterprise/blob/944d4efb25b522c3e726221993f4be1e0fb2c133/l10n_be_reports/models/res_partner.py#L29 This ensures a safe fallback to an empty list in case the value is False.
opw-4717387
Forward-Port-Of: odoo/enterprise#87196This has to be done right after l10n setup, it has no to negative effect if done above the COA loop or before setting up localisation. This seems to most affect the domain engine as it can do a lot of relatively well filtered queries, but those need to be properly planned. The repeated `ANALYZE` are not free, but trade favorably (test runs about 4mn faster locally). Forward-Port-Of: odoo/enterprise#88143 Forward-Port-Of: odoo/enterprise#88116
Original PR description
This has to be done right after l10n setup, it has no to negative effect if done above the COA loop or before setting up localisation. This seems to most affect the domain engine as it can do a lot of relatively well filtered queries, but those need to be properly planned. The repeated `ANALYZE` are not free, but trade favorably (test runs about 4mn faster locally). Forward-Port-Of: odoo/enterprise#88143 Forward-Port-Of: odoo/enterprise#88116
Forward-Port-Of: odoo/enterprise#88149
Original PR description
Forward-Port-Of: odoo/enterprise#88149