Tuesday, March 18, 2025
27 changes
1 change
Resolved issues and error corrections
This fix ensures debug settings are handled consistently during automated tests, preventing avoidable test failures. It helps maintain confidence in quality checks for Documents, Dashboards, and Studio without changing end-user functionality.
Original PR description
odoo.debug has to be a string. If an error is thrown in a test with a
patchWithCleanup(odoo, { debug: true/false });
an error of type "env.debug.includes is not a function" is thrown.
Task ID: 465518026 changes
Resolved issues and error corrections
The self-ordering interface now appears in the language chosen by the user instead of always using the default language. This improves the experience for customers and staff using point-of-sale self-ordering in multilingual environments.
Original PR description
Before this commit, the interface was always shown in the default language. This fix ensures that the UI is displayed according to the user’s selected language. task-4609518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents the live chat interface from appearing twice on website pages. Visitors now see a single, clean chat entry point, reducing confusion and improving the support experience.
Original PR description
The live chat module the chat hub inside its shadow root. Do avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: https://github.com/odoo/odoo/pull/201771
This fix prevents the web interface from crashing when a record contains a related record ID but is missing the related model information. Instead of failing, Odoo now treats the missing relationship as no related record, improving reliability for affected users.
Original PR description
Having a record with set res_id but no res_model doesn't mean much, but we can consider, in web_read, that it means that there is no related record to avoid crashes. opw-4527152
Sales orders with down payments taken through Point of Sale now correctly show the amount already invoiced when creating the final invoice. This prevents staff from seeing a zero value in the invoicing wizard and helps avoid billing confusion or duplicate charges.
Original PR description
Currently when invoicing a SO which has a downpayment made in Pos this downpayment is not reflected in the wizard. Steps to reproduce: ------------------- * Create an SO * Open pos session and make a downpayment for the SO * Close register * Go back to the SO * Deliver the items * Select the invoice > Observation: Amount already invoiced is at 0 Why the fix: ------------ There was a previous fix at the same place previously: https://github.com/odoo/odoo/commit/f613b87c38d208730ba2470e0a26a110c2089b66 However the wizard had changed and instead of showing `amount_to_invoice` we now show `amount_invoiced` opw-4585413
Users who have been granted access to bills of material can now open them without hitting an attachment-related error. This makes custom access setups more reliable without requiring extra development work.
Original PR description
### Steps to reproduce 1. Create a new group 2. Give the group access to the following models: - `mrp.bom` - `mrp.bom.line` - `mrp.routing.workcenter` - `product.document` 3. Create a new menu using studio to access `mrp.bom` directly 4. Create a new user with the newly created group 5. Sign-in with this user and go on a BoM 6. AccessError ### Before this commit: Users without the `mrp.group_mrp_user` group cannot display bills of material, even if we add the necessary access rights. The record loads without issue, but the chatter displays an error when loading the attachments, due to strict group access on the field `attached_on_mrp`. ### After this commit: Remove the group from the field and move it into the view. This allows easier and more flexible access rights to the BoM without writing any custom code. opw-4538532
Fixed a configuration issue in the Indian withholding tax module that was causing automated validation to fail. This helps keep the module stable and prevents avoidable deployment or upgrade blockers.
Original PR description
In this commit-
We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614)
```py
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_in_withholding'
View: tds_entry_view_form
Fields:
<field name="currency_id" column_invisible="True"/>
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen workers add or increase components on a manufacturing order that is already in progress, the related stock transfer is now updated correctly. This helps ensure the right materials are moved to production and reduces the risk of shortages or manual corrections on the shop floor.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Enterprise: https://github.com/odoo/enterprise/pull/81361 opw-4638371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where manually created company-specific fields did not keep their company-dependent behavior. Businesses using custom fields can now rely on values being stored separately per company as intended.
Original PR description
The field attribute `company_dependent` is not passed when instanciating manual fields so they do not get created as jsonb columns and lose the company dependent property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Delivered and received quantities now update correctly for kit products in intercompany sales and purchases. The change ensures transfers through transit locations are counted, giving teams accurate order fulfillment and receipt information.
Original PR description
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used…
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used instead of the supplier and customer locations. Purpose: Updating the filter to include transit locations will allow stock moves to and from the transit locations to be included in the delivered and received quantities. Steps to Reproduce on Runbot: 1. Enable Inter-Company Transactions for both companies, with Generate Sales Orders, Generate Purchase Orders, and Synchronize Deliveries to your Receipts selected. 2. Create a product and create a kit type bill of materials for it. Remove the company from the bill of materials so it is available for both companies. 3. Create a sale order for this kit product with the customer set to another one of your companies. 4. Confirm the sale order and validate the picking. 5. Observe the delivered quantity on the sale order line is still 0. 6. Switch to the company you sold the kit to. 7. Navigate to the purchase order that was created and confirm it. 8. Validate the picking. 9. Observe the received quantity is still 0. opw-4536144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal signing flow now handles customers or contacts that do not have a standard name without failing. This prevents users from hitting an error when previewing and signing sales quotations for such contacts.
Original PR description
Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `SignatureForm` initialization, `onMounted` raise a traceback, because it calls directly `this.signature.resetSignature`. This commit adds default functions to `resetSignature` and `getSignatureImage` to prevent the crash. opw-4504223
This fixes an issue where loyalty points could be changed for multiple open POS orders when only one order was paid. Loyalty balances are now updated only for processed orders, preventing incorrect point deductions or awards for customers with draft orders.
Original PR description
Currently, when having multiple orders opened, when validating one, the points will be granted for all opened orders. Steps to reproduce: ------------------- * Have a loyalty progam with * 1point per $ spent * 5% on order in exchange of 200 points * Have 2 customers A and B with 300 each on their loyalty card * Open pos shop * On the order, select customer A, add items and select the reward * Open a new floating order, do the same but for customer B * Pay the order related to customer B * Go in the backend and check the loyalty card of customer A > Observation: Point have been modifyed * Back in the shop, pay order related to cusotmer A * Go in the backend and check the loyalty card of customer A > Observation: points have been modifyed twice Why the fix: ------------ Only processed orders should modify the points available on the loyalty card in the backend. opw-4539274
Exporting products by category with only the external ID field selected no longer causes an error. This keeps product data exports reliable for users who need external IDs for integrations or reporting.
Original PR description
Steps: - Install sales app. - Go to product menu and group list view by category - Export products with only `Product/Product/External ID` Issue: - Traceback. Cause: - Directly try to access `type` key from dict without checking dict contain `type` key or not. Before [this] PR we were checking if it contain type or not. Fix: - Check dictionary contain `type` or not. [this]: https://github.com/odoo/odoo/pull/178214 opw-4585879
This fixes automated web tours so steps using shared helper actions still perform the expected page-unload safety check. It helps make tour execution more reliable and reduces missed issues during automated testing.
Original PR description
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the beforeUnload event that is done. In this commit, we fix this. 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
Portal shoppers can now configure combo products that include unpublished configurable items when those items belong to a published combo product. This prevents checkout disruption while keeping unpublished combo items unavailable for direct selection from the cart.
Original PR description
_* : website_sale Steps: - Create a combo product with combo items containing unpublished configurable product - on /shop as portal user add the combo product and try to configure any unpublished product Issue: - access error Cause: - The product configurator doesn't sudo the product which is being configured Fix: - if the product for product_configurator is part of published combo product, it will be sudo'ed opw: 4567008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops Italian electronic invoicing from automatically treating negative invoice lines as discounts. It avoids confusion for businesses where negative lines represent other accounting situations, making invoice exports better match user intent.
Original PR description
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish SII electronic invoicing demo certificates were replaced because the previous ones had expired and were causing automated validation tests to fail. This keeps the demo/test setup working reliably and aligns certificate naming with related Spanish localization components.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix helps accounting keep zero-value tax lines when they are needed for correct tax repartitioning. It reduces the risk of missing tax details in invoices or accounting entries, supporting more accurate reporting and compliance workflows.
Original PR description
opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
Some internal system labels in the Base module were incorrectly eligible for translation. This fix keeps those strings unchanged across languages, reducing confusion in configuration screens and ensuring consistent technical labels.
Original PR description
The point of sale now keeps the cashier on the payment screen if the session becomes idle during an online payment. This prevents the active order from losing its context, avoiding confusing empty tickets or unfinished orders after the customer completes payment.
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When operators add or increase components on a manufacturing order that is already in progress, Odoo now updates the related stock transfer to pre-production. This prevents missing material moves in two-step manufacturing flows and keeps shop floor changes aligned with warehouse operations.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. ### Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Community: https://github.com/odoo/odoo/pull/201592 opw-4638371
The Documents file viewer now stays correctly positioned when users scroll horizontally, including in grouped views. This prevents misplaced previews and provides a more consistent document viewing experience.
Original PR description
Previously, the file viewer was misaligned when scrolling horizontally, causing incorrect placement. This fix ensures that the file viewer remains properly positioned, even when scrolling, for a consistent viewing experience. Task-4531591
Invoices using external tax calculators can now keep expected zero-value tax lines so they can be updated with the correct externally calculated tax. This prevents missing journal tax lines on fully discounted invoices where tax is still due, improving accounting accuracy for Avatax and similar integrations.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded. opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
The automated test for the signing flow now closes the final confirmation window instead of trying actions that trigger a download or do not fit the test purpose. This prevents timeout failures and keeps the signing process validation stable after related platform changes.
Original PR description
In this commit, we fix the latest step of tour. We can't click on primary or secondary button ... make no sense. As the primary button download the pdf file and there is no test to ensure the file is well downloaded, it make more sense to click on close the modal. With the fix in https://github.com/odoo/odoo/pull/202089 and without the correction, the tour was timeout exceeded.
Fixes subscription churn reporting when a renewed subscription has different discount terms than the original. Churn amounts are now based on previous monthly recurring revenue logs, preventing misleading negative revenue figures after cancellations.
Original PR description
Steps to reproduce: - Install `sale_subscription` - Create a sub with a discount - Confirm and invoice it - Renew the sub without the discount - Confirm the renewal - Remove the discount on the original sub via the shell since it's locked (simulate first year discount removal) - Cancel the renewal Issue: MRR log is now negative, this is due to how the way `amount_signed` is computed during the churn event creation. Recurring monthly is now greater because we deleted the first year discount, which results in negative MRR. https://github.com/odoo/enterprise/blob/5a7b55f9e059c3b54492e184d1e2429779399d08/sale_subscription/models/sale_order_log.py#L174 Solution: Compute `amount_signed` using the sum of the previous logs.
This update resolves several issues affecting accounting, manufacturing, field service, delivery tests, and regional reporting. It also adds Spain's Modelo 130 tax report and improves Belgian CodaBox workflows, helping users get more accurate reports, clearer screens, and fewer posting errors.
Payment notification emails for SEPA Direct Debit are now sent in the customer’s preferred language instead of always defaulting to English. This helps customers receive clearer, localized communication when direct debit payments are processed.
Original PR description
Direct Debit payment notification email was always sent in english regardless of customer language. **Steps to reproduce:** * Configure SDD creditor identifier in accounting settings * Bank Journal should have valid bank account * Customer record have different language than user's language and have valid IBAN bank account * Create Direct Debit mandate for this customer * Pay an invoice for this customer with SDD payment method * Create batch payment for this payment and validate it. * The payment notification email should be sent on payment chatter with wrong language. Video: https://drive.google.com/file/d/1jzlALs4SJRtOA5gPBt_xo0m8r7kpZd_m/view opw-4552438