Daily updates from Odoo
Friday, June 13, 2025
17 changes · 18.0
Enhancements to existing features
Analytic reporting now automatically adapts group-by options to the hierarchy levels defined in analytic plans. This makes it easier for users to analyze data by levels such as city, country, or continent across standard list, pivot, and graph views.
Original PR description
Help the users by creating filters automatically depending on the hierarchy of analytic plans. This allows to open any standard view (list/pivot/graph) by level of hierarchies. One usecase is, for a plan about localisation: * Main plan: City (i.e. Brussels, New York, Los Angeles) * Level 1 sub plan: Country (i.e. Belgium, USA) * Level 2 sub plan: Continent (i.e. Europe, America) This will generate (or delete) automatically new fields depending on the various levels in the hierarchy being created or deleted. When the feature is in use, the group by widget becomes a drop-down similar to the groupby selector of dates, allowing to select either the year/month/... task-4763892
The recruitment job positions page is being streamlined so hiring teams can see key actions and status information faster, including activity and configuration shortcuts, clearer application labels, in-progress status, and company names where available. The mobile view is also simplified to show only the most useful details, making day-to-day recruiting work quicker on smaller screens.
Original PR description
### Description of the issue/feature this PR addresses:
Making a cleaner recruitment job positions view:
- Adding activity and configure button directly in the view to avoid losing time clicking o_kanban_card_manage_settings -> Activities/Configuration
- Renaming
- open slots -> new applications
- open applications -> new applications
- Adding "in progress" (more convenient)
- Displaying company name when it's possible instead of the user_id (more convenient)
Cleaner recruitment job position for mobile:
- Displaying only usefull infos
- Displaying company name when it's possible instead of the user_id (more convenient)
On job position activities view:
- Adjusting spacing right to the assignee avatar
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved issues and error corrections
Fixes an inventory issue where validating multiple partial receipts for subcontracted products could incorrectly add far more stock than was actually received. This keeps on-hand quantities accurate when purchase receipts are split across several backorders.
Original PR description
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5…
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5 units and backorder - Validate the backorder R2 for 3 units and backorder - Validate the backorder of the backorder R3 for 1 units and backorder #### > The on hand qty of the product is at 99 even thought you registered only 9 units. ### Cause of the issue: Currently, the above flow associate with the last receipt move with a qty of 1 both a move line for 1 unit and a move line for 90 units. As both will be picked at validation time, the receipt for 1 unit will effectively be treated as a receipt of 91 units. Here are the details: Updating the quantity of the move of R1 to 5 will in turn update the quantity of the move line to 5 and pick it by the "_set_quantity": https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L78-L82 https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L139-L143 Then, the first validation (of R1) for 5 units instead of 100 is well processed: it creates a backorder with a receipt move for 95 units and assign it with a single move line of 95. Similarily, setting the quantity on R2 will set the move line to 3 picked units. However, at validation, the situation will be quite different when assigning its backorder since the move of R2 now has an `move_orig_ids`. This will result in R3 to be assigned by 2 move lines: - one for 2 units - one for 90 units instead of one for 92 units. Indeed, during the action_assign of R3 (triggered by the `_create_backorder` of R2), we try to determine the qty available from done move lines related to our move_orig_ids and its `move_dest_ids` in order to see if there is already an available quantity (bacause more was processed in than out for instance). We will then first create a move line for that available quantity: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1873-L1886 and finish the assignment with the `missing_reserved_quantity`: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1907 The issue is that in our case, we should not find any available quantity to assign and the method responsible for this computation `_get_available_move_lines` will still find a discrepency between the available_move_lines_in qty and the available_move_lines_out qty for 5 - 3 that is 2 units -> We will end up with one move line for 2 units and one for 90. The discrepency is due to the fact that the `_get_available_move_lines_in` finds one in move line **done** for 5 units of R1. But that the `_get_available_move_lines_out` first finds the move line **done** for 5 units related to R1: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1817-L1821 But then erase the values by the demand of 3 provided by the **partially_available** move line of R2 that we are currently validating and that we should not have considered in the present flow: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1822-L1823 In particular, we end with a picking R3 for 92 units and 2 move lines. Now, setting the quantity of R3 to 1 will update the quantity of the first move line to 1 and set it as picked without altering the second one as the update of the quantity can totally be handled by the first move line. We therefore end up with a move with a move with a quantity of 1 and 2 move lines: 1 picked unit and 90 unpicked unit: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L124-L143 Now, this would be fine if the second move line was not automatically picked as it would be ignored by the action done. However, since the move it self was not picked since subcontracted moves are never automatically recomputed as picked from their move lines: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L61-L63 the _pre_action_done_hook of the picking validation will pick the entire move and hence set the other move line as picked: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_picking.py#L1486-L1487 In particular both move lines will be validated and update the related stock quants. ### Fix: Since in the case where there is no done move line we still find the outgoing partially reserved quantity that we are currently validating we should add the values of both **done** and **reserved** outgoing qties for the behavior on backorders to be the same as on the first picking validation. opw-4822646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where videos and other embedded content could disappear when code view was enabled in the HTML editor. The editor now keeps the needed add-ons loaded, so users can switch modes without losing embedded content.
Original PR description
Problem: When the `codeview` option is enabled in the HTML editor, embedded components like videos no longer work and disappear from the content. Cause: The `html_field` overrides `config.resources` entirely when `codeview` is enabled, which prevents other required plugins (e.g., for embedded components) from being loaded. Solution: Move the code view logic into its own dedicated plugin, consistent with how other optional features are handled, to avoid overriding `config.resources`. Steps to reproduce: 1. Open an HTML field. 2. Add a video (embedded component). 3. Enable the `codeview` option. 4. Enter debug mode. → The video disappears from the content. opw-4837016 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders for serial-tracked finished products now correctly set the produced quantity to 1 when production quantity is entered. This helps ensure related quality checks are processed with the right quantity and avoids errors in serial-based production workflows.
Original PR description
This commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks. Task : 4575193 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
Italian EDI proxy users are now created only for branch companies that have a different VAT number or Codice Fiscale from their parent company. This prevents subsidiaries that share the same legal identity from getting separate proxy configurations, while still supporting branches that operate as independent legal entities.
Original PR description
Companies (typically branches) whose VAT or Codice Fiscale differs from their parent (root) company are now allowed to create their own EDI proxy user. This ensures that only independent legal entities are assigned individual proxy users, while subsidiaries sharing the same VAT/CF use the root company's proxy configuration. no-task
This update fixes inconsistencies between server-side and browser-side tax calculations, especially around rounding and inherited tax settings. It helps ensure invoices, sales orders, and related accounting totals are calculated more reliably and consistently.
Original PR description
- rounding_method is there on the python code but not js-side. - rounding_method is passed to the taxes computation but not used after to decide if the total_excluded has to be rounded or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues affecting accounting, website editing, point of sale sample data, spreadsheets, email marketing, time off tests, and live chat internals. Business users should see fewer incorrect warnings, smoother website editing, more reliable demo/sample data loading, and corrected editor or dashboard behavior.
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
This fix prevents picking operation reports from crashing when a kit component has zero or missing packaging quantity. Business users can now print the report successfully even after manually removing kit components, avoiding a server error during warehouse operations.
Original PR description
Description of the issue/feature this PR addresses: When printing the Picking Operations report for kit-type BoMs, a `ZeroDivisionError` occurs if the packaging quantity (`product_packaging_id.qty`) becomes zero or is unset due to manual removal of a component. This happens in `_compute_product_packaging_qty`, where a division by zero is attempted when `product_packaging_id.qty == 0`. Current behavior before PR: - Users manually remove kit components (e.g., "Packing") - Print Picking Report → Server Error: `ZeroDivisionError: division by zero` Desired behavior after PR is merged: - The report prints correctly even if component quantities or packaging is zero - Division is safely guarded with a fallback of `1` to avoid crashes Fixes: #210594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a vendor bill in a different currency is matched to a purchase order, the down payment amount is now converted correctly. This prevents purchase orders from recording incorrect down payment values and helps keep purchasing and billing totals accurate.
Original PR description
Users can create a downpayment bill directly from the purchase order or create a bill separately and then associate it with the original purchase order. However, in the latter case, the bill amount won't take into account the currency. Steps to reproduce: - Create a purchase order for a partner in company currency - Create a bill in foreign currency for the same partner - Click "Purchase Matching" smart button - Select PO and BILL > Add to PO > Add Down Payment Issue: Downpayment will be added into the PO without taking into account the different currency opw-4716949
This fixes an error where Bulgarian invoice totals written in words could show the wrong thousands value, such as describing 8,500 as 7,500. Businesses using Bulgarian invoices can now rely on the printed amount text matching the actual invoice total.
Original PR description
### Steps to reproduce: - Install l10n_bg - Install the Bulgarian language - In the Accounting Settings, tick the option "Total amount of invoice in letters" - Change a contact's language to Bulgarian - Create an invoice for this partner, select BGN as the currency - The total should be with a unit in thousands (for example 8500) - The text transcription of the number substracts 1000: Седем Хиляди И Петстотин = 7500 ### Cause: The class `NumberToWords_BG` is a copy of the library num2cyrillic except for the initialization of the variable `_digits` which specifies three arrays with variants of the numbers (1-9). We do it by copying the index 0, which is the default variant, for the non-different spellings. The issue comes from the line `_digits[-1] = [None, 'една', None] + _digits[0][2:]` which have an unneeded `None` which offsets the array by one. So when reading `_digits[-1][8]` we end up with "seven". ### Solution: Remove the `None`. opw-4753418
This update resolves several issues found during the 18.0 upgrade, including password reset errors, unnecessary vendor bill notifications, dashboard filtering inconsistencies, and repeated portal email verification messages. These fixes reduce confusion for users and improve reliability across accounting, purchasing, website profile, and signup workflows.
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
Failed quality checks now correctly split stock movements when items are sent to a failure location, preventing location mismatches. This helps avoid downstream inventory routing and valuation problems, while keeping manufacturing quality checks safe during upgrades.
Original PR description
In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation. Task: 4575193
Odoo now sends the full product catalog to UrbanPiper whenever connected delivery platforms such as JustEat, Grubhub, DoorDash, or UberEats require it. This prevents missing or inconsistent menu information on those partner platforms during synchronization.
Original PR description
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894
The Italian Libro Giornale report now includes bank lines for payment entries, ensuring payments show both debit and credit sides. This prevents unbalanced report totals and supports more accurate statutory accounting output.
Original PR description
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to the default pdf and xml buttons name and remove _custom_options_initializer overwrite function task-4830113
This fixes an issue where scanning the same product after removing an inventory count line could create repeated duplicate sublines. Inventory counts in the Barcode app now stay clearer and more accurate, reducing confusion during stock checks.
Original PR description
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to…
### Steps to reproduce:
- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear
### Cause of the issue:
Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.
To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471
opw-4787229Non-administrator users can now retrieve Envia shipping rates without encountering an access error. This helps sales and operations teams quote shipping costs smoothly without needing elevated system permissions.
Original PR description
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196