Monday, April 13, 2026
14 changes · 19.0
New functionality added to Odoo
This update introduces basic financial reports specifically tailored for Uzbekistan businesses. It includes essential reports like the Balance Sheet and Profit & Loss Report, enabling users to generate key financial statements in accordance with local accounting standards. This expands Odoo's capabilities to support the Uzbek market.
Original PR description
This commit introduces basic report package for Uzbekistan and includes Balance Sheet and Profit & Loss Report. task-3927927 Community PR - https://github.com/odoo/odoo/pull/241811
Enhancements to existing features
Module updates will no longer show unnecessary warning statuses when Odoo temporarily adjusts company-specific fields during the update process. The same checks still happen, but routine messages are moved to debug logs so healthy production branches remain green.
Original PR description
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the…
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet. But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine. Current behavior before PR: Logs may contain warnings such as: - Patching res.partner.ref with company_dependent=True - Patching product.template.sale_ok with company_dependent=True - Patching product.product.default_code with company_dependent=True even though there is no actual issue (ok normal behavior) The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine. Desired behavior after PR is merged: Keep the same mechanism, but lower the log level from WARNING to DEBUG. This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG. Having the production branches green. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258444 Forward-Port-Of: odoo/odoo#258326
Resolved issues and error corrections
Purchase order lines now keep the correct product name when users move between paginated order lines. This prevents confusion from products appearing under a vendor-specific name while still allowing searches by vendor code or vendor product name.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#258467 Forward-Port-Of: odoo/odoo#240515
Agents who are already participating in an active livechat can now still see the livechat button and start another conversation as a visitor. This removes a confusing limitation and helps users handle or test additional chats without losing access to the entry point.
Original PR description
Previously, users who were part of active livechats as agents could not see the livechat button to start a new conversation. This change ensures the button remains visible so users can start additional livechats as a visitor. task-[5119098](https://www.odoo.com/odoo/project/1519/tasks/5119098) Forward-Port-Of: odoo/odoo#258486 Forward-Port-Of: odoo/odoo#253894
Invoice line product names now appear in the language set on the selected invoice contact, even when that contact belongs to a parent company with a different language. This avoids confusing or incorrect labels on customer invoices in multilingual setups.
Original PR description
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not…
### Issue before this commit: When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language. ### Steps to reproduce the issue: 1. Activate at least 2 languages (X and Y) 2. Create a product and set the translation for that product in the activated languages 3. Create a Contact with the language X 4. Create a child contact (invoice adress type) for that contact with language Y 5. Create a new invoice setting the customer as the child contact 6. Add the product you created 7. See the label is displayed in the language of the parent contact ### Cause of the issue: The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language. ### Reason to introduce the fix: To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner. opw-5955875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258458 Forward-Port-Of: odoo/odoo#254833
Portal users can now use Search More on task fields such as Tags without encountering an error. The fix ensures task-specific filtering is only applied where it belongs, keeping shared project task editing smoother and more reliable.
Original PR description
Steps to reproduce: -------------------------- 1. Install Project and create a portal user. 2. Create a project and a task with tags added to it. 3. Share the project with the portal user (Edit…
Steps to reproduce:
--------------------------
1. Install Project and create a portal user.
2. Create a project and a task with tags added to it.
3. Share the project with the portal user (Edit access).
4. Log in as the portal user and open the task.
5. Click on the 'Tags' field and select 'Search More'
Issue:
----------
A traceback occurs:
```ValueError: Invalid field project.tags.display_in_project in condition ('display_in_project', '=', True)```
Cause:
----------
The [ProjectTaskRelationalModel](https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_relational_model.js#L4-L7) calls `_processSearchDomain.`
This method automatically appends a domain when 'showSubtasks' is not enabled.
https://github.com/odoo/odoo/blob/75fd7b05766c6789bf311f6a8257b89ecf4f86de/addons/project/static/src/views/project_task_model_mixin.js#L5-L12
When clicking 'Search More' on the 'Tags' field, the same domain is
applied to the **project.tags** model. However, since **project.tags**
does not have the `display_in_project` field, the ORM raises a ValueError.
In portal, only `project.webclient` assets are loaded, causing
ProjectTaskRelationalModel to be used for all relational fields.
In contrast, internal users use the standard RelationalModel, so the
issue does not occur.
Solution:
-------------
Restrict the domain modification in _processSearchDomain to apply only
when the current model is `project.task` and `report.project.task.user`.
opw-5930427
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249282This fix stops spreadsheet pivots from allowing grouping on field types they cannot handle, such as JSON fields. It prevents crashes when users build or edit pivot tables and adds test coverage to keep behavior consistent across field types.
Original PR description
Spreadsheet pivots only do not support all field types. But we were relying only on `field.groupable` to determine if a field could be grouped, which is wrong (eg. JSON fields can be groupable but are not supported). It leads to crashes for fields that were groupable, but didn't have an entry in `pivotNormalizationValueRegistry`. Added a test for all of the field types to ensure we have a correct behavior. Task: 6036075 Task: [6036075](https://www.odoo.com/odoo/2328/tasks/6036075) 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#255571
This fixes an automated manufacturing test so it no longer depends on an enterprise-only barcode manufacturing add-on. It helps keep community and non-enterprise build checks reliable without changing business workflows.
Original PR description
The test `test_basic_flow_with_minimal_access_rigths` fails in builds without `stock_barcode_mrp` since the `backorder_ids` mrp.production field is introduced in that module: https://github.com/odoo/enterprise/blob/92c584cc1426ac70f6f77aa8216c17004fa42d35/stock_barcode_mrp/models/mrp_production.py#L10 runbot-242465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shop product breadcrumbs now show a category that belongs to the current website, or a shared category, instead of picking a category from another website. This avoids customer confusion on multi-website stores and keeps navigation aligned with the site being viewed.
Original PR description
Steps to produce: --- - Install the `website_sale` module. - Go to `Website > Configuration > Websites` and create a new website, placing it first in the sequence to make it the default. - Create a…
Steps to produce: --- - Install the `website_sale` module. - Go to `Website > Configuration > Websites` and create a new website, placing it first in the sequence to make it the default. - Create a product and assign 2 eCommerce categories under the Sales tab. - Publish the product. - Go to `Website > eCommerce > Products > eCommerce Categories`. - Set Website 1 on Category 1 and Website 2 on Category 2. - Open the shop in an incognito tab, search for the product, and open it.t. Issue: --- - The breadcrumb displays an incorrect category, as the category selection logic does not filter out categories that are not linked to the current website (it should only consider categories assigned to the current website or no website). Solution: --- - Filter product categories to include only those linked to the current website or no website when resolving the breadcrumb category. opw-6039587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a misleading warning displayed during payslip generation when contracts partially overlapped with pay periods. The system now correctly handles overlapping contracts, ensuring users can generate payslips without unnecessary alerts. This improves the user experience and avoids potential confusion.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791A recent update to the Document module caused a problem where the server action view within the Odoo interface was broken, preventing users from accessing key features. This was due to an incorrect priority setting for the view, leading to the wrong view being displayed. This fix ensures the server action view functions correctly after the Document module is installed.
Original PR description
When the document module is installed, sometimes the server action view that is shown when accessing the server actions from the normal menu can be broken: the model field for instance is no longer visible, which makes the user interface unusable. <img width="723" height="412" alt="image" src="https://github.com/user-attachments/assets/73f6d516-77be-4f66-80dc-033fd8c0cb7c" /> This is because the document module defines a new primary form view for server actions, but does not set a priority for that view. As a result we have 2 primary views, with the same default priority of 16 in the database, and in that case the sorting of view can lead to the document specific view to be selected, when the other one is expected. We fix this by explicitly setting a priority of 32 on the form view in the document module.
This update resolves an issue where price changes within the Blackbox module were failing due to incorrect decimal separator handling in different user language settings. The fix ensures that price updates are now consistently applied regardless of the user's locale, improving the reliability of order pricing.
Original PR description
Before this commit, when changing the price of an orderline with the blackbox installed, if the decimal separator of the user language was not a dot and was used during the price change, the price was not changed. This was due to the fact that we were comparing a string with a number, the string would be implicitly be converted to a number and, when there was a comma for example, it would return a NaN which would cause the discount to not be applied and thus the price to not change. Forward-Port-Of: odoo/enterprise#113151
This update fixes a misleading warning in the payroll system related to contract dates and payslip periods. Previously, a warning appeared even with a slight overlap between the contract and payslip. Now, the system correctly handles overlaps, eliminating the unnecessary warning and improving user experience. This ensures accurate payroll processing.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update corrects a technical issue in the web_studio report editor where unwanted placeholders were automatically inserted between layout sections. This prevented reports from printing correctly, and the fix ensures that report sections are properly formatted for printing. The change addresses a bug related to how Odoo prepares reports for output.
Original PR description
… sections Before this commit, the html_editor automatically put placeholders between hearder, article and footer nodes (identified with classes) This is caused by odoo/odoo@edf7f7bb0c62978640c181eccb4934855d5d872d. This caused issues because at print time those cracks are not printed because of base/ir_actions_report.py:def _prepare_html (which separates header, footer, and articles to pass them to wkhtmltopdf) After this commit, those placeholders are not present in those cracks. opw-6048955