Friday, June 27, 2025
11 changes · 18.0
Resolved issues and error corrections
A typo in a Belgian tax data value was corrected from an invalid-looking decimal format to the intended value. This helps ensure Belgian localization tax setup data is accurate and avoids confusion or potential configuration issues.
This update makes Odoo’s automated guided tests more predictable when a test action changes or reloads a page. It also prevents downloads from incorrectly triggering page-exit behavior, reducing false test failures and improving release confidence.
Original PR description
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
Exports now use the correct translated display value for selection fields whose options are generated by a function. This prevents users from receiving raw or incorrect values in exported files, improving data accuracy for multilingual exports.
Original PR description
Whenever selection field have the any function in selection value at that time while export it not export associated language ``value``. For Fixing this, according to [this](https://github.com/odoo/odoo/blob/a7a5470596b1d08311d87931c0ef24217087f729/odoo/fields.py#L2960) adding this condition to get the correct values. opw-4882812 upg-2985436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale receipts now show the cashier who completed the payment, even if the cashier was changed during checkout. This ensures receipts accurately reflect who served the customer and avoids confusion in cashier tracking.
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038
Product units of measure are now hidden across inventory, manufacturing, sales, purchasing, and point of sale screens when the Units of Measure feature is turned off. This reduces unnecessary information and avoids confusion for users who do not use multiple units.
Original PR description
**Description of the issue/feature this PR addresses:** Should not show product uom when the feature "Units of Measure" is not activated  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where empty text or chart fields in spreadsheet list formulas could appear as a false value instead of being blank. Business users will see cleaner and more accurate spreadsheet reports when list data contains empty fields.
Original PR description
Following the fix in d927a7b6, we broke the default behaviour of empty text/chart fields. While the server returns the value `false` when they're empty, we want to display an empty string in the `ODOO.LIST` formulas. Task-4897690 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
This fix prevents an unnecessary warning from interrupting setup or upgrades when purchase requisitions look for a receiving operation type that is inactive. It helps companies complete module installation or database upgrades more reliably without being incorrectly redirected to create a warehouse.
Original PR description
Fixed an issue in ```_default_picking_type_id``` where a missing picking type triggered a ```RedirectWarning``` due to an incorrect domain in the ```search``` Hence disabled `active_test` context to…
Fixed an issue in ```_default_picking_type_id``` where a missing picking type triggered a ```RedirectWarning``` due to an incorrect domain in the ```search``` Hence disabled `active_test` context to ensure proper fallback behavior.
```sql
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1328, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 604, in init_models
model._auto_init()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3468, in _auto_init
new = field.update_db(self, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3215, in update_db
return super(Many2one, self).update_db(model, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1090, in update_db
self.update_db_notnull(model, column)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1142, in update_db_notnull
model._init_column(self.name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3384, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/18.0/addons/purchase_requisition_stock/models/purchase_requisition.py", line 13, in _default_picking_type_id
self.env['stock.warehouse']._warehouse_redirect_warning()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_warehouse.py", line 172, in _warehouse_redirect_warning
raise RedirectWarning(msg, warehouse_action.id, _('Go to Warehouses'))
odoo.exceptions.RedirectWarning: ('Cree un almacén para la empresa Navieras Internacionales, S.A. (Navinter).', 464, 'Ir a los almacenes', None)
```
```sql
depr_2982092=> select id,name,active,company_id,warehouse_id from stock_picking_type where code = 'incoming' and active = 'f' order by company_id;
id | name | active | company_id | warehouse_id
----+----------------------------------------------------------------------------------------------------+--------+------------+--------------
6 | {"en_US": "Devoluciones"} | f | 1 | 1
67 | {"en_US": "Recepciones", "es_GT": "Recepciones"} | f | 1 | 12
72 | {"en_US": "Devoluciones", "es_GT": "Devoluciones"} | f | 1 | 12
1 | {"de_DE": "Anlieferungen", "en_US": "Recepciones", "es_GT": "Recepciones", "nl_NL": "Ontvangsten"} | f | 1 | 1
(4 rows)
```
OPW - [4869238](https://www.odoo.com/odoo/project/70/tasks/4869238?debug=1)
UPG - [2982092](https://upgrade.odoo.com/odoo/upgrade.request/2982092)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prBranch users who have access to a parent company can now open the Profit and Loss report when journals use a different company currency. The change prevents an unnecessary access error while preserving normal permission limits.
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455
Spreadsheet dashboards now treat creation date filters as date-and-time values, so results correctly reflect each user's timezone. This prevents dashboard filters from including or excluding the wrong records when dates are used.
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362Creating a spreadsheet in a Documents folder no longer fails when one of the folder's internal editor members has been archived. This prevents unnecessary validation errors and keeps document workflows working even when former employees remain listed on folders.
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693
The Colombian e-invoicing mandate module now explicitly includes a required dependency, preventing setup or usage errors when that related component is not present. This improves reliability for new installations, though existing databases are not automatically changed.
Original PR description
l10n_co_edi_mandate depends on l10n_co_dian, however this dependency wasn't set directly, relying on l10n_co_dian being auto-installed with l10n_co_edi which is a direct dependency. As such, errors could occur if user manually uninstalls l10n_co_dian. This fix addresses the issue for new installations, however existing databases won't be affected. See odoo/enterprise#77673