Monday, June 30, 2025
32 changes · 18.0
Enhancements to existing features
This update adjusts mail test setup so upcoming Documents service requests for multiple groups are ignored during legacy steps. It supports performance comparison work without changing end-user behavior.
Original PR description
We're adding a route to allow fetching multiple groups at once for the Documents service. This will be useful to compare with alternative solutions. Task-4836624
Resolved issues and error corrections
This fixes how employee online status lists are combined in Time Off, replacing behavior that only worked accidentally. It reduces the risk of incorrect availability checks when showing or using employee presence information.
Original PR description
PR above made a typo in code in which list of "online" member IM status is a list of string, and it uses + to concatenate items like in python but this doesn't work in JS. Thankfully it kinda "worked" because this casted the array into list (e.g. `["a", "b"]` becomes "a,b") and other items were appended to string. Since this list was used for `.includes()` by chance the ".includes()" method is on Array and String and functionally this results to about the same intention... Again by chance! Forward-Port-Of: odoo/odoo#216598
Miscellaneous changes
**PROBLEM** The account Caixa (Cash) and Depósitos à Ordem (Demand deposits) are missing from the Portuguese localization. The accounts numerario and banco exist, but they don't have the right names. **STEPS TO REPRODUCE** - install the accountant and l10n_pt module. - select a Portuguese company and select the portuguese language. - in the Chart of Accounts, notice there is no account named Caixa and Depósitos à ordem. **FIX** We still need to translate "Bank" by Banco in some cont
Original PR description
**PROBLEM** The account Caixa (Cash) and Depósitos à Ordem (Demand deposits) are missing from the Portuguese localization. The accounts numerario and banco exist, but they don't have the right names. **STEPS TO REPRODUCE** - install the accountant and l10n_pt module. - select a Portuguese company and select the portuguese language. - in the Chart of Accounts, notice there is no account named Caixa and Depósitos à ordem. **FIX** We still need to translate "Bank" by Banco in some context. We override the "Bank" and "Cash" account in the pt journal template, using the account.account-pt.csv data. opw-4829413 related PR: https://github.com/odoo/odoo/pull/213522 Forward-Port-Of: odoo/odoo#215369
This fixes Spanish SII reporting so credit notes identify OSS taxes using the correct refund tax information instead of invoice tax information. It helps ensure refunds are reported accurately and reduces the risk of incorrect tax data being sent.
Original PR description
Before this commit, the method _has_oss_taxes was determining whether a tax is OSS based on the tax_ids.invoice_repartition_line_ids.tag_ids This works fine for invoices, but for credit notes it should be based on tax_ids.refund_repartition_line_ids.tag_ids This commit solves this issue followup of: https://github.com/odoo/odoo/pull/215614 task-4548095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216603 Forward-Port-Of: odoo/odoo#216543
The mail message composer now keeps a consistent height when empty in Chromium-based browsers. This prevents the input box from visibly resizing as users begin typing, making messaging feel smoother and more polished.
Original PR description
Before this commit, composer height was too small when it had no content. This lead to composer changing height when typing some characters which looks off. This bug is specific to Chromium browsers and seems to be new since Chrome 138.0. The code expected that textarea had unchanged scrollheight when textarea has height 0 and fits its content in at most 1 line, but this seems to have changed with Chrome 138.0. This commit fixes the issue by cheating when composer is empty: the fake textarea artificially adds a character so that the computation for height when empty works as if it has 1 character, thus the computed height is the same when there are few characters in composer.
This fixes a visual issue on invoice forms where an empty section could leave an odd line and extra spacing beside invoice amounts. The invoice screen now hides that whole section when it is not relevant, making the layout cleaner for draft invoices or invoices without outstanding items.
Original PR description
Repro steps: Navigate to the form view of an invoice that is either 1. not posted 2. does not have outstanding debits/credits Problem spotted: next to the invoice amounts, a weird line and margin to the right can be seen Cause: The field invoice_outstanding_credits_debits_widget of an invoice may be invisible with this condition invisible="state != 'posted' or not invoice_has_outstanding" and in that case, it's containing group would still be visible (showing the aforementioned margin). Fix: This commit fixes this issue by moving the invisible condition to the group containing the field invoice_outstanding_credits_debits_widget instead of the condition being on the field itself. task-4882509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated website payment donation test so it handles the payment confirmation redirect reliably. It helps keep donation-related website checks stable and reduces false test failures during quality assurance.
Original PR description
In this commit, we fix the donation_snippet_use tour. At the end of the tour, when you click on submit donation, you are redirected to a page "Your payment has been processed." From this page, you are then redirected to a page with "Thank you". This intermediate redirection page can be a problem if there are several steps that concern it because we do not know when the redirection will be triggered (in the first or the second step?) Therefore, it is essential to have only one step for intermediate redirections. 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
Error dialogs in debug mode no longer show an unrelated internal request ID as if it were a record ID. This avoids misleading information when users or support teams review crash details for server actions.
Original PR description
Steps: - Enable debug mode - Go to server actions - Create a server action that crashes with `Execute code` - Example -> "a" (will crash because `a` is undefined) - Traceback will contains an invalid ID `Occured on odoo180 on model ir.actions.server and id 19 on 2025-06-30 09:20:48 GMT` This was an error and this ID is not linked with the model, it is the rpc id, so it should not be on the traceback. This commit remove this id to have something like this `Occured on odoo180 on model ir.actions.server on 2025-06-30 09:20:48 GMT` opw-4816514
The Spanish SII electronic invoicing integration now identifies OSS taxes using tax tags instead of relying only on predefined system records. This ensures custom OSS taxes created by users are correctly recognized, reducing reporting errors for cross-border EU sales.
Original PR description
This commit fixes the search for OSS taxes in `_has_oss_taxes` function. The current search approach (with tax tags) is better in the following points: 1. No need to use `sudo` for ir.model.data access 2. Currently, user-created OSS taxes are considered in the search task-4548095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216375 Forward-Port-Of: odoo/odoo#215614
This change restores the previous behavior of an automated test for creating project sales order lines. It helps keep quality checks stable so future updates to sales-project workflows can be validated reliably.
Original PR description
This reverts commit bde64f4dd19d30f807142fea6f04409de0696c54. runbot-error-226711
The emoji picker now keeps focus when a user selects an emoji category, so keyboard navigation continues to work as expected. This makes emoji selection smoother and more accessible for users who rely on keyboard controls.
Original PR description
Before this PR, the keyboard navigation capability was lost after clicking on a category. This PR adds a tabindex to avoid losing focus on the emoji picker.
A payroll expense process was pointing to the wrong type of record, which could cause incorrect handling of expense sheets linked to payslips. This fix ensures expense sheets are referenced correctly, improving reliability for payroll-related expense workflows.
Original PR description
this commit fixes wrong reference to `hr.payslip`. `payslip_sheets` should be a recordset of `hr.expense.sheet` and not `hr.payslip`.
This update fixes a translation-related error that could occur when referral links or loan information were processed in different languages. It improves reliability for multilingual users without changing business workflows or features.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198
This fix prevents an error when users edit payslip lines through the payroll wizard. Payroll staff can update payslip details more reliably without being blocked by an unintended record creation issue.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88033
A test counter in the Mail Enterprise test suite was corrected to better reflect expected activity behavior. This helps keep automated quality checks reliable and reduces the chance of false failures during development.
This update fixes an issue in the Belgian salary contract offer process. It helps ensure salary offers are handled more reliably for HR teams using the Belgian localization.
The employee document smart button now shows only documents the user can actually access. This avoids confusing count mismatches and gives users a more reliable view of available HR documents.
Original PR description
Previously the smartbutton showed the number of documents the user was a contact of, without checking if the user had access to such documents or not, resulting in sometimes different values Task: 4771754
The Journal Report now shows the account name in the Account column, making entries easier to identify and review. This fixes a visibility issue so business users can better understand accounting report lines without relying only on account codes.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276
The Partner Ledger partner filter has been corrected so companies are no longer missing from the dropdown when they have a parent company. This helps users select the right partners for reporting and avoids incomplete filtering options.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020
A test setup issue in Documents Sign was corrected so signer email details are populated from the right contact record. This prevents false test failures in builds without demo data and helps keep automated quality checks reliable.
Original PR description
This commit fixes a ValidationError triggered during sign request creation tests due to missing signer emails in "no demo" builds. The root cause was incorrect data passed into the test helper create_sign_request_1_role: the user record (res.users) was passed instead of its corresponding partner (res.partner). Since the sign.request.item expects a valid partner_id, this led to signer_email being computed as False, violating the constraint that requires all signers to have valid email addresses. This change ensures the proper partner_id (user.partner_id) is passed when creating the request item, allowing the email computation and constraint to behave as expected. This fix unblocks TestSignedDocument.test_gc_clear_bin build_error-224070
Currently, a traceback occurrs when creating a leave request for an employee **To reproduce this issue in 18.0:** 1) Install hr_holidays 2) Navigate to Time Off > Management > Allocations. 3) Create an allocation for 2 employees with same leave type 4) Navigate to Time Off > Management > Time Off. 5) Create a new time off for employye1, with above leave type 6) Now, change the employee to employee2 **Error:-** ``` 'hr.leave.allocation' object has no attribute 'virtual_remaini
Original PR description
Currently, a traceback occurrs when creating a leave request for an employee **To reproduce this issue in 18.0:** 1) Install hr_holidays 2) Navigate to Time Off > Management > Allocations. 3) Create…
Currently, a traceback occurrs when creating a leave request for an employee **To reproduce this issue in 18.0:** 1) Install hr_holidays 2) Navigate to Time Off > Management > Allocations. 3) Create an allocation for 2 employees with same leave type 4) Navigate to Time Off > Management > Time Off. 5) Create a new time off for employye1, with above leave type 6) Now, change the employee to employee2 **Error:-** ``` 'hr.leave.allocation' object has no attribute 'virtual_remaining_leaves' ``` **Cause:-** The field `virtual_remaining_leaves` is present in `hr.leave.type`, it was introduced from saas~18.3 in `hr.leave.allocation`. https://github.com/odoo/odoo/commit/944c11e61abead4f5157a7a7cb7b1f536bc14411#diff-3a9cd2e66cdd2827ecf6d9e693aff35eeacdfaaa68875b7b2572edde23b757eaR123 So indeed a traceback will occur when trying to access `virtual_remaining_leaves` from allocation from the below line. https://github.com/odoo/odoo/blob/97f9ad816cb4b35aa2d4713038cc2c623dfaf176/addons/hr_holidays/models/hr_leave_type.py#L168-L170 **Solution:-** Since the value of `virtual_remaining_leaves` is retrieved from the same method (_get_consumed_leaves) for both `hr.leave.type` and `hr.leave.allocation` in 18.3, So we can use the value of `virtual_remaining_leaves` from `hr.leave.type`. opw-4860637,4868969 Forward-Port-Of: odoo/odoo#214709
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an mrp.production order and clicking on "Set as done". Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg. At the end of
Original PR description
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an…
Description of the issue/feature this PR addresses:
I'm not sure how to reproduce right now. Clue: these modules are installed:
- sale_stock_margin
- stock_account
Other clue: user is going to an mrp.production order and clicking on "Set as done".
Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg.
At the end of the rabbit hole, the code ends up here, where there's a pretty obvious bug: a singleton value being extracted from a multi-record variable.
So, yes, this is probably the worse fix description ever. 😅 However, the bug is so obvious that I'm not sure I really need something more elaborate in this case. So, here's the fix! 🎁
@moduon MT-7556
Current behavior before PR:
<details>
```
Traceback (most recent call last):
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 15, in _call_kw
raise ValueError
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5182, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1651, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/opt/odoo/custom/src/odoo/odoo/service/[model.py](https://model.py/)", line 133, in retrying
result = func()
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1678, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1882, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/[ir_http.py](https://ir_http.py/)", line 154, in _dispatch
result = endpoint(**request.params)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 734, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 46, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 19, in _call_kw
return super()._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 469, in call_kw
model.env.flush_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 745, in flush_all
self._recompute_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 741, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 6282, in _recompute_field
field.recompute(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1370, in recompute
apply_except_missing(self.compute_value, recs)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1343, in apply_except_missing
func(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1392, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 4240, in _compute_field_value
fields.determine(field.compute, self)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/sale_stock_margin/models/[sale_order_line.py](https://sale_order_line.py/)", line 18, in _compute_purchase_price
purch_price = product._compute_average_price(0, line.product_uom_qty, line.move_ids)
File "/opt/odoo/auto/addons/mrp_account/models/[product.py](https://product.py/)", line 54, in _compute_average_price
return super()._compute_average_price(qty_invoiced, qty_to_invoice, stock_moves, is_returned=is_returned)
File "/opt/odoo/auto/addons/stock_account/models/[product.py](https://product.py/)", line 788, in _compute_average_price
qty_valued, valuation = candidates._consume_specific_qty(qty_invoiced, qty_to_invoice)
File "/opt/odoo/auto/addons/stock_account/models/[stock_valuation_layer.py](https://stock_valuation_layer.py/)", line 113, in _consume_specific_qty
rounding = self.product_id.uom_id.rounding
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1154, in __get__
record.ensure_one()
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5185, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: uom.uom(1, 12)
```
</details>
Desired behavior after PR is merged: Fixed!
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183402…d comp **Problem:** when updating the quantity of a sale order line for a kit whose components are dropshipped, the update of the quantity of the linked Purchase order lines is wrongly computed **Steps to reproduce:** - enable the dropshipping setting - create a new storable product - in the purchase tab set a vendor - in the inventory tab check only the dropship route - repeat these operations for another product - create a third storable product - create a BOM for this product a
Original PR description
…d comp **Problem:** when updating the quantity of a sale order line for a kit whose components are dropshipped, the update of the quantity of the linked Purchase order lines is wrongly computed…
…d comp **Problem:** when updating the quantity of a sale order line for a kit whose components are dropshipped, the update of the quantity of the linked Purchase order lines is wrongly computed **Steps to reproduce:** - enable the dropshipping setting - create a new storable product - in the purchase tab set a vendor - in the inventory tab check only the dropship route - repeat these operations for another product - create a third storable product - create a BOM for this product and set it as "kit" - add the two first products you created in the components - create a new quotation for the kit product, set a quantity of 25 and confirm - modify the quantity to 10 and save - click on the purchase smart button **Current behavior:** the quantities of the two purchase order lines have been updated to -15 **Expected behavior:** it should be 10 **Cause of the issue:** When we change the quantity on the sale order line: The method action_stock_rule from SaleOrderLine is triggered. It will create a procurement: https://github.com/odoo/odoo/blob/2e7fd1c45a0f68d123e85c95f3eb3a7fd5395527/addons/sale_stock/models/sale_order_line.py#L338 To compute the quantity used for this procurement,the computation is : product_qty = line.product_uom_qty - qty where qty is line._get_qty_procurement https://github.com/odoo/odoo/blob/2e7fd1c45a0f68d123e85c95f3eb3a7fd5395527/addons/sale_stock/models/sale_order_line.py#L313 The error comes from the _get_qty_procurement - The "normal" behaviour of _get_qty_procurement is to compute the difference between outgoing moves and incoming moves https://github.com/odoo/odoo/blob/2e7fd1c45a0f68d123e85c95f3eb3a7fd5395527/addons/sale_stock/models/sale_order_line.py#L253-L263 - Basic _get_qty_procurement wouldn't work for a kit as a move is created for each components. So there is an override of the method to handle this case https://github.com/odoo/odoo/blob/2e7fd1c45a0f68d123e85c95f3eb3a7fd5395527/addons/sale_mrp/models/sale_order_line.py#L128-L141 this override calls _compute_kit_quantities on the stock moves linked to the sale order line via its move_ids attribute. _compute_kit_quantities does a computation of the ratios for each component and returns the minimum - Basic _get_qty_procurement wouldn't work either for a dropshipped product as no move is created when confirming the sale order. So there is another override of the method to compute this case https://github.com/odoo/odoo/blob/2e7fd1c45a0f68d123e85c95f3eb3a7fd5395527/addons/stock_dropshipping/models/sale.py#L42-L51 This override uses the purchase order line linked to the sale order line via its purchase_line_ids to compute the quantity. Neither of those two overrides would work for a kit with dropshipped components. The first one would fail because no stock moves are created. The second one would fail because adding the value of each purchase order line created returns a value too high **fix** for this specific case we just take the previous quantity opw-4743482 Forward-Port-Of: odoo/odoo#211726
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefi
Original PR description
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefined). So when metamask (or another extension that cause window.chrome.runtime to be defined) is installed, we get an error shown because the promise rejection is not handled. Fix: handle the unhandled promise error. opw-4874027 Forward-Port-Of: odoo/odoo#216132
Versions -------- - 17.0+ Steps ----- 1. Log Stripe payment values. Issue ----- Only the keys get logged. Cause ----- Commit 1a2573881281 fixed the logging of secret keys, but in doing so, only logs keys and no values. Solution -------- Use a dict comprehension to create a full dict to log. opw-4818301 Forward-Port-Of: odoo/odoo#216303
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Log Stripe payment values. Issue ----- Only the keys get logged. Cause ----- Commit 1a2573881281 fixed the logging of secret keys, but in doing so, only logs keys and no values. Solution -------- Use a dict comprehension to create a full dict to log. opw-4818301 Forward-Port-Of: odoo/odoo#216303
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_
Original PR description
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has…
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_id set The POL has the qty set to the min_qty of the invalid supplierInfo and the vendor code of that supplier info is not displayed. And if you further remove the invalid supplier info from the product page, the vendor code will be read and the POL qty will be the min_qty of the valid supplier info. This is because on creating a POL, two functions are got called, the first one is `_suggest_quantity` which suggests the initial quantity to set on the POL when the PO is created. This one is based on the minimum min_qty of all the supplierInfos related to the same product we are purchasing regardless if they are completely valid or not. Hence it chose the invalid supplierInfo min_qty. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/purchase/models/purchase.py#L1386C9-L1388C45 After the qty of the POL is set based on the `_suggest_quantity`, the `_compute_price_unit_and_date_planned_and_name` is called because it depends on the product_qty which calls the `_select_seller` function on the product. The `_select_seller` filters all the supplierInfo keeping only the valid ones BASED on the qty we are asking (so it eliminated the one with the smallest min_qty because the date_end is < PO.date and also the second one because the min_qty of the second_supplierInfo is > qty we are asking) ending up with empty list of supplierInfo to apply on our POL. Then the POL is set to the standard price and no vendor code is attached and read into it. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L616-L617 https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L603-L612 opw-4640937 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 Forward-Port-Of: odoo/odoo#205915
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the
Original PR description
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one…
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself. When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193 Since the move has a quantity but picked is still False, the full picking is being picked at once https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207 ----- Ticket: opw-4726229 Forward-Port-Of: odoo/odoo#212687
**Steps to reproduce:** 1) Install CRM 2) Create a crm lead and mark it as lost 3) Create a new activity for the lost lead for today 4) Go to the activity button in the top right corner 5) Click on today's activity for crm leads **Issue:** If you click activity for crm, it will only show the active lead's activities, not the lost ones. You need to click on the filter 'lost', to see the lost leads **Cause:** When the lead is marked as lost, we archive the lead record.
Original PR description
**Steps to reproduce:** 1) Install CRM 2) Create a crm lead and mark it as lost 3) Create a new activity for the lost lead for today 4) Go to the activity button in the top right corner 5) Click on today's activity for crm leads **Issue:** If you click activity for crm, it will only show the active lead's activities, not the lost ones. You need to click on the filter 'lost', to see the lost leads **Cause:** When the lead is marked as lost, we archive the lead record. Indeed, we won't see the lost leads by default when opening activities, since they are not active. https://github.com/odoo/odoo/blob/8111009f6a8888db80f9afaa145a4c64272370e7/addons/crm/models/crm_lead.py#L1013-L1016 **Solution:** Add `active_test` to the context to show the archived/lost activities. opw-4866692 Forward-Port-Of: odoo/odoo#214942
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#88654
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#88654
**Steps to reproduce:** 1. Install the Helpdesk module. 2. Create a ticket directly in a closed stage (e.g., 'Solved') and add the portal user as a customer. 3. Log in as the portal user. 4. Apply the Open filter. **Issue:** - The ticket appears under Open Tickets, even though it was created in a closed stage. **Cause:** - Currently we consider a stage as closed if 'floded in kanban' is True and When a ticket is created directly in a closed stage, the close_date field is not set.
Original PR description
**Steps to reproduce:** 1. Install the Helpdesk module. 2. Create a ticket directly in a closed stage (e.g., 'Solved') and add the portal user as a customer. 3. Log in as the portal user. 4. Apply the Open filter. **Issue:** - The ticket appears under Open Tickets, even though it was created in a closed stage. **Cause:** - Currently we consider a stage as closed if 'floded in kanban' is True and When a ticket is created directly in a closed stage, the close_date field is not set. Since the portal filter relies on close_date to distinguish open from closed tickets, this shows closed tickets in open filter. https://github.com/odoo/enterprise/blob/c34256932e593ac2774fa65af813d64edb70ec43/helpdesk/controllers/portal.py#L63 **Solution:** - During ticket creation, if the specified stage is a closing stage, set the close_date field to the current time. opw-4847097 Forward-Port-Of: odoo/enterprise#87293
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Original PR description
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the
Original PR description
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one…
Issue ----- In barcode processing reception of subcontracted products doesn't create a back order for the remaining products. Steps to reproduce ----- - Create 2 products, one subcontracted and one storable - Create a purchase order for the 2 products & confirm it - Go to barcode and open the delivery - Only validate the reception of the subcontracted product --> No backorder is created for the remaining product, it is considered received Cause ----- Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself. When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193 Since the move has a quantity but picked is still False, the full picking is being picked at once https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207 ----- Ticket: opw-4726229 Forward-Port-Of: odoo/enterprise#86979