Monday, June 30, 2025
36 changes · saas-18.3
Enhancements to existing features
A new Odoo interface icon was added to support the Add Lead button used in VoIP. This helps keep the user interface consistent and clearer for sales teams using the related VoIP workflow.
Original PR description
This commit introduces a new Odoo icon to complement the "Add Lead" button added in Voip in odoo/enterprise#87294. task-4855486 Requires: - https://github.com/odoo/enterprise/pull/87294  Enterprise: https://github.com/odoo/enterprise/pull/87294
Resolved issues and error corrections
This update adjusts an automated editor test to avoid inconsistent rounding differences in specific test environments. It helps keep quality checks stable so development validation is less likely to fail for reasons unrelated to product behavior.
Original PR description
It looks like, on runbot specifically, the previously chosen size unfortunately resulted in a size near the 0.5px mark. Because of that, sometimes it would be rounded down and sometimes up. Hopefully changing to another font size won't have the same issue. If it does then we'll need to manually choose either to always round down or up.
Miscellaneous changes
In this PR: - When activating an Online Payment provider that creates a payment.method.line in a journal, automatically assign an Outstanding account to the payment method. - Uses the existing Outstanding Account resolution method from Invoicing module to ensure consistency across the system. - Applied to all Online Payment Providers that rely on provider integration, excluding manual payment providers without external integrations. task-4826385 Forward-Port-Of: odoo/odoo#216251 Forwa
Original PR description
In this PR: - When activating an Online Payment provider that creates a payment.method.line in a journal, automatically assign an Outstanding account to the payment method. - Uses the existing Outstanding Account resolution method from Invoicing module to ensure consistency across the system. - Applied to all Online Payment Providers that rely on provider integration, excluding manual payment providers without external integrations. task-4826385 Forward-Port-Of: odoo/odoo#216251 Forward-Port-Of: odoo/odoo#213554
The time-off form now identifies the record being edited more accurately, so users are not shown an overlap warning when adjusting dates within the existing approved period. This reduces confusion for employees and HR teams when updating time-off requests.
Original PR description
### Steps to reproduce: - Create a time-off with dates from X to Y. - Attempt to modify the start or end date to a value that still falls within the original X–Y range. ### Fix: - Updated the condition to correctly retrieve the current record's ID using .ids ,since .ids can also include the origin ID. Task-4819538 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Searching security groups for a forward slash no longer causes an error. This keeps the group search in Settings working reliably even when users enter unusual search terms.
Original PR description
Currently, an error is produced on searching in a security group with a forward slash ('/').
**Steps to reproduce:**
- Navigate to `Settings > Users & Companies > Groups`.
- Type '/' in the search bar and hit Enter.
**Error:**
`IndexError - pop from empty list`
**Cause:**
When the group name contains only slashes, splitting it by '/' at [1] results in an empty list. After computation, it attempts to pop from the empty list, resulting in an error.
[1] - https://github.com/odoo/odoo/blob/a301f8ae6aad59efd073a34c6f9ec323191d211b/odoo/addons/base/models/res_users.py#L234-L235
This commit ensures the group name is only assigned when values have content, preventing the error.
Sentry - 6685124199
Forward-Port-Of: odoo/odoo#216430
Forward-Port-Of: odoo/odoo#214557The task form header now uses the available space correctly when viewed through shared projects. This prevents the task status field from appearing out of place, giving portal users a cleaner and more consistent experience.
Original PR description
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the…
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the state misalignment ___ ### Issue: The task header section (.oe_title) was restricted by a max-width: 75% styling. When the priority field was removed, the remaining fields in the header, particularly the state field, appeared misaligned due to this layout constraint. ___ ### Root Cause: The .oe_title class imposes a max-width that limits the available horizontal space for inline fields in the header. This fixed constraint does not adapt when fields like priority are removed, resulting in layout misalignment. ___ ### Fix: To resolve this, the class mw-100 was added to the `<div class="oe_title"> `element. This overrides the default max-width behavior, allowing the container to use full width when needed. ___ ### Technical Details: This approach keeps layout logic within the view. It also preserves layout flexibility for different screen sizes and future field additions or removals. task-4813557
This fixes an automated test step so it selects the correct point of sale order when multiple orders are present. The change helps keep point of sale and restaurant bill-splitting checks reliable, reducing false test failures without changing customer-facing behavior.
Original PR description
Modified the selectOrder function to specifically target the order-row that contains the tracking_number being passed to the function. Also updated a step in SplitBillScreenTour to align with the changes in selectOrder. Enterprise PR: https://github.com/odoo/enterprise/pull/88795 runbot-163111
This fixes an issue where loading restaurant sample data could fail if a product category had been manually removed. The sample data now uses a safe fallback, helping businesses restore or test restaurant point-of-sale data without errors.
Original PR description
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading…
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading the demo data. - new demo data has been added : odoo/odoo@94734feba5670b23acf73a2ad485efe3d480efc0 - `raise_if_not_found` conditions has been added for all demo data : odoo/odoo@e6430737bdcea0162e4a3d5ee82e9ab6caa697e9 Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete food category. 4. Navigate to Point of Sale → Load Restaurant Sample Data. 5. An error is triggered during the process. Error: ```python odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/odoo/saas-18.3/addons/pos_restaurant/data/scenarios/restaurant_demo_data.xml:605, somewhere inside ``` This issue occurs because `sushi_drink_combo` also references a missing product category. As with previous products, this change ensures a fallback to prevent failure when no categories exist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A new automated check confirms that date-based rentals count the full rental period correctly, such as January 1 to January 2 being treated as two days. This helps prevent future changes from accidentally causing incorrect rental durations and pricing behavior on eCommerce rental flows.
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88671 Forward-Port-Of: odoo/enterprise#88264
The accounting reconciliation process now safely stops when there are no bank statement lines to process. This prevents users from seeing an error when running reconciliation models with no available transactions.
Original PR description
SQL syntax error occurs when trying to auto reconcile transactions via reconcile models,it is because there are no statement lines to reconcile. **Steps to reproduce:** * Install `accountant` module (No demo data needed) * Accounting Dashboard> Bank dropdown menu * Under reconciliation>Models>Internal Transfers>Run Now `syntax error at or near ')' LINE 57: WHERE st_line.id IN ()` **Solution:** * Return the function if there are no statement to reconcile. **Sentry-6610155279**
Printed payslips now display title-style salary rule lines with the correct formatting. This makes generated payroll documents clearer and more professional for employees and HR teams.
Original PR description
### Steps to reproduce: - Generate and print a payslip after marking a salary rule line as a title. ### Fix: - Added conditional styles and classes to fix the issue. task-4780481
This fix prevents an error from appearing when staff mark a point-of-sale preparation order as done shortly after it arrives while using debug mode. It adds a safety check so the display no longer tries to use order information that has already been removed.
Original PR description
Steps to reproduce: - Open a preparation display in debug mode - Make an order that will appear on the preparation display - Click on the done button before 5 seconds - Traceback will appear 5 seconds after the order was received Issue: When receiving an order useDelayedValueChange is called in the setup of the Orderline component. This method will try to access the props after a timeout. When the preparation orders are deleted in debug mode, the states are deleted from the front end. Since the props of orderline are the preparation state linked to it a traceback arises. Fix: A check is added to check if the state record exists.
Removing a parent emission source from an ESG emission source no longer triggers an error. This keeps emission source management reliable and prevents disruption when users update ESG reporting structures.
Original PR description
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new…
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new emission source with a parent emission source. - Remove the parent emission source. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=3>,).activity_flow_direct_indirect` This error occurs when the parent emission source is removed, causing the scope to become False in _compute_scope[1]. Subsequently, in _compute_activity_flow[2], none of the cases match, which results in a failure to assign the activity flow and raises an error. [1] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L75 [2] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L77-L78 This commit ensures that if the parent emission source is removed, the activity flow is properly maintained. sentry-6690968543
HR users can now update employee leave requests even while they are waiting for approval, provided the leave has not already been included in payroll. This helps HR correct or adjust leave records before payslip processing without unnecessary blockers.
Original PR description
- Allowing HR people to always edit the leave, as long as it's not included in a payslip. task-4866887
This update keeps the automated checks for Mexican electronic invoicing in Point of Sale aligned with a recent underlying system change. It helps ensure invoice-related POS workflows continue to be tested correctly without affecting day-to-day users.
Original PR description
In this commit, I’ve updated the test in invoice_order_tour to align with the new signature of the selectOrder function introduced in the PR referenced below. Odoo PR: https://github.com/odoo/odoo/pull/212434
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 -
Original PR description
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open…
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 - Third line with a price of 0.020 and a qty of 3 - Create a new request for quotation for this product with this vendor - set a quantity of 3 **Current behavior:** The unit price is 0.022 **Expected behavior:** It should be 0.020 **Cause of the issue:** When sorting the set of product.supplierinfo, rounding should not be applied because the rounding will be the one of the currency and the Product Price could allow more decimal than the currency. If we allow vendors price to be more precise the the currency, the sorting should take into account this precision when choosing a vendor. opw-4823919 Forward-Port-Of: odoo/odoo#213826
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214289 Forward-Port-Of: odoo/odoo#202832
Original PR description
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214289 Forward-Port-Of: odoo/odoo#202832
Before this commit: 1. Insert an image and add a link to it. 2. Click on the image and remove it by clicking the remove button in the toolbar. 3. The link popover remains open and only disappears after clicking away. This occurs because the default behavior of a link with text preserves the link element to allow the possibility of completely changing the label of the link directly in the editing area. After this commit: The link popover is properly closed when an image link is remove
Original PR description
Before this commit: 1. Insert an image and add a link to it. 2. Click on the image and remove it by clicking the remove button in the toolbar. 3. The link popover remains open and only disappears after clicking away. This occurs because the default behavior of a link with text preserves the link element to allow the possibility of completely changing the label of the link directly in the editing area. After this commit: The link popover is properly closed when an image link is removed, and the link element is removed when the link element associated with the image is empty. task-4805029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216045 Forward-Port-Of: odoo/odoo#213955
Forward-Port-Of: odoo/odoo#213890
Original PR description
Forward-Port-Of: odoo/odoo#213890
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#183402Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better ali
Original PR description
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better aligned with official terminology, improving usability and compliance with Romanian accounting norms. The updated translations are based on the official ANAF reference: [SAF-T RO Schema Definition Codes v4.1.6](https://static.anaf.ro/static/10/Anaf/Informatii_R/SAF_T_Ro_SchemaDefinitionCodes_v4_1_6_final_1712021.xlsx) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215085 Forward-Port-Of: odoo/odoo#212477
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another company than Marc's company - Confirm the SO **Issue:** A traceback is raised: `No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.` **Root Cause:** - When the procurement group searches for a pull
Original PR description
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another…
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another company than Marc's company - Confirm the SO **Issue:** A traceback is raised: `No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.` **Root Cause:** - When the procurement group searches for a pull rule with a destination location set to the inter-company transit location (due to the partner's company being different), the rules for the inter-company transit location are not automatically applied. - The `_get_rule_domain` method https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_rule.py#L641-L653 modifies the destination location to the customer's location if: - The user belongs to the `base.group_multi_company` group. - The destination location is the inter-company transit location. - In this use case, the user does not belong to the `base.group_multi_company` group because they are restricted to a single allowed company. Additionally, the logic in `_compute_location_dest_id` https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_move.py#L227-L231 for inter-company transfers does not account for users with a single allowed company. **opw-4749870** 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#211063
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
Original PR description
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
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#216126 Forward-Port-Of: odoo/odoo#205915
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://g
Original PR description
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within…
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L18 During recursion in `_compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call. Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L77 Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders. Root Cause: The stock_moves passed into the method have env.company set to Company 1. At https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L66 bom_lines are extracted, inheriting the environment from stock_moves. As a result, _compute_average_price is executed within the context of Company 1, which may lead to incorrect computations when the intended company context is different. Fix: Ensure that stock_moves is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution, preventing unintended company switching. opw-4222976 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#216326 Forward-Port-Of: odoo/odoo#192890
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read t
Original PR description
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213807
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it,
Original PR description
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it, the form will be hidden by default then shown based on attributes such as data-visibility-selectors. But on the root tag, we only allow to modify only a very restricted list of tags, so we saved the hiding of the form, but didn't save the attributes that made it visibile based on a condition. Fix: add the attributes used for visibility in the authorized list on the root tag. opw-4765026 Forward-Port-Of: odoo/odoo#215479
Before this commit: ================ Users could attempt to proceed with payment even when the cart had no orderlines After this commit: =============== If the cart is empty, the user is automatically redirected back to the product page, preventing the error and ensuring a smoother user experience. Task-4880984 Forward-Port-Of: odoo/odoo#216169 Forward-Port-Of: odoo/odoo#215139
Original PR description
Before this commit: ================ Users could attempt to proceed with payment even when the cart had no orderlines After this commit: =============== If the cart is empty, the user is automatically redirected back to the product page, preventing the error and ensuring a smoother user experience. Task-4880984 Forward-Port-Of: odoo/odoo#216169 Forward-Port-Of: odoo/odoo#215139
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: -
Original PR description
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: - Use the correct default account codes directly (101403, 101404) - Avoid reassignment of codes that are now created by the CoA template task-4826385 Forward-Port-Of: odoo/enterprise#88745 Forward-Port-Of: odoo/enterprise#88068
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it : 1) Use a Belgian company and an employee with a contract; 2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example); 3) Try to create a payslip for this employee. Error : File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half work_data[('half', work_entry.work_entry_type_id.id)] +=
Original PR description
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it :
1) Use a Belgian company and an employee with a contract;
2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example);
3) Try to create a payslip for this employee.
Error :
File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half
work_data[('half', work_entry.work_entry_type_id.id)] += dt.days * 24 + dt.seconds / 3600 # Number of hours
TypeError: 'float' object is not iterable
[opw-4752109](www.odoo.com/odoo/project/49/tasks/4752109)
Forward-Port-Of: odoo/enterprise#87895
Forward-Port-Of: odoo/enterprise#84810Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The
Original PR description
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The Ticket should continue to include a reference to the originating Lead (existing behaviour). - The Lead should also display a chatter message referencing the newly created Ticket. Forward-Port-Of: odoo/enterprise#87463
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime". The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]` I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forwar
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88730With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
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
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104