Tuesday, April 28, 2026
24 changes · 19.0
New functionality added to Odoo
This pull request adds new language translations for two Odoo modules: `documents_project_sign` and `l10n_eg_iot`. These updates improve the software's support for different languages, ensuring a better user experience for international customers and users.
Original PR description
- Added `documents_project_sign` - Added `l10n_eg_iot` Related: https://github.com/odoo/odoo/pull/261628
Enhancements to existing features
Automated CRM lead generation emails now come from noreply@odoo.com instead of iap@odoo.com. This helps prevent customers from replying to an unattended or inappropriate service address and makes the automated nature of the message clearer.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/odoo#260794 Forward-Port-Of: odoo/odoo#259691
Resolved issues and error corrections
This fix updates an automated restaurant point-of-sale test so it waits for order syncing before changing the customer. It prevents false test failures caused by very fast test steps rather than actual user-facing issues.
Original PR description
In the tour test_customer_alone_saved, the test was creating an order, then go on the ticket screen and then come back on the product screen to change the customer to go again on the ticket screen and come back on product screen to check that the customer did not changed. The problem was that when going to the ticket screen the first time, the order was synced with the server but the answer might come after the test changed the customer. When going the second time on the ticket screen, the order was changed with the information of the backend and the user was lost. This is all due to the test that are too fast. runbot-error: 238467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253587
Miscellaneous changes
- Added `l10n_vn_edi_viettel_pos` - Removed `project_mrp_sale` (no terms left) Related: https://github.com/odoo/enterprise/pull/115424 Forward-Port-Of: odoo/odoo#261555
Original PR description
- Added `l10n_vn_edi_viettel_pos` - Removed `project_mrp_sale` (no terms left) Related: https://github.com/odoo/enterprise/pull/115424 Forward-Port-Of: odoo/odoo#261555
Point of Sale invoice reports now add spacing between the Source Invoice and Reference fields. This prevents long invoice names from visually running into nearby information, making reports easier to read.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users are now prevented from using a Danish CVR number with the “DK” country prefix when setting up Nemhandel. This avoids incorrect identifiers and replaces confusing downstream errors with a clear validation message.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - An error is raised if the CVR contains the 'DK' country code prefix, to ensure the correctness of the Nemhandel identifier. Task: 5449059
This update improves how automated test tags are identified during nightly checks, reducing the risk of accidentally disabling a broad set of web tests. It helps keep quality checks more accurate and safeguards ongoing release stability.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests. Forward-Port-Of: odoo/odoo#261618 Forward-Port-Of: odoo/odoo#261526
The Bills of Materials form no longer allows quick creation of a product variant from that field. This prevents users from accidentally creating a separate, unrelated product when they intended to choose a variant of the selected product.
Original PR description
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create".…
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create". Issue: --- Using quick create on the Product Variant field does not create a variant of the selected product template. Instead, it creates a completely new, unrelated `product.template`. This is because the `create()` method on `product.product` is overridden to call super() with context `create_product_product=False`, which suppresses direct variant creation and forces creation through `product.template` instead, see [1]. **Why passing `default_product_tmpl_id` does not help:** One might expect that passing `default_product_tmpl_id` in the field context would cause the newly quick-created `product.product` to be linked to the already-selected `product.template`. However, because of the `create()` override above (introduced in [commit]), the variant creation is always redirected to `product.template`, ignoring any `default_product_tmpl_id` passed in context. It is therefore not possible in any case to quick-create a `product.product` that is correctly and directly linked to the currently selected `product.template`. Fix: --- Disable the "Create" and "Create and Edit" options. Since there is no way to quick-create a `product.product` that is correctly linked to the currently selected `product.template`, the user must create the variant directly on the product template first. [1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368 [commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8 opw-6127738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261316 Forward-Port-Of: odoo/odoo#259776
This fixes an accidental rollback in the Ecuador localization data that caused automated checks to fail. Restoring the intended tax data changes helps keep Ecuador accounting setup reliable and prevents release validation errors.
Original PR description
Somehow commit https://github.com/odoo/odoo/commit/ef3b9f6b731b104027fcee9e83a5f2f4fc544f16 reverted the changes introduced by https://github.com/odoo/odoo/pull/257513/changes causing tests to fail. runbot error 243401 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
This fix removes an incorrect default account setting in the Bangladesh localization that caused unwanted stock variation journal entries. Businesses using the Bangladesh chart of accounts will get inventory accounting behavior that better matches local expectations.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi invoice printouts now show the company tax number only once. This prevents duplicated information on customer-facing invoices and keeps documents cleaner and more accurate.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once
Quotation templates used from a task will no longer attach the task to section or note lines. This prevents unnecessary links on non-product lines and avoids errors when completing related tasks.
Original PR description
When a sales order is created from a task, if a template is used, the first line is given a task ID from the context's default_task_id. If this first line were to be a non-product line (section/note), this would still be given a task_id. This is unneeded and can cause issues such as a float precision error when trying to mark the task as done. This change checks to see if the line has a display_type, in which case it will set the task_id to false. Steps to reproduce: 1. Create a new Quotation Template with a single section line 2. Create a new project 3. Open the project settings 4. Enable 'Billable' and 'Extra Quotations' 5. Create a new task 6. Select 'New Quotation' 7. Select the quotation template with just a section 8. Enter customer (to allow saving) 9. There will be a single order line, a section, with a task_id opw-6122235
This update adjusts the bank statement reconciliation process within Odoo Enterprise to better align with accounting regulations. Specifically, it prevents statement lines from being automatically marked as reconciled when the 3% rule applies, ensuring accurate financial reporting. This improves the reliability of financial data.
Original PR description
POC no task id
This change updates the email address used for automated support notifications from iap@odoo.com to noreply@odoo.com. This ensures that client responses to support emails are correctly directed to the appropriate team, improving response times and support efficiency.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update corrects a mismatch in transaction identifiers used when generating financial reports (FAIA export) for Luxembourg. Previously, the system used different identifiers, leading to potential reporting errors. This change ensures all transaction IDs align, improving the accuracy and reliability of financial data.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
This update resolves an issue where incorrect string comparisons were occurring within the l10n_co_dian module. The fix ensures accurate data processing for the Colombian Dian tax reporting system, preventing potential errors and ensuring compliance. This change improves the reliability of the Dian localization functionality.
Original PR description
Issue: commit 780b12ca7e2525bfa86f00d232fa9f186c914a85 introduced incorrect string comparison opw-6077050
This update allows administrators to control when subscription users are automatically reset. Previously, this process was automatic and couldn't be altered. This change provides greater flexibility in managing subscription accounts and ensures alignment with business processes.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update fixes a bug that prevented users from changing the state of tax returns within the accounting dashboard. Previously, attempting to use an invalid state would cause the page to crash. This change ensures the system handles state transitions correctly, improving the reliability of tax return management.
Original PR description
Before this commit, if you were to change the states_workflow to from a some that had an option, such as submitted, to something that did not contain a state that an account_return does not have, you would crash when trying to load the page. To get to this page go to the accounting dashboard and click on the tax returns option. To change the states_workflow change go to accounting -> configuration -> return types and change the states variable. opw-6107995
This update resolves an issue where portal users were incorrectly seeing the 'View Timesheets' button, even when they lacked the necessary permissions. The fix utilizes a new helper method to accurately control button visibility, ensuring users only see options they are authorized to access. This improves the user experience and prevents confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481
This update corrects a potential error in the account reports module where custom modules could cause conflicts when referencing the 'state' column. By explicitly using column aliases, the system now correctly identifies and resolves ambiguous column references, ensuring reports run smoothly across all client configurations.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The fix also includes a minor typo correction within the equity views.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343
This update corrects a technical issue where styling applied to a list view was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list view, improving the visual consistency of reports. This resolves a minor cosmetic problem.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685
This update resolves an issue where time off allocations couldn't be deleted after a payslip was validated. The fix adjusts the system to recognize that time off created *after* payslip validation can be safely deleted, removing a previous restriction. This improves usability for HR and payroll teams.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990This update resolves an issue where payroll document validation incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a company-dependent field with a stored employee flag, ensuring accurate validation during background tasks like payroll generation. This prevents errors and ensures proper document access.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti)