Friday, March 13, 2026
4 changes · saas-19.1
Enhancements to existing features
This update introduces a new button in the order management interface that allows users to quickly move all orders to the next stage of processing. When an order reaches the final stage, the preparation status is automatically marked as complete, improving workflow efficiency. This change simplifies order management and reduces manual effort.
Original PR description
In this commit: =============== - We added a `Clear All Orders` button in the sidebar. On clicking that, all the orders will be moved to their next respective stage. - If the order stage is already the last stage, then the order's preparation state is marked as done. Task: 5877460 Forward-Port-Of: odoo/enterprise#105847
This update enhances the Turkish localization for Odoo, specifically addressing issues related to invoice generation and VAT compliance. Key changes include mandatory fields for tax exemption reasons and improved handling of UBL invoice generation, ensuring accurate and compliant invoices for Turkish businesses.
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
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. This results in faster report generation times, improving efficiency for users.
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#110334
Forward-Port-Of: odoo/enterprise#109795This update streamlines the timesheet assistant by simplifying labels and UI elements, while also enhancing the accuracy of time calculations and resolving display issues. Key changes include restricting access to the billable status field and optimizing how project information is stored for better performance.
Original PR description
[IMP] {helpdesk,sale,project}_timesheet_{,enterprise,forecast}: timesheet assistant generic improvements
In this Commit,
- Assistant Form > "Billable" boolean hidden for users without Sales access rights
- Assistant Form > Labels updated:
- "Project Name" → "Project"
- "Task Name" → "Task"
- "Time Spent" → "Time"
- "Save Changes" → "Save"
- Assistant Form UI Improved by applying same changes done in master,
REF: https://github.com/odoo/enterprise/pull/104347
- Assistant Form > create and edit option removed for projects
- Suggestions logic reviewed for better results
- Correct time calculation for chronological grouping
- Unmatched project display issues resolved in both suggestions and local config
- Local Config List view aligned with Odoo UI views
- Local Config Storage limited to project/task/ticket IDs instead of `display_name`
and `id`
task-5902077