Monday, June 23, 2025
17 changes · saas-18.1
Resolved issues and error corrections
A typo in the hardware drivers module caused an update step to fail during git checkout. This fix corrects the data passed to the update process, allowing checkouts to complete as expected.
Original PR description
Introduced in odoo/odoo#213177. A simple typo meant the `update_conf` method was being called with a set instead of a dict, leading to an error being thrown and preventing the git checkout. This commit fixes the typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reduces a flaky automated test failure in the Mail app by allowing a more flexible check of edited message text. It helps keep validation runs reliable without changing end-user behavior.
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-181952Miscellaneous changes
Description of the issue/feature this PR addresses: allowedFns is used to validate functions permitted for use in evaluate. However, it is not currently exported, so other modules cannot create new functions. Current behavior before PR: Other modules can inherit and add new functions. 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#214106
Original PR description
Description of the issue/feature this PR addresses: allowedFns is used to validate functions permitted for use in evaluate. However, it is not currently exported, so other modules cannot create new functions. Current behavior before PR: Other modules can inherit and add new functions. 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#214106
For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not per invoice. Also, they do not separately compute the tax amount per each line to generate the final totals. They use total sales amount * tax. task - 4875546 Forward-Port-Of: odoo/odoo#214698
Original PR description
For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not per invoice. Also, they do not separately compute the tax amount per each line to generate the final totals. They use total sales amount * tax. task - 4875546 Forward-Port-Of: odoo/odoo#214698
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413 Forward-Port-Of: odoo/odoo#213522
Original PR description
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413 Forward-Port-Of: odoo/odoo#213522
`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
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
**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
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
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting pla
Original PR description
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting plain text inside code blocks preserves indentation using normal spaces, avoiding insertion of `nbsp`. task-4815939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211386
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
fix in version-18.0 Forward-Port-Of: odoo/odoo#215374
Original PR description
fix in version-18.0 Forward-Port-Of: odoo/odoo#215374
The size of fields for Previous Payroll IDs was set to 20 characters. According to the STP xml schema, the max size is 200. This is already checked with the schema validation so the limit can be safely removed. This commit also adds a disclaimer for the users informing them regarding STP compliance. opw-4820852 Forward-Port-Of: odoo/enterprise#87068
Original PR description
The size of fields for Previous Payroll IDs was set to 20 characters. According to the STP xml schema, the max size is 200. This is already checked with the schema validation so the limit can be safely removed. This commit also adds a disclaimer for the users informing them regarding STP compliance. opw-4820852 Forward-Port-Of: odoo/enterprise#87068
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
**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