Thursday, April 3, 2025
12 changes · 18.0
Enhancements to existing features
Spanish invoicing now more accurately marks eligible invoices as simplified by default when the customer has no VAT number, is located in Europe, and the invoice is below the simplified invoice threshold. Users can still override the setting if needed, reducing manual work while preserving control.
Original PR description
…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 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
Resolved issues and error corrections
Products in subcategories now appear correctly on the Point of Sale screen when category restrictions are enabled. This prevents cashiers from missing sellable items that should be available under permitted parent categories.
Original PR description
Before this commit, when the "restricted categories" setting was enabled, products belonging to subcategories of the allowed categories were not shown on the POS screen when no category was selected. opw-4700812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Time Off app now handles employees who do not have a working calendar assigned, avoiding an error when opening or calculating time off. This makes leave balances and expiring leave information more reliable for fully flexible workers.
Original PR description
… flexible This commit aims to resolve critical error in time off when the user is fully flexible. - get_allocation_data is updated to handle the case when the employee is fully flexible. - Set duration_hours and duration_days in the dummy attendance to handle flexible time off requests and to avoid unintended zero division error in _get_attendance_intervals_days_data. P.S: Currently Fully Flexible resources do not support fully time offs, so this allows a fallback that prevents error while still setting a valid duration of a time off request. Steps to reproduce: 1. Install hr_holidays 2. Go to Mitchel Admin's employee profile > work information 3. Delete the working calendar > so that the employee is fully flexible 4. Try to open time off module -> Prior to this commit, it would raise a zero division error ticket-id: 4677726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents banner blocks in the HTML editor from being treated as changed after every save. Users keep their editing session and history intact, reducing disruption when working with rich text content.
Original PR description
Prior to this commit, using a `/banner` block would create elements that always have `contenteditable` attributes when saving, that are always different from the server value which removes these…
Prior to this commit, using a `/banner` block would create elements that always have `contenteditable` attributes when saving, that are always different from the server value which removes these `contenteditable` attributes, resulting in a new `Wysiwyg` instance being constructed after each `save`. Resolution: 1- Introduce new classes to handle the `contenteditable` attribute: `o-contenteditable-true` and `o-contenteditable-false` to avoid a namespace conflict with `website` specific features. They replace `o_editable` and `o_not_editable` for the `banner` block. 2- Ensure that `contenteditable` attribute handled by these classes are removed during `cleanForSave`, to create a value comparable to the server value. This is because the server sanitizes the `contenteditable` attribute. If both compared values are not equal, the current `Wysiwyg` and `Editor` instances would be fully replaced after each save, resulting in a loss of edition history. This should ideally never happen. 3- Ensure the attributes `role` and `aria-label` which are also sanitized by the server are removed during `cleanForSave` and maintained during `normalize` through `data-oe-role` and `data-oe-aria-label`. 4- Introduce a `o_editor_banner_content` class for the `banner` content, for ease of selector creation. 5- Ensure that the `baseContainer` created before the `banner` if it is the first element in the `editable` has the proper `tagName` based on the `HtmlField` configuration. A `html_migrations` version is added to adjust existing `banners` to the new classes usage. task-4640490
This fixes an issue where customers using the portal's Pay Now button could hit a PayPal error instead of being redirected to complete payment. The PayPal payment request now excludes unsupported information, allowing the checkout flow to proceed correctly.
Original PR description
Description of the issue/feature this PR addresses: Currently, the payload contains unsupported data and due to this, payment with PayPal results in error. Current behavior before PR: Sending payment request to PayPal API via portal button "Pay Now" results in error: 'The communication with the API failed. Details: Request is not well-formed, syntactically incorrect, or violates schema.'. Desired behavior after PR is merged: After clicking "Pay Now" in portal, visitor is successfully redirected to PayPal for payment. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where percentage promo codes could incorrectly discount fixed shipping charges. Customers now receive discounts only on eligible order items, keeping delivery fees accurate during checkout.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a promo code that applies a 50% discount; 2. have a fixed price delivery method; 3. apply code on an order with said delivery method. Issue ----- The 50% discount is applied to the shipping costs. Cause ----- When calculating the discountable amount in `_discountable_amount`, it uses the `_get_no_effect_on_threshold_lines` method to filter out sale order lines that shouldn't impact the amount discounted. This value gets stored in the `lines` recordset. Commit d0e7be7832672 overlooked the existence of this variable when modifying the `_discountable_amount` method, and instead used `self.order_line`, using all lines to calculate the discountable amount. Solution -------- Use the filtered recordset to calculate the discountable amount. opw-4658702
This fixes a multi-company inventory issue where validating a picking for one company could fail to create the next shipping step when another company was the main active company. Deliveries using two-step routes now continue correctly for the company that owns the warehouse, reducing manual corrections and missed shipments.
Original PR description
### Steps to reproduce: - In the settings: enable Multi-steps route. - Have two companies active (each with an existing warehouse): COMP 1, 2 - Put the warehouse of COMP 2 in delivery in 2 steps. - With COMP 1 as main active company, create and confirm an SO for COMP2 > A pick picking has been created for COMP2 - Validate The pick picking #### > The ship picking was not created ### Cause of the issue: During the `_action_done`of the pick move, we will run a `_push_apply` on the move and try to trigger any push rule related to its destination. However, since de destination location of tha move (COMP2 output) does not belong to the main active company, the warehouse for which we search the rule is set to False and the rule ends up not being found: https://github.com/odoo/odoo/blob/cc05d9d50ac668eaa26363e1127f914897a4b125/addons/stock/models/stock_move.py#L1058-L1066 opw-4670760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When Inventory is installed after Sales in a multi-company setup, existing sales orders are now assigned to the warehouse belonging to their own company. This prevents orders from one company being grouped under another company's warehouse, improving accuracy for inventory and order operations.
Original PR description
Steps to reproduce: 1. create 2 companies, 2. install sales, 3. create SOs for both companies, 4. install Inventory, 5. Group SOs into warehouse for Company B Issue: All so's are under Warehouse A even though Warehouse B is created Cause: We take the first available company Solution: There should be only one warehouse defined per company https://github.com/odoo/odoo/blob/c045a5c9d6f6dd52271d9ab6b4265fd849cd53de/addons/stock/models/stock_warehouse.py#L32-L34 opw-4376078
Project profitability reports now include revenue from expenses that are reinvoiced through purchase orders or vendor bills. This makes project margins more accurate when costs are billed back to customers at cost or at a sales price.
Original PR description
### Issue: - in 18.0 when a product expence reinvoice configuration is st to 'at cost' or 'sales price', the expense is not added to the profitability. even tho we see it on the SO. ### Steps To…
### Issue: - in 18.0 when a product expence reinvoice configuration is st to 'at cost' or 'sales price', the expense is not added to the profitability. even tho we see it on the SO. ### Steps To Reproduce: - Create a product that can be expensed where type is `service`, add cost and sales price. - Set the product `Create on Order` to `project & task` and `Re-Invoice Costs` to `At cost` or `Sales price`. - Create a sales order for the product and confirm it. - Create a purchase order for the product and add the SO project to the PO project. - Confirm the PO and validate the bill. - Notice the expense is now added as a sol on the SO. - Notice the expense is missing in the project profitability. ### Solution: - in `_get_profitability_sale_order_items_domain` we used to remove the expense lines from the domain. however, since now we are adding them on the SO to be reinvoiced, we should keep them. ### opw-4398193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders with combo products now create invoices with the expected combo lines and correct line order. The Create Invoice action also better reflects whether the related order lines can actually be invoiced, reducing confusion for sales and billing teams.
Original PR description
Steps: - Install sales app. - Create a combo type product with invoice_policy delivery. - Create a sale order with product. Issue: - 1) Combo line is not adding when creating invoice. - 2) Sequence of combo line always stays last even fro order policy - 3) If we change combo product policy to order then `Create Invoice` stays primary even all the actual line are not invoicable Cause: - Corner cases that left to handle for combo type products Fix: - Handle those cases. opw-4640087
The manufacturing change process now counts engineering change orders separately for products and bills of materials. This prevents misleading counts and avoids showing empty results when users open the ECO smart button.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Create a BoM - Go back to the product form and create an ECO: - Apply on: “Bill of Materials” - The created BoM will be selected…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a BoM
- Go back to the product form and create an ECO:
- Apply on: “Bill of Materials”
- The created BoM will be selected automatically.
- Save.
- Return to the product form.
- The ECO count in the smart button is 1.
- Click on it.
Problem:
No ECO is displayed because the domain filters only ECOs applied to the product:
https://github.com/odoo/enterprise/blob/ec6b4717f49ccd5b651be80aed21494ed500f580/mrp_plm/models/product.py#L17-L20
Solution:
only ECOs of type "Product" should be counted in the product form.
Issue 2:
- Try updating the "Apply on" field of the ECO to “Product.”
Problem:
The "Bill of Materials" field becomes invisible but is not cleared. As a result, when counting the number of ECOs linked to the BoM, the count will be incorrect.
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4653598This fixes how German balance sheets calculate profit or loss for the current and previous fiscal years. The correction helps ensure carried-forward profit or loss and net income figures are reported in the right period, improving financial statement accuracy.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/82656 Profit and loss from previous year was not well calculated on the balance sheet. With this commit, we change the date scope for the `Net profit/loss for the year` line from `normal` to `from_fiscalyear`. We also change the way we calculate `Profit carried forward/loss carried forward` and `Net income/loss for the year` lines. opw-3663626