Wednesday, June 11, 2025
17 changes · 17.0
Enhancements to existing features
Users can now archive a bank account linked to a contact instead of leaving outdated account details active. This helps businesses keep partner banking information cleaner while preserving historical records.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies internal code patterns across several Odoo apps without changing business workflows. It helps keep the codebase cleaner and easier to maintain, with minimal expected impact for users.
This update simplifies internal code patterns in several Odoo Enterprise modules without changing business workflows. It helps keep the codebase easier to maintain and may provide small efficiency benefits across reporting, payments, HR, appointments, knowledge, localization, and marketing tools.
Resolved issues and error corrections
When Jordan e-invoicing submissions are rejected because of incorrect credentials, users now see a clearer message instead of an empty error. This helps businesses identify setup problems faster and reduces confusion when invoices fail to send.
Original PR description
Improve the error message when the response is HTTP 403. Currently, the content is empty for such errors, making it difficult to identify the source of the problem for users. Step to reproduce: - Try to send an invoice with wrong credentials. - The error message is empty, making it hard to understand what went wrong. Error message before this commit:  After:  Also added the missing .pot file. opw-4823950 opw-4628908 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
Global purpose is to make mail/view controller more resilient by improving redirections when not having access to the record. Notably * correctly route internal users to discuss, portal users to /my and unlogged users to login; * keep original mail/view route when performing redirection after login so that we try the routing again; * fix various issues in redirect computation, such as lost access token parameter or partial reconstruction of URLs; Improve test coverage.
Original PR description
Global purpose is to make mail/view controller more resilient by improving redirections when not having access to the record. Notably * correctly route internal users to discuss, portal users to /my and unlogged users to login; * keep original mail/view route when performing redirection after login so that we try the routing again; * fix various issues in redirect computation, such as lost access token parameter or partial reconstruction of URLs; Improve test coverage. Task-4685166 Forward-Port-Of: odoo/odoo#212545
This update adds the missing phone number needed for an online sales checkout test to complete successfully. It prevents the automated add-to-cart checkout validation from timing out, helping keep website sales flows reliable.
Original PR description
the tour was failing because the phone number was not set in the website configuration, which is required for the add to cart snippet tour to pass because it checks the phone number in the billing address form page which is required to be filled in order to proceed with the tour and confirm order is on the next page which is not reached so the tour was failing due to timeout build_error-160894
The mail GIF picker now shows a clear help message when users open Favorites without any saved GIFs. This avoids an empty, confusing screen and makes the feature easier to understand.
Original PR description
**Current behavior before PR:** When the user opened the Favorite category with no favorite GIFs, nothing was shown. This was caused by using `.length` on Map objects (`evenGif.gifs` and `oddGif.gifs`) , which should have been `.size`. (since #131344 ) **Desired behavior after PR is merged:** Help message is correctly displayed when no favorite GIFs are available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies a small part of Odoo's translation tooling by avoiding unnecessary temporary list creation. It is an internal code quality fix with no expected visible change for users, but it helps keep the codebase aligned with quality checks.
Original PR description
Also replace an unnecessary listcomp by a gencomp as the list is not necessary. Though all the callsites seem to go through the entire sequence so likely doesn't do much.
Have a model that returns a warning onchange during the first call to onchange. On another model that has a many2one to the first model, Create And Edit a record via the many2one field on the form view. Before this commit, there was an endless loop because on dialog was triggering the opening of a second one *during* its willStart lifecycle period, so none of them end up mounted, instead, the formViewDialog was constantly reinstanciated because the dialog container constantly received request
Original PR description
Have a model that returns a warning onchange during the first call to onchange. On another model that has a many2one to the first model, Create And Edit a record via the many2one field on the form view. Before this commit, there was an endless loop because on dialog was triggering the opening of a second one *during* its willStart lifecycle period, so none of them end up mounted, instead, the formViewDialog was constantly reinstanciated because the dialog container constantly received requests to re-render. After this commit, we only open those dialog onMounted of the main component, and this issue doesn't occur anymore. opw-4783459 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#213742
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As
Original PR description
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner…
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As a result, the `-50%` margin shifts the video offscreen. Solution: Set both `left` and `right` to `0` in `.o-position-absolute` to ensure proper centering. Remove `margin-left: -50%` to prevent misalignment in non-editor contexts. **Before**: In website editor:  In contacts (html_field):  **After** In website editor:  In contacts (html_field):  Steps to reproduce: - Go to Contacts > "Gemini Furniture". - Add a video in the "Website Partner Full Description" field. - Save and open the partner on the website (`partners/gemini-furniture-11`). - Return to the Contacts page. → The video appears shifted 50% to the left. opw-4752567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212344
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of
Original PR description
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of the date is obviously 2024 but the week of 12/30/2024 is 1 only because we consider it part of 2025. Since both parts of the information are gathered independently, we end up with this misleading formatted value. Task-4853825 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#213302
Current behaviour: --- When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35 Expected behaviour: --- The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: --- 1. G
Original PR description
Current behaviour: --- When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35 Expected behaviour: --- The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: --- 1. Go to Contacts 2. Create a new contact 3. Set country as Malaysia, and choose a state 4. Go to Invoice, create one 5. Select new malaysian contact 6. State code in address instead of name Fix: --- Added a custom address_format in res_country_data.xml opw-4762300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212316
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body: "Durante el año gravable de 2025..." This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year. This change ensures that the "año gravable" corresponds to the selected period ye
Original PR description
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the…
The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body: "Durante el año gravable de 2025..." This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year. This change ensures that the "año gravable" corresponds to the selected period year, taken from the date_from filter in the report wizard, which reflects the actual accounting or fiscal period being certified. Justification According to Colombian tax practices and DIAN guidelines, the "año gravable" mentioned in retention certificates must match the period in which the income or payment was made and the tax was withheld. Using the current date instead of the actual reporting period could lead to confusion or even legal inconsistencies during audits. Reference: Estatuto Tributario Art. 378: Certificates must include the fiscal year in which the withholding was applied. Common practice requires companies to issue certificates reflecting the year of the transactions, not the year of report generation. Forward-Port-Of: odoo/enterprise#86838
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The c
Original PR description
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The currency code should go into Column C - The base currency amount (i.e. the company's local currency) should be shown in Columns E and F opw-4701001 Forward-Port-Of: odoo/enterprise#87002
**Before this commit:** - Submitting a GSTR-1 return to the GST portal with an empty `hsn` dictionary caused a schema validation error from the portal: {"error_msg": "Error in Json structure validation.", "error_cd": "RET191106"} - This occurred because the generated JSON included the `hsn` key with an empty dictionary, which is invalid as per government schema requirements. - The portal expects the `hsn` field to be absent if no data is available, or to contain valid nested keys an
Original PR description
**Before this commit:**
- Submitting a GSTR-1 return to the GST portal with an empty `hsn` dictionary
caused a schema validation error from the portal:
{"error_msg": "Error in Json structure validation.", "error_cd": "RET191106"}
- This occurred because the generated JSON included the `hsn` key with an
empty dictionary, which is invalid as per government schema requirements.
- The portal expects the `hsn` field to be absent if no data is available, or to
contain valid nested keys and values.
**After this commit:**
- A `ValidationError` is raised when attempting to send a GSTR-1 return with no
HSN data, preventing the generation and submission of an invalid JSON payload.
- This ensures that the `hsn` field is only added to the payload when it contains
at least one section with data.
- Helps avoid unnecessary submission failures and improves user feedback at the
point of action.
task - 4807628
Forward-Port-Of: odoo/enterprise#86655In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a) **Backport of this PR:** https://github.com/odoo/enterprise/pull/87171 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947 Forward-Port-Of: odoo/enterprise#87160
Original PR description
In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a) **Backport of this PR:** https://github.com/odoo/enterprise/pull/87171 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947 Forward-Port-Of: odoo/enterprise#87160
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name. Purpose: When changing the c
Original PR description
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after…
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name. Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention. Steps to Reproduce on Runbot: 1. Install Payroll 2. Create a new salary structure with no country 3. Create a new salary rule and enable "View in Payroll reporting" 4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created 5. Change the country set on the salary structure 6. Try to access a payroll report record and a traceback is thrown opw-4649030 Forward-Port-Of: odoo/enterprise#83749