Tuesday, March 17, 2026
11 changes · 17.0
New functionality added to Odoo
This update incorporates the Slovakian PEPPOL code (0245) into the Odoo accounting system. This is necessary to comply with European regulations regarding electronic invoicing and data exchange through the PEPPOL network, specifically for businesses operating in Slovakia. The change supports secure and standardized financial transactions.
Original PR description
- Added new code Information: https://docs.peppol.eu/poacc/self-billing/3.0/v3.0.1/ https://docs.peppol.eu/edelivery/codelists/v9.5/Peppol%20Code%20Lists%20-%20Participant%20identifier%20schemes%20v9.5.html OPW-6017742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a technical issue in Odoo's testing environment related to the demo certificate for Peru's electronic invoicing (PE) requirements. The certificate's lifespan was extended by ten years to ensure accurate testing and compliance with evolving regulations. This change ensures the demo certificate remains valid for future testing scenarios.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058
This update corrects a technical issue where Avatax settings weren't correctly identifying the company they were associated with. Adding the missing 'company_dependent' key ensures Avatax data is accurately linked to the correct company within Odoo. This improves the reliability of Avatax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. task-none
This update resolves a technical issue that caused the restaurant order tour to fail. The fix ensures the system waits for order updates to complete before proceeding, preventing duplicate order transmissions and improving the reliability of the test. This ensures a smoother experience for users placing restaurant orders.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846
This update resolves an error message that appeared when exporting payroll data to SDWorx for freelance employees. The change ensures that the system doesn't flag missing SDWorx codes for freelancers, streamlining the export process and preventing user confusion. This improves the user experience for our Belgian clients.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342
This update corrects a display issue where the 'Relationship' field was incorrectly shown to employees outside of India. The fix ensures that this field is only visible for employees associated with Indian companies, aligning with local tax regulations and improving data accuracy.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees linked to non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888
This update resolves an issue where header border widths were inconsistently applied, leading to unexpected full borders. The change standardizes border width input to a single value for typical headers, while still allowing full borders for specific templates. This ensures a consistent and predictable appearance across the website.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516
This update corrects a problem where the `auth_oauth` module left a user field in a list after uninstall, causing errors when other modules tried to read that field. The fix ensures the field is properly removed during uninstall and resolves this issue across all Odoo databases, regardless of installation location.
Original PR description
At install, the `auth_oauth` module adds `oauth_access_token` to the constant list `base.models.res_users.USER_PRIVATE_FIELDS`. At uninstall, it doesn't get removed automatically, it stays in the…
At install, the `auth_oauth` module adds `oauth_access_token`
to the constant list `base.models.res_users.USER_PRIVATE_FIELDS`.
At uninstall, it doesn't get removed automatically,
it stays in the list until a server restart or a worker
reload.
This causes problem when other/custom modules also add fields
to this `USER_PRIVATE_FIELDS` and then perform a read
with one of these private fields.
in `odoo/addons/base/models/res_users.py` in the method `def _fetch_query`
`self.env.cache.update(records, self._fields[fname], repeat('********'))`
raises a crash as it tries to access `self._fields['oauth_access_token']`
while it no longer exist.
Actually it's also a multi-tenant problem: If one database installs the
`auth_oauth` module on the server, `oauth_access_token` is added to the list
`USER_PRIVATE_FIELDS` for all databases, not just the one which installed
the `auth_oauth` module.
The solution is to convert this list with a property method,
and override that property method in `auth_oauth` to add
`oauth_access_token` when the module is installed.
It also solves the multi-tenant issue.
Steps to reproduce:
- Use this diff to add temporary a private field
```diff
diff --git a/odoo/addons/base/models/res_users.py b/odoo/addons/base/models/res_users.py
index 2c8da7ec529c..ac973205e6ef 100644
--- a/odoo/addons/base/models/res_users.py
+++ b/odoo/addons/base/models/res_users.py
@@ -87,7 +87,7 @@ class CryptContext:
# Only users who can modify the user (incl. the user herself) see the real contents of these fields
-USER_PRIVATE_FIELDS = []
+USER_PRIVATE_FIELDS = ['login']
MIN_ROUNDS = 600_000
concat = chain.from_iterable
```
- Start the server, preferably in threaded mode rather than worker mode
- Then, in the web interface, install and uninstall `auth_oauth`
- Then, using RPC, do a read on `res.users` with `login` as field
```py
import xmlrpc.client
URL, DB, UID, PASSWORD = 'http://localhost:8069', '17.0', 6, 'demo'
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(URL))
print(models.execute_kw(DB, UID, PASSWORD, 'res.users', 'read', [[1], ['login']]))
```
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2410, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1985, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 153, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2013, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2217, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 799, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 25, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 21, in _call_kw
return call_kw(Model, method, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 484, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 469, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 1913, in read
res = super(UsersView, self).read(other_fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 645, in read
return super(Users, self).read(fields=fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3583, in read
self._origin.fetch(fields)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 551, in _fetch_query
self.env.cache.update(records, self._fields[fname], repeat('********'))
KeyError: 'oauth_access_token'
```
opw-6042456This update resolves an issue where Odoo servers couldn't start if certain modules (marked as 'uninstallable = False') had older versions than the current Odoo release. The fix prevents Odoo from incorrectly checking module versions during startup, ensuring a smoother and more reliable server launch. This improves stability and reduces potential downtime.
Original PR description
Description of the issue/feature this PR addresses: If we have a module with instalalble = False on the manifest and an older version, for eg "16.0.1.0.0", odoo server can't start due to version check Current behavior before PR: Can't start odoo server if there are modules with "instalalble = False" and version info with different major version included, for eg "16.0.1.0.0" Desired behavior after PR is merged: Odoo server starting ok --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where CFDI invoices were incorrectly displaying '99 - False' instead of '99 - Por definir' on reports. The fix ensures that archived payment method 99 is properly retrieved, resulting in accurate reporting for Mexican tax compliance. This ensures invoices generated with the mx company are correctly formatted.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655