Monday, November 3, 2025
2 changes · 19.0
New functionality added to Odoo
This update extends Türkiye’s Nilvera e-invoicing support to cover additional legally required invoice scenarios, including withholding VAT, tax exemptions, exports, and public sector cases. It also adds the required tax office information to invoices, helping businesses stay compliant with local regulations.
Original PR description
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We…
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We do not support Withholding VAT (KDV Tevkifatı), Exemption Invoices, and Export Invoices (İhracat Faturaları) with our current e-invoicing solution in Türkiye. Those invoice types are legally important and required for both domestic and international sales for businesses. In addition, the inclusion of the Tax office in our current XML we send to Nilvera, both for `<cac:AccountingSupplierParty>` and `<cac:AccountingCustomerParty>`, is required by law. This PR adds an extension module for Nilvera E-Invoicing. The purpose of this module is to extend the existing E-Invoicing functionality to support additional invoice types and scenarios to be compliant with the TR legal requirements. --- ### Invoice Scenario: **Basic** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export **Export** Invoice Type: - Tax Exempt **Public** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export --- ### Current behavior before PR: We don't support a scenario-based system to comply with TR legal requirements. --- ### Desired behavior after PR is merged: We support a scenario-based system to comply with TR legal requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229344 Forward-Port-Of: odoo/odoo#213766
Enhancements to existing features
This change removes extra processing from the Recruitment app when opening job views, which makes pages load significantly faster and reduces the amount of data sent to the browser. It also keeps the earlier behavior fix so users are matched correctly even when a company is not set, while keeping an old field available for compatibility.
Original PR description
Description ----------- The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they…
Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.
This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.
Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.
This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.
⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.
Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:
| | Before | After | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time | 400ms | 160ms | 2.5x |
| Frontend process time | 3.3s | 220ms | **15x** |
| Total (LCP) time | 3.7s | 380ms | 9.7x |
| Response Payload size | ~800KiB | ~33KiB | **24x** |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232354