Daily updates from Odoo
Thursday, March 12, 2026
14 changes
4 changes
Enhancements to existing features
This update adds a barcode (GTIN) to product data within our website, enhancing its visibility on search engines like Google. This change improves SEO and ensures compliance with Google Merchant Center guidelines, ultimately driving more traffic and sales.
Original PR description
Include the barcode (GTIN) in product micro-data to improve SEO indexing and comply with Google Merchant Center requirements. Added gtin property to the JSON-LD metadata in product.product. Affected Version: 19.0 Task: 5953441 Forward-Port-Of: odoo/odoo#252823
This update enhances the accuracy of leave accrual calculations within the payroll system by ensuring proper tracking of leave requests and addressing potential date format issues. It also includes security enhancements to restrict access to tracking data and improves the generation of work entries for leaves, resolving a previous bug.
Original PR description
Accrual is computed based on tracking values, checking added or removed leaves in a given request, based on their datetimes. This feature does not seems tested currently, so let us cover it. That way we ensure future changes in tracking model do not break current feature. By the way, fix an ACL issue when trying to access tracking values and not being admin. By the way, fix date / datetime issue when generating work entries. By the way, fix leaves support when generating work entries. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com> Forward-Port-Of: odoo/enterprise#110302
This update simplifies the partner list by adding a direct 'unselect' button whenever a partner is selected. Previously, users had to hover to remove a selected customer, which was confusing and inefficient. This change improves usability and ensures partners can be easily removed from the list.
Original PR description
Before this commit: ==== - Initially if partner is selected then hovering over partner shows option to remove the partner, until user won't be able to get how to remove the customer if selected. - Not good from user perspective. Following this commit: ==== - Unselect button will be shown everytime instead of hovering if partner is selected so that when user open the partner list, user can easily unselect the partner. task-5945904 Forward-Port-Of: odoo/odoo#249405
This update enhances the Turkish localization for Odoo, specifically addressing invoicing and VAT compliance. Key changes include mandatory fields for tax exemption reasons and shipping methods, as well as fixes for error messages and UBL generation to ensure accurate VAT reporting and improved invoice processing.
Original PR description
This commit adds the following improvements and bug fixes to the turkish localization: - Make shipping method required for GiB export invoices - Make Exemption Reason mandatory when Invoice Type is Tax Exempt - Ensure Invoice Type is selected when Invoice Scenario is set - Hide the nilvera send status for Vendor Bills - Adjust the error message for missing CTSP numbers on invoice lines - Allow resetting Vendor Bills to draft - Give priority to the currency rate on the invoice when generating UBL - Create a new bridge module to bypass the VAT validation for test VAT numbers - Fix bug in bulk customer verification task-5868201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249247
1 change
Enhancements to existing features
This update enhances the testing of accrual calculations within the US HR Payroll module, ensuring accurate leave tracking. It also addresses a security issue by granting access to tracking values to non-admin users, allowing for broader use of this functionality. This improves the reliability and flexibility of payroll calculations.
Original PR description
Accrual is computed based on tracking values, checking added or removed leaves in a given request, based on their datetimes. This feature does not seems tested currently, so let us cover it. That way we ensure future changes in tracking model do not break current feature. By the way, fix an ACL issue when trying to access tracking values and not being admin. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com> Forward-Port-Of: odoo/enterprise#110302
1 change
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that caused performance issues with large datasets, resulting in faster report generation times. This improvement focuses on efficiency and scalability for handling substantial amounts of financial data.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#1097951 change
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. The original query was slow due to a complex sub-query, which has been simplified. This results in faster report generation, particularly when dealing with large volumes of data.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#1097955 changes
Enhancements to existing features
This update simplifies the Data menu within the Enterprise edition of Odoo. Previously, a large number of data sources resulted in a cluttered and difficult-to-navigate menu. Now, data sources are grouped into submenus – List and Charts – making it easier for users to find the information they need.
Original PR description
## Description When a spreadsheet contains many data sources, the Data menu becomes too long and harder to scan. This changes enterprise data source entries from a flat list into grouped submenus: - Data -> List -> item_list_* - Data -> Charts -> item_chart_* Task: [5948385](https://www.odoo.com/odoo/project/2328/tasks/5948385)
This update allows users to print receipts directly from a USB printer, eliminating the need for a network connection or IoT Box. This improves usability for locations without reliable network access and provides a more flexible printing solution.
Original PR description
Expand POS printing capabilities so that the client can detect and use a local USB printer (via `window.printer`) without requiring any network printer or IoT Box setup. This allows users to rely solely on a directly connected USB printer for receipt printing. - Extend PosStore to instantiate a new `LocalPrinter` when `window.printer.printReceipt` is available. - Introduce LocalPrinter class to handle: printer setup, vendor/product ID retrieval, sending jobs to the local printer with fallback on failure. Task:5368831
This update focuses on improving the testing and tracking of accrual calculations within the US HR Payroll module. Adding dedicated logs and comprehensive tests ensures the accuracy of payroll processing, particularly as the underlying value model may evolve. This strengthens the reliability of the system.
Original PR description
This code does not seems tested currently, so let us cover it as tracking value model may change in a near future. Task-
This update enhances the search capabilities within pay runs, allowing users to filter by pay structure and employee name in addition to existing date ranges. The changes include a new user interface tour to demonstrate the improved search process, ensuring easier and more accurate pay run identification. This improves payroll efficiency and reporting.
Original PR description
Default search is extended with the month name of date_start and date_end + year of date_start and date_end. Other searches are added for structure name and employee's name task - 5925528
This update simplifies the process of entering Belgian employee addresses within the HR payroll system. By replacing separate ZIP and city fields with a combined 'Postal Code or City' dropdown, and removing the state field, we've improved the user experience for Belgian employees. This change ensures data accuracy and aligns with Belgian address requirements.
Original PR description
To improve UX, when Belgium is selected, replace the ZIP and city fields with a single "Postal Code or City" dropdown and hide the state field, which is not required in a Belgium address. Implementation: - Added `res.city` data for Belgium sourced from Bpost. - Added `l10n_be_private_city_id` to `hr.employee` and `hr.version` to handle the selection in the backend. - Overrode `create` and `write` to ensure standard `private_zip` and `private_city` fields are synced for compatibility with existing logic. - Created a public RPC endpoint to allow the salary configurator (which has no direct ORM access) to fetch these cities. - Patched the `SalaryPackage` JS interaction to dynamically toggle field visibility and manage the combined input. task-5882118
1 change
Enhancements to existing features
This update enhances the payroll accrual calculation by adding thorough testing to ensure future changes don't break the system. It also resolves a security issue, granting access to tracking values (used for accrual calculations) to non-admin users, while maintaining data security.
Original PR description
Accrual is computed based on tracking values, checking added or removed leaves in a given request, based on their datetimes. This feature does not seems tested currently, so let us cover it. That way we ensure future changes in tracking model do not break current feature. By the way, fix an ACL issue when trying to access tracking values and not being admin. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com>
1 change
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that was causing performance issues with large datasets. This results in faster report generation times, improving efficiency.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#109795