Daily updates from Odoo
Friday, June 19, 2026
20 changes · saas-19.2
New functionality added to Odoo
This update incorporates support for the states of Tajikistan, Turkmenistan, Kyrgyzstan, Armenia, and Kazakhstan, aligning with international ISO 3166-2 standards. This change improves data accuracy and consistency by displaying state names instead of codes within address fields. This update is considered an improvement for our global user base.
Original PR description
Added the states of Tajikistan, Turkmenistan, Kyrgyzstan, Armenian, and Kazakhstan to align with official ISO 3166-2 standards. In addition change their address format of the country to show state name instead of state code. task-6237707 task-6237595 task-6237473 task-6237440 task-6237284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269091
Resolved issues and error corrections
This update fixes an error in the Luxembourg localization settings, ensuring the correct stock valuation account (301 Inventories of raw materials) is used instead of an expense account (60761 Merchandise). This ensures accurate financial reporting for Luxembourg businesses using Odoo.
Original PR description
**Problem:** Valuation account for luxembourg is currently 60761 Merchandise which is incorrect because it's an expense account. We should rather use a current asset account like 301 Inventories of raw materials **Steps to reproduce on a fresh db:** - create a new db with modules stock_account and accountant (without demo data) - On the 'fiscal localization setting' set the package as 'Luxembourg' and save - ativate the automatic accounting setting **Current Behavior:** The 'stock valuation account' appearing below the automatic accounting setting is : 60761 Merchandise **Expected behaviour:** It should be 301 Inventories of raw materials Forward-Port-Of: odoo/odoo#270048 Forward-Port-Of: odoo/odoo#269469
This update fixes a bug that prevented customers from removing free shipping rewards once they were applied to their cart. The issue stemmed from a technical limitation in how the system handled different reward types. Now, customers can successfully remove free shipping and free product rewards from their carts, improving the user experience.
Original PR description
Steps to produce: --- - Install `website_sale_loyalty`. - Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`. - Create a new discount & loyalty program > set program type as `promotions`. -…
Steps to produce: --- - Install `website_sale_loyalty`. - Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`. - Create a new discount & loyalty program > set program type as `promotions`. - Under Rewards, select `Free Shipping` as the reward type. - Create a product with a price of 1000 and publish it. - Add the product to the cart from the website. - Observe that free shipping is automatically applied on cart. - Attempt to remove the free shipping reward from the cart. Issue: --- - Free shipping (and similarly, free product rewards) cannot be removed from the cart once applied. Root cause: --- - At [1], the `website_sale_loyalty_delete` context is only passed when the reward type is `discount`. As a result, for free shipping and free product rewards, the context is not set. At [2], the order line is removed, but the reward is not added to `disabled_auto_rewards`. The `_auto_apply_rewards` method runs immediately afterward, detects the missing reward, and re-applies it automatically. Fix: --- - Since there are three reward types (discount, free shipping, and free product), the condition restricting the context to only discount rewards should be removed. [1]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order.py#L179 [2]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order_line.py#L15-L23 opw-6159288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261732
This update resolves an issue that prevented website upgrades when using custom themes. Specifically, the system failed to find a necessary theme file, causing an error during the upgrade process. This fix ensures that website upgrades work correctly with custom themes.
Original PR description
After commit 3cbaad4, the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose…
After commit 3cbaad4,
the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose code is not present in the addons path, `Manifest.for_addon()` returns `None` and `_generate_primary_snippet_templates` raises an `AttributeError`:
```py
2026-06-16 03:27:47,155 24126 INFO db_4367932 odoo.modules.loading: loading website/views/new_page_template_templates.xml
2026-06-16 03:27:47,803 24126 WARNING db_4367932 odoo.modules.module: module theme_prime: manifest not found
2026-06-16 03:27:47,845 24126 WARNING db_4367932 odoo.modules.loading: Transient module states were reset
2026-06-16 03:27:47,846 24126 ERROR db_4367932 odoo.registry: Failed to load registry
2026-06-16 03:27:47,846 24126 CRITICAL db_4367932 odoo.service.server: Failed to initialize database `db_4367932`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 605, in _tag_root
f(rec)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 273, in _tag_function
_eval_xml(self, rec, env)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 197, in _eval_xml
result = method(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/website/models/ir_module_module.py", line 704, in _generate_primary_snippet_templates
theme_addons = theme_manifest.get('configurator_snippets_addons', {})
AttributeError: 'NoneType' object has no attribute 'get'
```
We also get the missing manifest logs right before the error.
TBG-2781
[`_generate_primary_snippet_templates`]: https://github.com/odoo/odoo/blob/19.0/addons/website/models/ir_module_module.py#L700
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270217This change reverses a recent update that prevented the blog footer from being editable within the Odoo website builder. The previous change was intended to improve builder stability, but it inadvertently restricted access to a key element. This reversion restores the original functionality, allowing users to modify the blog footer as intended.
Original PR description
This reverts commit[1] which introduced not_activable_element_selectors resource in html_builder and used it to make the blog footer not selectable in the builder. [1]:https://github.com/odoo/odoo/commit/87d0c49a6 Forward-Port-Of: odoo/odoo#268141 Forward-Port-Of: odoo/odoo#268024
This update fixes alignment issues within the Timesheet Assistant, specifically in the 'By Project' and 'Chronological' views. The changes ensure that time entries and project descriptions display correctly, even with lengthy descriptions, and add a margin to the 'No time recorded' section for better visual clarity.
Original PR description
# [FIX] timesheet_grid: alignment issues in assistant This commit resolves the following alignment issues in the Timesheet Assistant: - View "By Project", the time wraps if description too long - View "Chronological", the time wraps if descriptions too long and project / task is not truncated - No timesheet recorded does not have a margin start # [FIX] sale_timesheet_enterprise: alignment issues in assistant This commit adds margin start on the "No (non-)billable time recorded" information. task-6264756 Forward-Port-Of: odoo/enterprise#120608
This update ensures that combo prices shown in the configurator dialog accurately reflect the order's currency. Previously, extra prices were displayed incorrectly due to a lack of currency conversion. Now, prices are automatically converted, guaranteeing accurate totals and matching sale order line prices.
Original PR description
Description of the issue/feature this PR addresses: In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product…
Description of the issue/feature this PR addresses: In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS 1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match. Current behavior before PR: _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line. Desired behavior after PR is merged: The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a foreign-currency pricelist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269905 Forward-Port-Of: odoo/odoo#269386
This update resolves an issue where focusing on the end date within a daterange widget incorrectly modified the start date. The fix ensures the correct date field is updated by accurately identifying the focused input element, improving data consistency and accuracy.
Original PR description
When a daterange widget is used (e.g., `deferred_start_date` coupled with `deferred_end_date`), focusing on the end date input was incorrectly modifying the start date field. This occurred because the `focusin` event was resolving the field name from the parent widget rather than the specific input focused. This commit updates `onFocusFieldWidget` and `getFullFieldName` to accept and evaluate the specific `event.target`. For `o_field_daterange` widgets, it now extracts the correct field name from the target's `data-field` attribute, ensuring the correct date field is updated. opw-6250048 Forward-Port-Of: odoo/enterprise#121033 Forward-Port-Of: odoo/enterprise#120684
This update fixes an error in the executive summary report that was incorrectly calculating the period length. Previously, it was measuring the gap between dates instead of the total number of days, leading to inaccurate metrics like Average Debtor Days. This change ensures the report accurately reflects the period length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update resolves an issue where POS orders with tracked products and GS1 barcodes would incorrectly report duplicate lot numbers. The fix ensures that the system correctly identifies existing lots based on their full GS1 name, even when the order uses a GS1 nomenclature. This prevents order validation failures and improves the reliability of the POS system.
Original PR description
When validating a POS order containing a product tracked by lots, an error about duplicate lot numbers is raised if the lot name can be read as a GS1 barcode (e.g. "10156": "10" is the GS1…
When validating a POS order containing a product tracked by lots, an error about duplicate lot numbers is raised if the lot name can be read as a GS1 barcode (e.g. "10156": "10" is the GS1 Application Identifier for Batch/Lot) while the company uses a GS1 nomenclature and the Barcode app is installed.
Steps to reproduce:
-------------------
* Install Barcode, POS and Inventory, enable lots & serial numbers
* Set the barcode nomenclature to "Default GS1 Nomenclature"
* Create a product tracked by lots and a lot named "10156" (any name starting with "10"), set an on-hand quantity for it with this lot
* On the "PoS Orders" operation type, enable both "Create New" and "Use Existing ones" for lots/serial numbers
* In POS, sell the product with lot "10156" and validate the order
> Observation:
The order fails to validate with a duplicate lot number error: the search for existing lots does not find lot "10156", so the POS tries to create it again and hits the unique constraint on stock.lot.
Why the fix:
------------
With stock_barcode installed, `stock.lot._search` preprocesses any domain on `name` with `_preprocess_gs1_search_args` so that scanned GS1 barcodes can match lot records. The lot names sent at order validation by `_create_production_lots_for_pos_order` are real lot names coming from the order lines, not scanned barcodes, but "10156" is decomposable as a valid GS1 lot ("10" + "156"), so the search domain became `('name', '=', '156')` and missed the existing lot. Skip the GS1 preprocessing in that search with the existing `skip_preprocess_gs1` context key, as already done in `product` and `stock`.
opw-6274744
Forward-Port-Of: odoo/odoo#269787This update resolves an issue where reducing the PO quantity after a partial receipt in a multi-step warehouse setup incorrectly calculated the remaining backorder demand. The fix ensures the system accurately adjusts quantities based on the actual receipt progress, preventing overestimation of required units.
Original PR description
**Issue** Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse can incorrectly update the remaining receipt quantity. **Steps to reproduce** - Setup 2-route…
**Issue** Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse can incorrectly update the remaining receipt quantity. **Steps to reproduce** - Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses) - Create a PO for 35 units and confirm it - Click on receive products, set received quantity to 10 and create a backorder - Validate the next transfer - Go back to the PO and change the quantity to 20 - Check the receipt demand -> The backorder picking demand become 35 instead of 10 **Cause** Updating the quantity of a purchase order line, also updates the related picking: https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120 It updates the picking associated to the backorder since the other one is done: https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187 https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197 This ultimately calls: https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228 To compute the new demand for the picking, it retrieves the `move_dest`: https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240 To compute `qty_to_push`: https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249 However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking. Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15` **Solution** The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand. In push flows (e.g., multi-step receipts), this assumption does not hold. To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. **Additional information** Known limitation: this does not address inconsistencies in return flows. When there're returns, units define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that. opw-5512172 Forward-Port-Of: odoo/odoo#265583 Forward-Port-Of: odoo/odoo#248626
This update resolves a problem where order signing with Fiskaly failed after the company's API key was updated. The system now correctly resets the associated SCU and cash registers, ensuring seamless integration with the Fiskaly service. This prevents order processing disruptions for users.
Original PR description
When the Fiskaly API key/secret is changed, the company is bound to a new Fiskaly organization (owner). The SCU and cash registers stored on the company and POS configs were created under the previous owner and no longer exist for the new one, so signing orders fails with E_CASH_REGISTER_NOT_FOUND. Clear l10n_at_pos_company_scuid and each config's l10n_at_cash_regid together with the access token so they are recreated under the new organization on the next authentication. opw-6297695 Forward-Port-Of: odoo/enterprise#120839
This update significantly speeds up partner searches within the Point of Sale (POS) system. Previously, searching through a large number of partners was slow due to rendering all filtered results. Now, the system limits the displayed results to 200 and adjusts the search input's delay to reduce unnecessary calls, resulting in a smoother and faster user experience.
Original PR description
Before this commit, when high number of partners were loaded in the POS, searching for a partner was slow. The main issue was that all of the filtered partners based on the search query were being rendered, while in reality, if a query returns lots of results, the search query is not refined enough and the user is likely to type more characters to narrow down the search. So in this commit, we limit the number of rendered partners to 200, which is a reasonable number of results to display and does not cause performance issues. Moreover, the debounce time of the search input has been increased from 100ms to 500ms to further reduce the number of times the search function is called while the user is typing. opw-6215958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268658 Forward-Port-Of: odoo/odoo#264300
This update corrects a bug in the project scheduling system that incorrectly applied task buffers when rescheduling tasks with dependencies. The fix ensures that buffers are calculated and respected accurately, preventing tasks from being incorrectly shifted in the Gantt view. This improves the reliability of project timelines.
Original PR description
Steps to reproduce: ---------------------------------------- - Have the company calendar work from 9 to 17 on weekdays - In project gantt view, create tasks with dependencies like this: ``` - [Task…
Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`
**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is 23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.
Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.
Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.
Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.
The same logic applies when moving tasks backwards.
opw-5973597
Forward-Port-Of: odoo/enterprise#119161This update resolves an issue where changes to a company's country setting caused errors in Time Off management. The system now checks if there are existing Time Off records linked to a Time Off Type before allowing the company country to be modified, ensuring smoother operation.
Original PR description
When a Time Off Type is created, it inherits the country of the current company. If there are leaves or allocations created from this Time Off Type and the company's country is then changed, various…
When a Time Off Type is created, it inherits the country of the current company. If there are leaves or allocations created from this Time Off Type and the company's country is then changed, various parts of Time Off will throw access errors as the leaves and allocations are still tied to the former country. The goal of this PR is to constrain the company country from being changed unless there are no such leaves or allocations. **Steps to Reproduce on Runbot:** 1. Ensure the current company has a `country` set, e.g. "My Company (San Fransisco)" has country set to "United States". 2. Access Time Off as Mitchell Admin. 3. Create a new Time Off Type, for simplicity's sake without a need for allocation or approval, ex: "Gone Fishing". Note this Time Off Type will have the `country` set to the company country by default. 4. Take "Gone Fishing" time off. 5. Change or set blank the company's `country` value. 6. Ensure the record rules cache is flushed. 7. Try to access Time Off. opw-6206359, opw-6140496 closes #263950 Forward-Port-Of: odoo/odoo#263950
This update fixes a potential issue where vendor bills were automatically emailed to vendors by default. The change disables the 'Email' option by default for standard vendor bills, reducing the risk of sending incorrect invoices. This improves efficiency and prevents unnecessary communication.
Original PR description
Issue: By default, the "Email" option is checked in the wizard. Since this is a standard vendor bill (sent to us by the vendor), emailing it back to them is usually incorrect and can lead to accidental emails. Cause: The default sending methods for all moves fallback to the partner's preference or 'email', regardless of whether it is a customer or vendor document. Solution: Update `_get_default_sending_methods` to return an empty set for purchase documents, except in the case of self-billing (where the bill is generated on behalf of the vendor and a copy must be sent to them). This ensures the "Email" checkbox is disabled by default for standard vendor bills, preventing accidental emails, while leaving it available for manual selection if needed.
This update resolves a minor issue with the marketing automation dashboard by correcting calculations for key engagement metrics. Specifically, the KPI engagement rate and its n-1 counterpart are now accurately calculated, ensuring more reliable data reporting for marketing performance. This improves the dashboard's accuracy and provides a better view of marketing campaign effectiveness.
Original PR description
This commit fixes two issues:
- KPI engagement rate ('Mailing Statistics'!B16) should be =iferror((B7+B9)/B10),0)
- KPI engagement rate n-1 ('Mailing Statistics'!C16) should be =iferror((C7+C9)/C10),0)
Task: 5418449
Forward-Port-Of: odoo/enterprise#120962This update resolves an issue where opening the chatter for bank reconciliation statements was causing an unintended data expansion. The change prevents this unfolding process, improving the user experience and performance. This ensures a smoother and more efficient workflow for users.
Original PR description
Before this commit, open_chatter use the selectStatementLine function that will unfold the line. But we don't want the unfold when opening the chatter. task-6306311 Forward-Port-Of: odoo/enterprise#120847
This update resolves an issue preventing users with Sale access rights from inserting data into Quotation templates through the spreadsheet management feature. The change adds a setting to ensure the necessary flag is activated when the module is installed and the user has the correct permissions, improving usability.
Original PR description
Current behavior before PR: - The `can_insert_in_spreadsheet` session flag was not set by the spreadsheet_sale_management module. - Users with proper Sale access rights still could not insert into Quotation templates. Desired behavior after PR is merged: - Added logic to set `can_insert_in_spreadsheet` when the module is installed and the user has the required access rights. Task: [5960761](https://www.odoo.com/odoo/project/2328/tasks/5960761) Forward-Port-Of: odoo/enterprise#120903 Forward-Port-Of: odoo/enterprise#108674
This update enhances the visual clarity of the account reconciliation search dialog. The commit removes text truncation and adjusts the layout to ensure dates and balances are prominently displayed, providing a more user-friendly experience. This improves the readability of key financial data.
Original PR description
This commit will remove the text-truncate from the reference so that we have it full. Also removing the align item so that the date and balance are on top. no task id Forward-Port-Of: odoo/enterprise#120963