Monday, June 23, 2025
23 changes · 18.0
New functionality added to Odoo
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### **Description of the issue/feature this PR addresses:** Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report Install Argentinean - Accounting module Install Spanish language Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto G
Original PR description
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in…
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### **Description of the issue/feature this PR addresses:** Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report Install Argentinean - Accounting module Install Spanish language Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto Go to the Cutomer invoices menu and select any of the invoices already created in demo data Go to the partner and change the Languaje to Spanish Return to the invoice and print the PDF ### **Current behavior before PR:** All the other terms are translated, but not the % VAT column  ### **Desired behavior after PR is merged:** All the terms are correctly translated  References LATM 1343 | ADHOC 50766 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
CSV imports of tax descriptions now preserve plain text without adding unwanted paragraph formatting. This keeps tax description data consistent and avoids small display or content changes caused by automatic HTML cleanup.
Original PR description
Before this commit, when plain text (e.g., "Some tax") was imported from a CSV file into the HTML field `description`, the system wrapped it in a `<p>` tag during normalization via `html_normalize`, since plain text is not valid HTML. After this commit, we add a check before record creation: - If the value is plain text without any HTML, we wrap it in a `<div>` to make it valid HTML. - If it already contains HTML, we leave it untouched. This avoids unintended `<p>` wrapping by `html_normalize`. Note: if content is wrapped in a `<div>`, `html_normalize` will strip it out. This ensures consistent HTML formatting for the description field during create/write operations and prevents unexpected automatic wrapping by the system. task-4862728
Code cleanup and technical improvements
This update simplifies shared code used by Odoo's web error stack trace handling, making it easier to maintain without changing user-facing behavior. It also includes the contributor license confirmation for the author.
Original PR description
**Description of the issue/feature this PR addresses:** Extract shared logic into `compareByFields(...)` within `addons\web\static\lib\stacktracejs\stacktrace.js`. **Current behavior before PR:** `compareByOriginalPositions(...)`, `compareByGeneratedPositionsDeflated(...)`, and `compareByGeneratedPositionsInflated(...)` each contain shared code. **Desired behavior after PR is merged:** Introduce a helper `compareByFields(...)` that handles comparing by positions with optional parameters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### Description of the issue/feature this PR addresses: Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report 1. Install Argentinean - Accounting module 2. Install Spanish language 3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscr
Original PR description
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in…
Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### Description of the issue/feature this PR addresses: Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report 1. Install Argentinean - Accounting module 2. Install Spanish language 3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto 4. Go to the Cutomer invoices menu and select any of the invoices already created in demo data 5. Go to the partner and change the Languaje to Spanish 6. Return to the invoice and print the PDF ### Current behavior before PR: All the other terms are translated, but not the % VAT column  ### Desired behavior after PR is merged: All the terms are correctly translated  References LATM 1343 | ADHOC 50766 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: https://github.com/odoo/odoo/pull/206869 Forward-Port-Of: odoo/odoo#213501
This fix prevents checkout warnings when a customer's stored name contains trailing spaces, such as after an import. It also helps imported text fields stay clean by trimming unnecessary spaces when configured, reducing avoidable data quality issues.
Original PR description
**Steps to reproduce:** 1. Install the website_sale app. 2. Import a user with trailing spaces in the Name field. 3. Make this user Admin in settings 4. Log in with that user and go to Website >…
**Steps to reproduce:** 1. Install the website_sale app. 2. Import a user with trailing spaces in the Name field. 3. Make this user Admin in settings 4. Log in with that user and go to Website > Shop. 5. Click on new and create a new product 6. Add this product to the cart and proceed to checkout. 7. The checkout form pre-fills the name (with trailing spaces). 8. fill other fields 9. Submitting the form triggers a warning due to changed name. **Expected behaviour:** - Name is not changed by us so it should let us checkout - There should not be trailing spaces in imported char fields if trim attribute is true **Issue:** - The name field from the form is trimmed in post request, but the value from the database (with trailing spaces) is used during comparison This results in a false positive change detection. - User's name with trailing spaces is because of Imported records does not check for trim attribute in backend but this is handled in ui. **Solution:** - Trim the database value before comparing it to the form input - Trim the values of char field before importing if trim attribute is true opw-4794220
This fixes who can see the task count on project milestones so it follows the intended access group. It helps ensure project information is shown consistently to the right users without changing milestone functionality.
Original PR description
fix in version-18.0
This fixes an issue in Discuss calls where peer offer filtering was silently skipped because the app referenced the wrong internal store. The change helps call connection handling behave as intended without introducing visible workflow changes for users.
Original PR description
Before this commit, peer offer filtering was not working as the reference to the store was incorrect. This wouldn't cause tracebacks or known connection issues as the error was caught and the filter was just ignored.
CIS report values for materials and payments are now rounded down, as required by UK government guidance. This helps ensure submitted report figures match compliance rules and avoids small rounding discrepancies.
Original PR description
Before, a fix was done to round column for materials and payments columns but the method was HALF-UP. This should always be DOWN as specified here https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28 task-4881298
Urban Piper receipts now show the delivery identifier clearly in the receipt header when printed. This prevents staff from missing or misreading order delivery references due to overly light text.
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459
Task planned dates now display in a consistent MM/DD/YYYY format, including leading zeros for single-digit months and days. This makes deadlines easier to read and aligns the project task list with expected date formatting.
Original PR description
Step to reproduce: - install project_enterprise - open project -> open a task - add a deadline (start and end date) - return to my task - Observe the date format for tasks with Planned Date → Dates do not include leading zeros for single-digit days or months. Issue: The view uses the `condensed="True"` attribute on the daterange widget, which removes zero-padding from the date format. Fix: Remove the `condensed` attribute Before:  After:  opw-4844618
A payroll expense test setup was adjusted so reconciliation checks focus on the intended accounting entry. This helps prevent misleading test results and supports more reliable payroll expense handling after recent accounting changes.
Original PR description
This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270
See odoo/odoo#214960 (master) The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name. This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format. task-4815521 --- I confirm I have signed the CLA and read the PR
Original PR description
See odoo/odoo#214960 (master) The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name. This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format. task-4815521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215243
This commit aims to fix a random failure in the Spanish TBAI POS tour. We add a step to ensure that the selection popup is shown before clicking on the item "R1". runbot-112388 Forward-Port-Of: odoo/odoo#215198
Original PR description
This commit aims to fix a random failure in the Spanish TBAI POS tour. We add a step to ensure that the selection popup is shown before clicking on the item "R1". runbot-112388 Forward-Port-Of: odoo/odoo#215198
`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
If we are connected as a user that have only access to a branch company, we get an access error when trying to reconcile outstanding payment with an invoice. Steps to reproduce: - Create a branch company - Create user that has only access to branch - Log in with user - Create payment and invoice - From invoice form, try to reconcile payment with invoice Error raised -> Blaming "company rule employee" record rule OPW-4657488 --- I confirm I have signed the CLA and read the PR
Original PR description
If we are connected as a user that have only access to a branch company, we get an access error when trying to reconcile outstanding payment with an invoice. Steps to reproduce: - Create a branch company - Create user that has only access to branch - Log in with user - Create payment and invoice - From invoice form, try to reconcile payment with invoice Error raised -> Blaming "company rule employee" record rule OPW-4657488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207440
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after
Original PR description
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after PR is merged: No error was raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203171 Forward-Port-Of: odoo/odoo#196479
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213349 Forward-Port-Of: odoo/odoo#202832
Original PR description
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213349 Forward-Port-Of: odoo/odoo#202832
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#87196The _get_buget_items returns an empty dictionary when no analytic account is set, however the test is expecting a NONE value. This commits fixes it to match correctly. This error occurs only on 16.0 and in a single app mode. https://runbot.odoo.com/odoo/error/163195 Forward-Port-Of: odoo/enterprise#87525
Original PR description
The _get_buget_items returns an empty dictionary when no analytic account is set, however the test is expecting a NONE value. This commits fixes it to match correctly. This error occurs only on 16.0 and in a single app mode. https://runbot.odoo.com/odoo/error/163195 Forward-Port-Of: odoo/enterprise#87525
Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense. Now this is fixed as the closing balance should always be equal to the initial balance. Forward-Port-Of: odoo/enterprise#87419
Original PR description
Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense. Now this is fixed as the closing balance should always be equal to the initial balance. Forward-Port-Of: odoo/enterprise#87419
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
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