Daily updates from Odoo
Monday, June 16, 2025
9 changes
1 change
Resolved issues and error corrections
Fixes an issue in Odoo Studio where clearing the Default Group By field could cause an error and leave the view stuck loading. Users can now remove this setting safely without interrupting their workflow.
Original PR description
A `ValueError` occurs when we set and remove values `Default Group By` in terminal when you click the cross button multiple times the view gets stuck in infinite loading screen. **Steps to reproduce:** * Install `web_studio` and `inventory` with demo data * Inventory>Toggle Studio button>View * Select any value in `Default Group By` and remove it using cross button. `ValueError: Invalid field 'None' on model 'stock.picking.type'` **Solution:** * The Javascript is passing null value instead we pass an empty string. **Sentry-6618531530**
8 changes
Resolved issues and error corrections
Some mail conversation data can occasionally reference a participant whose contact profile is no longer available in the browser. This fix skips those incomplete entries when identifying the conversation counterpart, preventing unnecessary crashes and keeping messaging usable.
Original PR description
There are several flows where the persona of a member might not (or no longer) be known in JS. These members should simply be ignored when computing the correspondent of a channel rather than crashing.
Reversed point-of-sale orders in the Indian localization now receive the correct place of supply information. This helps ensure tax and compliance details remain complete when POS orders are reversed.
Original PR description
Before this commit: - The `_compute_l10n_in_state_id` method only considered `pos_session_ids` when assigning the state for Indian POS moves. - Reversed POS orders were ignored, leading to missing `l10n_in_state_id`. After this commit: - Added `reversed_pos_order_id` to the `@api.depends` decorator. - Updated domain to include moves with `reversed_pos_order_id`. Ensures correct place of supply is computed for reversed POS orders as well. OPW: 4862639
This fix makes an automated website event test wait until editing is properly finished before moving on. It reduces random test failures caused by timing differences, helping keep quality checks stable without changing customer-facing behavior.
Original PR description
The test `test_website_event_tour_admin` fails randomly depending on the processing speed available. When clicking on `a[title='Back to All Events']`, if the website happens to still be in edit mode, the click will be prevented: https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438 We can use the clickOnSave function made specifically for this. It ensures exiting edit mode before continuing. --- runbot-223022
This fix prevents errors when an invoice line is linked to multiple sales order lines. It uses the analytic distribution from the first linked sales line so invoice creation can continue reliably.
Original PR description
In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
Original PR description
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
This fix makes work order duration calculations ignore tiny microsecond differences when recording productivity time. It prevents occasional test and rounding failures caused by insignificant timing fluctuations, improving reliability without changing business workflows.
Original PR description
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start` of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test. To fix it, we simply set the microsseconds of the end date to zero. This bug was introduced in: https://github.com/odoo/odoo/pull/80319/commits/15fef27edb3ec437d1dbec33481c5d778795bc59 Runbot failure example: https://runbot.odoo.com/odoo/runbot.build.error/226657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users trying to fetch a Shopee shipping label for a delivery that is not connected to a Shopee shop will now see a clear error message instead of a technical crash. This helps staff understand what is wrong and prevents confusing system tracebacks during shipping operations.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery order with one unit of P1, not linked to any sale order
- Go to the delivery order list view
- Select the created delivery order
- Click on Action → Fetch shipping label
Problem:
A traceback is triggered:
```
ValueError: ValueError('Expected singleton: shopee.shop()') while
evaluating
'records._fetch_shipment_label()'
The above server error caused the following client error:
```
The `_fetch_shipment_label` function expects at least one item, but
we don't check it via a user error, because we're supposed to call
`_sync_shopee_pickings` instead, where all these filtering and checks
are done
opw-4812360The Data Cleaning module now uses a unique identifier for its model form, preventing it from being overwritten during installation. This ensures the expected configuration screen is available and avoids missing setup options for users.
Original PR description
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning…
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418