Daily updates from Odoo
Navigate
Branch
Thursday, November 20, 2025
196 changes
20 changes
New functionality added to Odoo
This change adds the EC Sales List report for Finland, including the corresponding export file. It helps businesses meet VAT reporting requirements more easily by producing the needed report in Odoo.
Original PR description
The aim of this commit is adding the Finnish EC Sales List report. task-5126664 Forward-Port-Of: odoo/enterprise#99854 Forward-Port-Of: odoo/enterprise#95901
Enhancements to existing features
This update adds triangular taxes to Finnish tax reporting so they can be used in the EC Sales List report. It helps ensure cross-border sales are reported more accurately for businesses operating in Finland.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-5126664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236427 Forward-Port-Of: odoo/odoo#229269
Resolved issues and error corrections
This change removes a unit test that depended on a different add-on and on Enterprise-only fields, which caused automated builds to fail. The test will be reintroduced later in the appropriate module if needed, helping keep the codebase stable and build results reliable.
Original PR description
The unit test `test_can_reset_deferred_invoice()` has several issues. 1. It should be in the `account_audit_trail` module, as the test requires this module. [Unit test documentation: modules](https://www.odoo.com/documentation/19.0/developer/tutorials/unit_tests.html#modules). 2. The test references fields from the Enterprise module `account_accountant`, `account.move.line.deferred_start_date` and `account.move.line.deferred_end_date`. This causes build tests to fail. As such, the test should be removed now and replaced later if necessary. Fixes [PR 235223](https://github.com/odoo/odoo/pull/235223) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235813
When a purchase quotation is shared by email, the “View Quotation” button now points to the correct company website instead of the default database address. This ensures customers and portal users land on the right online page, especially in multi-company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Host a server with demo data on localhost; 2. create & switch to a second company; 3. have a website linked to the second company; 4. set the website's domain to http://2.localhost:8069; 5. create a purchase order; 6. send order via email; 8. open mail via Settings / Technical / Email / Emails. Issue ----- The "View Quotation" button links to the default URL instead of the second company's website. Cause ----- The button added via `_notify_get_recipients_groups` only adds a relative URL, which then defaults to the database's base url when sent. Solution -------- Use an absolute URL, using the order's `get_base_url` method. opw-5035391 Forward-Port-Of: odoo/odoo#236438 Forward-Port-Of: odoo/odoo#233255
This change updates a test so it uses the same product editing flow a user would follow in the interface. As a result, the expected validation error is now correctly triggered, improving the reliability of the test suite and preventing false failures.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL:…
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL: TestEventProduct.test_ensure_event_service_tracking > AssertionError: ValidationError not raised Cause ----- The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30 This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183 As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised. Solution -------- Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected. runbot-234024 Forward-Port-Of: odoo/odoo#236045
When a Stripe payment fails due to a server validation or API error, the Point of Sale screen will now show the message instead of hiding it. This helps staff quickly understand what went wrong and retry or correct the payment without guessing.
Original PR description
Before this commit: =================== Previously, Stripe-related RPC calls used `silentCall`, which suppresses backend errors and prevents them from being displayed in the POS UI. As a result, users were unable to see important validation or API failure messages coming from the server After this commit: ====================== Use `call` instead of `silentCall`. Using `call` allows backend exceptions and validation errors to be propagated to the POS frontend, ensuring that the user receives clear feedback when a Stripe request fails. Task-4976972 Forward-Port-Of: odoo/odoo#236009
This fixes an error that could appear in Manufacturing when a line was left without a product name and the schedule date was changed. The update prevents the system from crashing on incomplete lines, making it safer to edit manufacturing orders.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234884
The point-of-sale now loads only draft delivery orders when a session starts, instead of loading every delivery order. This reduces startup delays and improves overall performance; a minor console warning on the delivery button was also removed.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904We fixed an issue that could block invoice creation for alternative upsell subscription orders. The system now carries over the correct invoice date information, so invoices can be generated successfully after an alternative order is confirmed.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99831 Forward-Port-Of: odoo/enterprise#98983
When importing bank statements from CSV, some validation errors during automatic reconciliation no longer cancel the imported lines. This means users can still review and reconcile the statement manually instead of losing the import and starting over.
Original PR description
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install…
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install "account_bank_statement_import_csv" - In the bank journal configuration: - Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account - Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account - Create a new transaction for $333.0 for example - Find its Journal Entry and change its reference to 'testref' - have a CSV file like this: ``` label, amount testref,333 ``` - Import this file - Make sure label is linked to label and amount to amount - Import - An error shows, no lines are imported ### Cause: On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192). This rollback cancels the transaction, including the creation of the statement lines. ### Solution: If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward. Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable. Test is not possible as we don't roll back during tests. opw-5138855 Forward-Port-Of: odoo/enterprise#99073
This fix ensures exchange difference entries are linked to the correct invoices when multiple invoices are paid together in one grouped payment. It prevents invoices from being associated with the wrong exchange entry, so payment and reconciliation records stay accurate.
Original PR description
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create…
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create a group payment dated today. Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices. Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed. It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`. In a group payment scenario: - Two partials are created (one per invoice). - Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line). - As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment. opw-5147281 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#235324
This fixes an accounting error that could produce different journal balances when a foreign-currency invoice was duplicated or when the exchange rate was entered in a different place. The tax amounts are now calculated consistently using the company’s global rounding method, which helps keep invoice totals accurate and reproducible.
Original PR description
- Set the tax rounding method to `'global'` in the settings. - Create an invoice in a foreign currency with: - Quantity: `0.80` - Unit Price: `894.34` - Currency rate set on the invoice: `1 / 1189.5` - This results in a journal entry balance of **851,051.57**. - Now set the currency rate directly on the currency instead. - Duplicate the invoice: the journal entry balance becomes **851,053.94**. The issue arises because _sync_tax_lines, triggered when setting the currency rate directly on the invoice, was computing the journal entry balance on a per-line basis, even though the tax rounding method was configured as global. opw-5012817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225407
This fix makes the rating cards in Website Slides use the same background color as the rest of the page. It improves visual consistency so the module matches the intended website theme more cleanly.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" /> Forward-Port-Of: odoo/odoo#236527
This change prevents delivery validation from failing when a sales order contains a down payment line. It ensures only real product lines are used for customs price calculations, so shipments can be confirmed without error.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This fix prevents the chosen warehouse from being replaced when enabling additional inter-company order options. It ensures each company keeps its intended warehouse setting, avoiding unexpected changes in purchase and sales setup.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
This change moves a small customization to the module that actually depends on the portal features. It keeps the code organized correctly and reduces the risk of future maintenance issues.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236436 Forward-Port-Of: odoo/odoo#236249
This fix makes sure preparation displays are updated when staff transfer, merge, link, or unlink tables in the POS. It also prevents duplicate kitchen orders from being created when orders are combined and lines are cancelled, helping the kitchen screen stay accurate and consistent with the sales screen.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/odoo#233630
This fix ensures Preparation Displays update correctly when POS table actions are used, such as transfer, merge, link, or unlink. It prevents mismatches between the order seen at the POS and what appears on kitchen screens, improving accuracy during service.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/enterprise#98374
Live chat visitors can no longer initiate call sessions. This closes a loophole in the server-side checks so the restriction is enforced consistently, helping prevent unintended call requests from unauthenticated users.
Original PR description
In [1], we fixed an issue where the start call button would be visible to portal partners. We do not want visitors to initiate calls on live chats. However, there also is a guard in the `rtc` controller which only checks that public users cannot start calls. The server code should also be adapted to properly ensure no live chat visitor can start a call. [1]: https://github.com/odoo/odoo/pull/236272 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#236495
This change fixes an error that could happen when viewing chat reports grouped by help status. It removes an incorrect lookup path so the report opens normally when agents click those results.
Original PR description
The `help_status` field of the channel member history model is used to quickly find sessions where help was requested/provided. However, the field exposes a `_search` method that doesn't exists which lead in a crash when clicking on the agent report bars when grouping by `help_status`. This field is stored so we don't need the search. 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
12 changes
Resolved issues and error corrections
When a purchase quotation is emailed from a company with its own website, the View Quotation button now opens the right website instead of the default one. This prevents customers from being sent to the wrong domain and improves the experience for multi-company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Host a server with demo data on localhost; 2. create & switch to a second company; 3. have a website linked to the second company; 4. set the website's domain to http://2.localhost:8069; 5. create a purchase order; 6. send order via email; 8. open mail via Settings / Technical / Email / Emails. Issue ----- The "View Quotation" button links to the default URL instead of the second company's website. Cause ----- The button added via `_notify_get_recipients_groups` only adds a relative URL, which then defaults to the database's base url when sent. Solution -------- Use an absolute URL, using the order's `get_base_url` method. opw-5035391 Forward-Port-Of: odoo/odoo#236438 Forward-Port-Of: odoo/odoo#233255
The point of sale now loads only draft delivery orders when a session starts, instead of pulling in every delivery order. This reduces startup delays and improves overall performance for users. A console warning was also removed from the delivery button component.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904This fix stops the system from crashing when a manufacturing order line is left without a product name and the schedule date is changed. It helps users continue editing draft or incomplete orders without running into an error.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234884
Hover animations on website card images could leave visible white gaps around the image. This update keeps the image filling its container properly, so pages look cleaner when editors enable hover effects.
Original PR description
Step to reproduce: 1. Open website 2. Click edit button and drop s_three_columns snippet 3. Click image and change animation option into hover 4. Some extra white space shown. Before this commit: Applying a hover animation on card images caused the `object-fit` property to unintentionally switch from `cover` to `contain`, resulting in visible white borders around the image.This happened because of the `geo_square` shape, which is automatically injected when a hover effect is applied and no user shape is chosen. This behavior was intentionally introduced in PR [1]. After this commit: Now cropped images use object-fit: contain to preserve the visible properly. and after stretch option apply it can take cover of this container. so his ensures the image fully covers its container without leaving any white gaps. [1]:https://github.com/odoo/odoo/pull/119197 task:4875770 Forward-Port-Of: odoo/odoo#215766
This update makes the rating cards in Website Slides use the same background color as the rest of the page area. It improves visual consistency so the interface looks more polished and matches the website theme better.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" /> Forward-Port-Of: odoo/odoo#236527
This update corrects how invoice totals are recalculated when a currency rate is changed directly on the invoice. It ensures tax rounding stays consistent with the global rounding setting, so duplicated invoices keep the same balance and avoid small but important discrepancies.
Original PR description
- Set the tax rounding method to `'global'` in the settings. - Create an invoice in a foreign currency with: - Quantity: `0.80` - Unit Price: `894.34` - Currency rate set on the invoice: `1 / 1189.5` - This results in a journal entry balance of **851,051.57**. - Now set the currency rate directly on the currency instead. - Duplicate the invoice: the journal entry balance becomes **851,053.94**. The issue arises because _sync_tax_lines, triggered when setting the currency rate directly on the invoice, was computing the journal entry balance on a per-line basis, even though the tax rounding method was configured as global. opw-5012817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225407
This fix prevents Odoo Studio from crashing when a user adds a Selection field option without typing a value first. Instead of showing an error, the interface now handles the empty input safely, making field configuration more reliable and forgiving.
Original PR description
**Before this commit:** When a user added a new Selection field and clicked the “Add Selection” :white_check_mark: button without entering any value, a `Client Error: (Cannot read properties of undefined (reading 'trim'))` was raised, resulting in a crash of the Studio interface. **After this commit:** Clicking the “Add Selection” :white_check_mark: button with an empty input no longer triggers an error. task-5159376 Forward-Port-Of: odoo/enterprise#99783 Forward-Port-Of: odoo/enterprise#98767
This change moves a messaging override to the module that actually depends on portal features. It keeps the code structure correct and reduces the risk of future maintenance issues without changing how users interact with the feature.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236436 Forward-Port-Of: odoo/odoo#236249
This change prevents an error when validating a Sendcloud delivery after a down payment invoice has been created. It ensures non-product sale lines are ignored during customs price calculation, so delivery processing continues normally.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This fix prevents the system from resetting the chosen warehouse when inter-company order options are changed. It ensures the warehouse previously selected by the user stays in place, which avoids confusion and keeps company settings consistent.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
This update prevents the message composer from failing when no message is attached to it during suggestion loading. It ensures the related thread is treated as unavailable in that case, which avoids an error and keeps suggestions working reliably.
Original PR description
This commit solves a runbot issue created by the debounced nature of the suggestion fetch. A composer could not have a message associated with it and was therefore failing to find the related thread. Now, the thread is set to undefined in that case since we do not need the result anyway. fixes-runbot-230311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236262
This update makes the point-of-sale black box integration more resilient when the device responds incorrectly or not at all. It now follows the documented retry behavior, which helps reduce failed transactions caused by temporary communication issues.
Original PR description
Following documentation, max timeout should be 1.5s and we should retry 3 times on every bb NACK/invalid data. Forward-Port-Of: odoo/enterprise#99705
7 changes
Resolved issues and error corrections
The POS now loads only draft delivery orders when a session starts, instead of pulling in every delivery order. This reduces startup delays and makes the point of sale feel faster. A console warning related to the delivery button was also removed.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904This fix prevents the warehouse choice in Inter-Company Transactions from being reset when another related setting is turned on or off. It ensures the warehouse a user selected stays in place, which avoids unexpected changes to purchasing and sales behavior across companies.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
Fixes an issue in Studio where adding a new selection option without typing a value could crash the interface. Users can now click Add Selection with an empty input without triggering an error, making field setup more forgiving.
Original PR description
**Before this commit:** When a user added a new Selection field and clicked the “Add Selection” :white_check_mark: button without entering any value, a `Client Error: (Cannot read properties of undefined (reading 'trim'))` was raised, resulting in a crash of the Studio interface. **After this commit:** Clicking the “Add Selection” :white_check_mark: button with an empty input no longer triggers an error. task-5159376 Forward-Port-Of: odoo/enterprise#99783 Forward-Port-Of: odoo/enterprise#98767
This fix avoids a crash when validating Sendcloud deliveries for sales orders that include down payment lines. It ensures these non-product lines are ignored during customs price calculation, so deliveries can be confirmed normally.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This update removes duplicate methods found across a few enterprise modules. It does not change business behavior, but it makes the codebase cleaner and easier to maintain, which helps reduce the risk of future issues.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99867 Forward-Port-Of: odoo/enterprise#99809
This change prevents an error from appearing in Documents when a CRM lead linked to an upload document activity has been deleted. The document now handles the missing source record gracefully, so users can open Documents without seeing a traceback.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
This update prevents spreadsheets from crashing when users create or edit global filters while some datasources are no longer valid after a migration or model change. It also makes cleanup easier by showing delete options more consistently for broken datasources, helping users recover spreadsheets faster.
Original PR description
Forward-Port-Of: odoo/enterprise#98448
21 changes
Enhancements to existing features
The IoT module files were reformatted using a standard formatting tool to make the codebase more consistent and easier to maintain. This is an internal cleanup with no expected change to user-facing behavior, and future checks will help keep the formatting consistent.
Original PR description
This commit formats all the files in the `iot` module using `prettier`. This formatting will be enforced by the ESLint test (see associated Community PR https://github.com/odoo/odoo/pull/236516).
Users can now mark or unmark documents as favorites directly from the list view, matching the behavior already available in Kanban view. The shortcut only appears when documents are selected, reducing clutter and making the action more relevant.
Original PR description
- Previously, toggling favorites was only supported in the Kanban view and not available in the list view. - Favorites can now be toggled in the list view, and provide consistency across all views. - Additionally, the shortcut command is now only available when at least one record is selected, as it doesn't make sense to show the command when no documents are selected. Task-4822074
Payroll users can now remove work entry export records for several Belgian payroll providers. This helps teams correct or clean up exported payroll data when records are no longer needed.
Original PR description
*={acerta,group_s,partena,prisma,sd_worx,ucm}
Payroll users should be able to delete the work entry export records.
task-5050476The default Administrator employee is no longer included in standard company data and is only available with demo data. This keeps new databases cleaner and avoids an incomplete placeholder employee getting in the way, while users can still create an Administrator employee when needed.
Original PR description
## Purpose The default administrator employee (in master data) sometimes can get annoying, making it difficult to code easy features. Moreover, almost all the fields of this employee are empty, and the user can easily create its own Administrator employee by clicking the "Create Employee" button from the Admin User View. ## Solution Moving the admin employee to the demo data. [community#232627](https://github.com/odoo/odoo/pull/232627) [upgrade#8806](https://github.com/odoo/upgrade/pull/8806) [task-5138634](https://www.odoo.com/odoo/all-tasks/5138634)
This update adds support for UK EC Sales and Intrastat return reporting. It helps businesses prepare required cross-border trade declarations more consistently within Odoo.
This update aligns several business workflows with a platform change where asking for zero records now correctly returns none. It helps avoid unintended records appearing in manufacturing planning, subscriptions, and barcode/package operations when a zero-result limit is expected.
Original PR description
https://github.com/odoo/odoo/pull/234231
The manufacturing work order display no longer keeps an unused reference in its setup logic. This removes outdated code tied to a previous storage naming approach, reducing confusion and making future maintenance safer.
Original PR description
Picking type Was only used in the previous local storage key name and was undefined. see odoo/enterprise#88073 (original PR) see odoo/enterprise#93841 (Fix PR were we remove the `picking_type_id` key from local storage name)
Installing an accounting chart template for countries in the SEPA zone now also installs ISO 20022 payment support. This helps businesses in those countries get the right bank payment capabilities automatically, reducing manual setup.
Original PR description
This commit will allow to install account_iso20022 when installing a chart template from the SEPA zone. task-5163045 Forward-Port-Of: odoo/enterprise#97209
The U.S. direct deposit settings are now connected to the community accounting setup, making them easier for users to discover in the right place. This improves configuration clarity without changing the direct deposit feature itself.
Original PR description
Change the new settings panel from being defined in enterprise to being defined in l10n_us_account and overriden here for proper discoverability. task-5080414
Resolved issues and error corrections
This fix prevents duplicate or incorrect tax closing entries when multiple tax reports exist for the same country. It ensures each eligible report only uses the relevant tax lines, disables duplicate return generation where reports overlap, and moves some reports to a review-and-submit flow when no closing entry is needed.
Original PR description
It's possible for different tax reports to exist in the same country, each with its own return type. However, this is an issue when they aren't configured to generate closing entries with distinct contents, since each of them will then repeat the content of the other. To fix this, when it's legitimate to make multiple closing entries, we make sure the closing entry only considers the tax move lines linked to the report's tax tags. If multiple reports must generate the same closing entry (typically because one of them is a simplified version of the other), we disable the generation of the return for one of them. Some reports also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564 Forward-Port-Of: odoo/enterprise#99182 Forward-Port-Of: odoo/enterprise#98158
This fixes a failure that prevented users from uploading videos to YouTube from Odoo when the older jQuery library was unavailable. The upload process now uses modern browser methods while preserving upload progress feedback.
Original PR description
Issue: when trying to upload a video to youtube, we receive an error as "ReferenceError: $ is not defined" meaning we're not able to reach the jQuery identifier. So following the trend we're moving away from jQuery, this commit removes the usage of jQuery in the youtube upload field. - Replaced $.ajax() with fetch() in _openUploadSession, _updateProcessingInfo, and _onClearClick methods - Replace $.ajax() with XMLHttpRequest in _uploadFile to maintain upload progress tracking opw-5142810 Forward-Port-Of: odoo/enterprise#97364
Fixes an issue where reusing a saved AI live chat website block could crash the website editor. Users can now save and re-add the AI chat snippet from custom blocks without interruption.
Original PR description
Steps to reproduce: ------------------------- 1. Install Website and AI modules. 2. Open the website editor. 3. From the Intro block, search for the AI snippet and add the snippet contains 'Need…
Steps to reproduce:
-------------------------
1. Install Website and AI modules.
2. Open the website editor.
3. From the Intro block, search for the AI snippet and add the snippet contains 'Need Help?'.
4. Click on the added block, then click the Save icon from the Style tab.
5. Save the snippet
6. Go to Blocks → Custom Blocks and add the saved snippet.
Observation:
-------------------------
A traceback is raised:
```
TypeError: Cannot read properties of null (reading 'remove')
at AILivechatOptionPlugin.onSnippetDropped
```
Issue:
-------------------------
The `onSnippetDropped` method
https://github.com/odoo/enterprise/blob/bb3699cc112acb3ec545d3aa5f3d8f7263a5dac6/ai_website_livechat/static/src/website/plugins/ai_livechat_option_plugin.js#L39-L51 executes every time a snippet is dropped into the layout. When the snippet is first added, the method removes the `<div>` with class `s_ai_livechat_preview`. Upon saving, the snippet is stored without that `div`. When re-adding the saved snippet from custom tab, the method runs again but fails since the `s_ai_livechat_preview` element no longer exists, resulting in the traceback.
Solution:
-------------------------
Added the optional chaining operator to safely remove the `s_ai_livechat_preview` div only when it exists.
opw-5227072
Forward-Port-Of: odoo/enterprise#99276The Copy to Clipboard option now appears correctly for regular conversations when the AI module is installed. This fixes a visibility issue in message actions and adds test coverage to help prevent the problem from returning.
Original PR description
Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content. This happens because message actions can condition overridden by some…
Before this commit, "Copy to Clipboard" was sometimes not visible in the message action list when message had some text content. This happens because message actions can condition overridden by some other modules, and the way overrides of action condition work is to have boolean value taking precedence over the local condition of action. This architecture is meant to provide exhaustive list of actions to allow, which is quite useful to control what livechat visitors can have. However this architecture requires overrides to properly return `undefined` when the local condition should apply, which was not the case for an override by `ai` module. So when `ai` module is installed, the "copy to clipboard" feature as not available. This commit fixes the issue by adapting the condition in `ai` module to return `undefined` on non-AI conversations, and add test coverage for both `@mail` discuss suite and all overrides of discuss in `@test_discuss_full_enterprise`. opw-5240768 https://github.com/odoo/odoo/pull/236295 Forward-Port-Of: odoo/enterprise#99794
The IoT connection flow now checks the device token before looking up older device records. This prevents unnecessary error logs when an IoT box reconnects after being unpaired or used with another database.
Original PR description
Steps to reproduce: 1. Connect an IoT box 2. Now unpair it from the IoT box homepage (record stays in DB) 3. Connect the same box again to a different DB but with the same IP (e.g. when a developer switches branch) 4. Now go back to the original DB 5. Observe a traceback in the DB logs when the IoT calls /iot/setup (`cannot access id on NoneType`) This traceback occurs because we were checking for an old IoT box record before checking if the token matches. We simply swap the checks around to prevent the traceback.
Website content generation issues are now recorded as warnings instead of errors when they do not block the user. This keeps monitoring reports cleaner while users still receive the appropriate notification when generation fails.
Original PR description
- Currently, we log an error whenever an error occurs during content generation for any webpage. - However, it is a non-blocking error so it can be safely converted to a `_logger.warning`, as we already notify user about the error through a notification [1]. - Additionally, the errors caught here will be all UserErrors so no need to log another error, so we log a warning instead. - This commit converts the `_logger.error` into `_logger.warning`. [1]: https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/ai_website/static/src/components/dialog/add_page_dialog.js#L74-L80 sentry-6974000714 Forward-Port-Of: odoo/enterprise#98844
This fix prevents the inter-company transaction settings from replacing a company's chosen warehouse when purchase order generation is enabled. Businesses with multiple companies and warehouses can keep the correct warehouse assignment, reducing order routing mistakes.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
CSV bank statement imports now keep imported statement lines even when automatic reconciliation hits a user-facing error. Users can still complete reconciliation manually afterward, reducing failed imports and repeated work.
Original PR description
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install…
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install "account_bank_statement_import_csv" - In the bank journal configuration: - Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account - Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account - Create a new transaction for $333.0 for example - Find its Journal Entry and change its reference to 'testref' - have a CSV file like this: ``` label, amount testref,333 ``` - Import this file - Make sure label is linked to label and amount to amount - Import - An error shows, no lines are imported ### Cause: On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192). This rollback cancels the transaction, including the creation of the statement lines. ### Solution: If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward. Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable. Test is not possible as we don't roll back during tests. opw-5138855 Forward-Port-Of: odoo/enterprise#99073
This fix prevents Sendcloud delivery validation from crashing when a sales order includes a down payment line. It ensures only real product lines are used for customs price calculations, allowing affected shipments to be processed normally.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
Users with the right manufacturing and timesheet permissions can now finish work orders even when the related project is assigned to someone else. This prevents an access error during analytic accounting entries, reducing interruptions on the shop floor.
Original PR description
Steps to reproduce: - Enable Analytic Accounting. - Assign a project A to User A. - Create user B with Manufacturing User + Timesheet User rights. - Create a storable product “P1” with the following…
Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
- Component: 1 unit of C1
- Workorder: Operation of 60 minutes
- Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
- confirm the MO
- start the workorder and try to mark it as done.
Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"
Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62
Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.
opw-5262213
Forward-Port-Of: odoo/enterprise#99716Italian POS users can now reprint the exact past order receipt they select, instead of accidentally printing the most recent receipt. This prevents customer service and record-keeping errors when businesses need copies of older receipts.
Original PR description
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian…
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian POS 2. make 2 sales with a different product (easier tracking) 3. open the "orders" view 4. try to reprint the ticket of the firt order result: the receipt of the second order is printed the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt. With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt. IMPORTANT NOTE: In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner. opw-5008702 opw-4882480 Forward-Port-Of: odoo/enterprise#99842 Forward-Port-Of: odoo/enterprise#96122
Fixed an issue where using backspace on the VoIP keypad did not delete highlighted characters when the selection started at the beginning. This restores expected editing behavior for users entering or correcting phone numbers while preserving safeguards against cursor errors.
Original PR description
This commit fixes a regression introduced in commit [1] prevented deleting when a selection began at index 0; extend the guard so the numpad (keypad) backspace still removes the highlighted characters while keeping the cursor-safety logic. [1]: https://github.com/odoo/enterprise/commit/73b01fa5e1f56d4ab71d67760b15942fb2fa0e31 task-5217676 Forward-Port-Of: odoo/enterprise#99835 Forward-Port-Of: odoo/enterprise#99358
34 changes
Enhancements to existing features
This change lets users specify the place where a service was delivered using the delivery address on a sales order or invoice. That address is now sent to the Brazilian tax and e-invoicing flow, so the issued service invoice can show the correct city where the service was provided.
Original PR description
Purpose: In Brazil, it is common for companies to sell services in one city and provide the services in another city, thus, it is necessary to inform the place of service provision in NFS-e. Users can specify where the service was provided through the delivery addresss on either sale order or invoice. The delivery address will be sent in the request to the tax calculation and edi. Outline of additional attributes being sent: - header.locations.rendered.address.street --> partner_shipping_id.street - header.locations.rendered.address.neighborhood --> partner_shipping_id.street2 - header.locations.rendered.address.zipcode --> partner_shipping_id.zip - header.locations.rendered.address.cityName --> partner_shipping_id.city - header.locations.rendered.address.state --> partner_shipping_id.state_id.code - header.locations.rendered.address.countryCode --> partner_shipping_id.country_id.l10n_br_edi_code task-5124608
The Philippine location database now includes all official provinces as states. This improves address accuracy and makes it possible to configure payroll and other processes at the province level.
Original PR description
Before: -The Philippine localization lacked province data in res.country.state. -Address and payroll setups couldn’t use province-level information. After: -Added all official Philippine provinces as states under the Philippines. Impact: -Improves address accuracy and enables province-based payroll configuration. task-5257793
The IoT service now loads IoT Box information in advance, which helps requests keep working even when connectivity is limited. It also reduces the number of database calls, improving responsiveness and lowering system load for related POS and self-order flows.
Original PR description
In order to allow iot requests to work offline, and also reduce the amount of orm requests sent to the db, we now preload IoT Box records in the `iot_http` service. Task: 5258886 Forward-Port-Of: odoo/enterprise#99910
This update clears existing UrbanPiper menu links and rebuilds them from scratch during synchronization. It helps keep the restaurant menu shown in UrbanPiper accurate and reduces the risk of outdated or duplicated menu connections.
Original PR description
Following this commit: - Flush out all existing UrbanPiper product menu linkages and performs a fresh menu sync. task-5231247 Forward-Port-Of: odoo/enterprise#98994
Resolved issues and error corrections
Website visitors with translation enabled can now edit translatable fields again, such as product names on translated pages. This fixes a regression that prevented some content from being updated in the right language while keeping menu translation behavior working correctly.
Original PR description
[FIX] html_builder, website: allow user to translate a field Steps to reproduce the problem: - With french installed on a website, go to `/fr/shop`. - Enter in translate mode. -> You can not edit…
[FIX] html_builder, website: allow user to translate a field Steps to reproduce the problem: - With french installed on a website, go to `/fr/shop`. - Enter in translate mode. -> You can not edit product names. The problem is that since [1], regular fields are not translatable. This commit does two things: - It modifies the `o_editable_selectors` selector in edit mode to allow translation of regular fields. - Because we revert the logic of [1], the problem that was solved by this commit (translation of a mega menu item) still has to be fixed. To do so, the `o_editable` or `o_editable_attribute` is removed when setting the `data-oe-readonly` attribute on cascaded branded elements. The idea is to follow the same logic than in the `SetupEditorPlugin` where elements with the `data-oe-readonly` attribute are filtered before adding the `o_editable` class. task-5265949 [1]: https://github.com/odoo/odoo/commit/d4d428ff1d5be46135973aa806f206a1076bfcf7 Forward-Port-Of: odoo/odoo#235800
This change adjusts an automated test so it follows the same product-editing flow a user would use in the interface. As a result, the system now correctly detects and reports invalid event ticket settings during testing, preventing false test failures.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL:…
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL: TestEventProduct.test_ensure_event_service_tracking > AssertionError: ValidationError not raised Cause ----- The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30 This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183 As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised. Solution -------- Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected. runbot-234024 Forward-Port-Of: odoo/odoo#236045
This update makes the Discuss app look cleaner on desktop by reducing extra header spacing, fixing a clipped badge in the sidebar, and lowering the message composer. It also aligns typing and livechat guidance with the standard chat window behavior, making the interface feel more consistent and easier to use.
Original PR description
Minor style improvements to discuss app in desktop: - less vertical padding of the header - no cropped badge on mailbox below "New meeting" in sidebar compact - composer is lower The composer was…
Minor style improvements to discuss app in desktop: - less vertical padding of the header - no cropped badge on mailbox below "New meeting" in sidebar compact - composer is lower The composer was higher to give room for "is typing" and "Tab to next livechat" features that were at bottom of composer in discuss app. They were changed to match chat window style: - "is typing" is above composer - "Tab to next livechat" is suggested in placeholder of composer Before (left) / After (right) <img width="1521" height="792" alt="Screenshot 2025-11-18 at 19 05 55" src="https://github.com/user-attachments/assets/216dd9de-601b-44fe-9169-66f50a243992" /> Before <img width="959" height="997" alt="Screenshot 2025-11-18 at 18 23 27" src="https://github.com/user-attachments/assets/9d9dfef0-8412-4a38-b0c7-7f9c66b084e5" /> After <img width="958" height="993" alt="Screenshot 2025-11-18 at 19 05 12" src="https://github.com/user-attachments/assets/cd6a9d14-e058-4159-920c-69778c6b3ec9" />
This fix restores the missing expand/collapse icon in email-style messages when quoted content is shown with a read more/less control. It improves the readability and usability of messages in the web interface by making the toggle button visible again.
Original PR description
Before this commit, when a message is of type "email" and contains parts are in foldable with more/less (like `<quote>`), the icon of the button for fold/unfold is missing. This happens because the icon is `.oi` and requires `odoo_ui_icons`. Message of type "email" have their content inside a shadow DOM, because we want to preserve the style of email inside the web client, at least in white theme. Shadow-DOM prevents the parent document to pass `odoo_ui_icons` thus the Shadow-DOM could not apply expected style on `.oi` icons. This commit fixes the issue by passing the required CSS as stylesheet to the shadow DOM, so that `.oi` icons are working inside the shadow DOM of message content of type "email". Forward-Port-Of: odoo/odoo#228741
This change prevents an error in payroll-related calculations when an employee contract does not have a start date. It makes the system handle incomplete employee data more safely, which helps tests and background updates run reliably.
Original PR description
The test_version_cron_update_no_fields from hr/tests/test_hr_employee.py didn't pass on runbot saas-18.4 due to the absence of a start date of contract leading to an error when trying to substract False to a datetime object. I added a verification in the concerned compute function in order to ensure the employee has a contract_date_start. If it's not the case, I set it to 0 as the compute method needs to compute the target field. Runbot error: 233590 Forward-Port-Of: odoo/enterprise#99815
When a Stripe payment fails because of a server-side validation or API issue, the point of sale now shows the error message to the user instead of hiding it. This helps staff understand what went wrong and resolve payment issues faster.
Original PR description
Before this commit: =================== Previously, Stripe-related RPC calls used `silentCall`, which suppresses backend errors and prevents them from being displayed in the POS UI. As a result, users were unable to see important validation or API failure messages coming from the server After this commit: ====================== Use `call` instead of `silentCall`. Using `call` allows backend exceptions and validation errors to be propagated to the POS frontend, ensuring that the user receives clear feedback when a Stripe request fails. Task-4976972 Forward-Port-Of: odoo/odoo#236009
This update makes the rating cards in Website Slides use the same background color as the rest of the page. It improves visual consistency so the interface looks cleaner and better aligned with the site theme.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" /> Forward-Port-Of: odoo/odoo#236527
The POS now loads only draft delivery orders when a session starts, instead of pulling in every order. This reduces startup delays and makes the delivery flow smoother. A small console warning in the delivery button was also removed.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99904This fix prevents the warehouse setting from being reset when users toggle inter-company order options. It ensures the warehouse they already chose stays in place, avoiding accidental changes to a different warehouse and reducing setup errors in multi-company environments.
Original PR description
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use…
Issue: -------- While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse". Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before is getting overridden to the first Warehouse which has minimal 'id'. Cause: ------ [Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1). Solution: ----------- To fix this, we'll just check if there's no value set before. If yes, then we'll set the first warehouse which has minimal 'id'. Otherwise, set the one which is selected. Steps to reproduce: ------------------------- 1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed. 2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save. 3. Now check/select the 'Generate Purchase Orders' and save. 4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'. Ref PRs: 1. https://github.com/odoo/enterprise/pull/55350 Forward-Port-Of: odoo/enterprise#87276
When users open the shop floor from a Manufacturing Order, the app now starts on the correct work center and shows the current order. This avoids landing on the wrong screen and makes returning to the shop floor app behave consistently for users.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#99855 Forward-Port-Of: odoo/enterprise#93841
This fixes a problem where group payments could attach foreign-exchange adjustments to the wrong invoices. As a result, invoice reconciliation now shows the correct exchange difference for each invoice, improving accounting accuracy and reducing confusion.
Original PR description
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create…
# How to reproduce the issue: - Create two currency rates: one for today and one for the day before. - Create two invoices with different `amount_total`, both using the rate from yesterday. - Create a group payment dated today. Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices. Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed. It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`. In a group payment scenario: - Two partials are created (one per invoice). - Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line). - As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment. opw-5147281 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#235324
This fix prevents Manufacturing orders from crashing when a move line has no product name or unit of measure assigned. It ensures users can still change the scheduled date without triggering an error, improving stability during order updates.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234884
This fix ensures invoices in foreign currencies are rounded consistently when tax totals are recalculated. It prevents small but important differences in journal entry amounts when the exchange rate is set in different places, which helps keep accounting results accurate and consistent.
Original PR description
- Set the tax rounding method to `'global'` in the settings. - Create an invoice in a foreign currency with: - Quantity: `0.80` - Unit Price: `894.34` - Currency rate set on the invoice: `1 / 1189.5` - This results in a journal entry balance of **851,051.57**. - Now set the currency rate directly on the currency instead. - Duplicate the invoice: the journal entry balance becomes **851,053.94**. The issue arises because _sync_tax_lines, triggered when setting the currency rate directly on the invoice, was computing the journal entry balance on a per-line basis, even though the tax rounding method was configured as global. opw-5012817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225407
When importing bank statement CSV files, the system now preserves the statement lines even if an automatic reconciliation step raises a user-facing error. This means users can still see and process the imported lines manually instead of losing the import altogether.
Original PR description
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install…
### Issue: When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed. ### Steps to reproduce: - Install "account_bank_statement_import_csv" - In the bank journal configuration: - Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account - Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account - Create a new transaction for $333.0 for example - Find its Journal Entry and change its reference to 'testref' - have a CSV file like this: ``` label, amount testref,333 ``` - Import this file - Make sure label is linked to label and amount to amount - Import - An error shows, no lines are imported ### Cause: On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192). This rollback cancels the transaction, including the creation of the statement lines. ### Solution: If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward. Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable. Test is not possible as we don't roll back during tests. opw-5138855 Forward-Port-Of: odoo/enterprise#99073
This update prevents regular users from triggering a signature-related option that they are not allowed to access. As a result, the signing flow no longer breaks for non-administrators when this feature is unavailable to them.
Original PR description
This pr is a wip onchange on only_autofill_readonly need to access a field only accessible to system administrator. Disable the feature is the user is not system administrator
This fix prevents overtime work entries from being generated when an overtime ruleset has no rules marked to pay extra hours. It ensures payroll records only include overtime that is actually meant to be compensated, avoiding incorrect work entries and possible payroll confusion.
Original PR description
## Steps to Reproduce 1. Create a Overtime ruleset with **none** of the rules have "Pay Extra Hours" checked. 2. Assign this ruleset to an employee. 3. Generate attendances that normally produce overtime. 4. It will create work entries based on these attendances. Navigate to work entries in payroll. ## Issue Even when none of the rules are checked as "Pay extra hours", It will still generates overtime work entries. ## Fix Filtered out work entries inside `hr.work.entry` create() method: - When the ruleset linked to work entry's version has no paid rules, overtime work entries are skipped and not created. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents an error when validating a Sendcloud delivery on orders that include a down payment invoice. It skips non-product sales lines during customs price calculation, so deliveries can be completed normally without a traceback.
Original PR description
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down…
Steps to reproduce ----- - Create a SO with a sendcloud delivery - Create an invoice for a down payment & confirm it - Go to the delivery and validate it > Traceback Cause ----- Creating a down payment adds lines to the SO https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165 When we confirm the delivery, we retrieve the price of products for customs. https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520 To do this, we iterate over the SOL and skip lines where the product qty is 0 https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528 The problem is that the down payment SOL has no uom. This means that when we do `float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)` precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36 where the assert is false, creating the traceback. ----- Ticket: opw-5207574 Forward-Port-Of: odoo/enterprise#99178
This fix makes JSON fields more tolerant when they receive common business objects such as domains or frozen dictionaries. It reduces the risk of errors when storing and retrieving unstructured data in the system.
Original PR description
The field did not change for quite some time. It mainly serves as a way of storing and retrieving some unstructured data. Use default serialization function when assiging values to Json fields. Some business code may assign domains or frozendicts to json fields. That should not fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix lets users who are not HR officers send feedback requests without running into access errors. It improves the appraisal workflow by allowing employee information to be read safely for this specific action, so the process works as expected for more users.
Original PR description
Since we cannot ask a feedback when we are not an HR officer because we don't have acces to employees and we get an access right error when we try to ask feedback. So we use the hr.public.version mecanism to allow too read the employees without rights.
This update fixes an issue where the push-to-talk microphone could stay active after switching away from the call tab, even if the key had been released. It makes calls more reliable and prevents users from being unintentionally heard after changing tabs.
Original PR description
Before this commit, when using push-to-talk in a discuss call, sometimes the push-to-talk was kept on although user had it released. Steps to reproduce: - do not use discuss extensions' push-to-talk key - start a call - enable push-to-talk with chosen shortcut - press and hold the push-to-talk key - switch to another browser tab while keeping the push-to-talk key pressed (e.g. alt-tab while holding push-to-talk) - release push-to-talk key => Even after a long time and coming back to the call tab, the push to talk is still on This happens because the release of push to talk is designed with keyup intercepted on the call tab. While this happens most of the time, sometimes the keyup is triggered outside of call tab and never in call tab, thus the push-to-talk is not released. This commit fixes the issue by triggering a push-to-talk release when unfocusing the tab. task-[4707634](https://www.odoo.com/odoo/project/1519/tasks/4707634)
Reprinting a previous receipt in the Italian POS now prints the selected order instead of always printing the most recent one. This fixes a customer-facing issue that affected order lookup and receipt reprints at the point of sale.
Original PR description
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian…
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian POS 2. make 2 sales with a different product (easier tracking) 3. open the "orders" view 4. try to reprint the ticket of the firt order result: the receipt of the second order is printed the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt. With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt. IMPORTANT NOTE: In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner. opw-5008702 opw-4882480 Forward-Port-Of: odoo/enterprise#99842 Forward-Port-Of: odoo/enterprise#96122
This change relocates a portal-related customization from the Rating module to the Portal Rating module, where it belongs. It keeps the module structure consistent and reduces the risk of dependencies being mixed up in future updates.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236436 Forward-Port-Of: odoo/odoo#236249
This fixes an issue where the message composer could fail when there was no existing message linked to it. The update makes suggestion loading more reliable, preventing an internal error and improving the user experience.
Original PR description
This commit solves a runbot issue created by the debounced nature of the suggestion fetch. A composer could not have a message associated with it and was therefore failing to find the related thread. Now, the thread is set to undefined in that case since we do not need the result anyway. fixes-runbot-230311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236262
This update makes the Swiss payroll transmission tests work independently from accounting-specific setup. It reduces test coupling, making the payroll module easier to validate and less likely to fail because of unrelated accounting configuration changes.
Original PR description
Forward-Port-Of: odoo/enterprise#99748 Forward-Port-Of: odoo/enterprise#98672
The activity counters in the top bar now show the correct number of late, due today, and future items for Tasks, To-Dos, and Mailings. Previously, multiple activities on the same record could be counted more than once, making the counts appear too high and less reliable.
Original PR description
Issue: When multiple activities were created on a single record (e.g., a Task, To-Do, or Mass Mailing), the systray counters for late/today/future activities would incorrectly count *all* of them. The standard behavior is to count only one (the most urgent) per record. Cause: Modules that split activity groups: `project` (for Tasks/To-Dos) and `mass_mailing` (for Email/SMS), used custom counting logic. This logic was outdated and did not follow the "one count per record" rule. Solution: Refactor the custom activity-grouping logic to make the count conform to the general rule again. This aligns all systray counters, ensuring Tasks, To-Dos, and Mailings are now correctly counted only once, based on their most urgent activity. Task-5059640 Forward-Port-Of: odoo/odoo#226940
This change prevents an error that could appear when opening payments from a batch invoice view. The system now only applies invoice-specific details to invoice records, avoiding confusion and interruptions for users working with payments.
Original PR description
Repro: - Create DDM for a client - Create 4+ invoices for him - Pay with SEPA - Go to batch payment set it with SEPA - Add all the invoices and set the date to any date <5 days from today. - A yellow line will appear along with (View All).. / click it - From the view click on any payment. - Exception arises saying made_sequence_gap not found in account.payment Issue: made_sequence_gap belongs to 'account.move' incompatible with 'account.payment' causing the exception. Solution: Here the view_duplicated_moves_tree_js view is intended for account.move elements not for account.payment ones, So I included it only when the resModel is account.move. opw-5149260 Forward-Port-Of: odoo/odoo#233450
This fix closes a gap that could let live chat visitors initiate calls, even though the button was already hidden in some cases. It ensures the server also blocks these calls, keeping live chat behavior consistent and preventing unauthorized call starts.
Original PR description
In [1], we fixed an issue where the start call button would be visible to portal partners. We do not want visitors to initiate calls on live chats. However, there also is a guard in the `rtc` controller which only checks that public users cannot start calls. The server code should also be adapted to properly ensure no live chat visitor can start a call. [1]: https://github.com/odoo/odoo/pull/236272 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#236495
The calendar day view now keeps event titles visible instead of cutting them off on mobile devices. This makes it easier for users to quickly identify what each event is without opening it.
Original PR description
Before this commit, when the user goes to a calendar view in day to check what he have to do. He cannot see the event title properly in his mobile phone since the title is truncated. This commit makes sure the event title is not truncated to clearly see the whole event title. Before the fix: <img width="1172" height="802" alt="image" src="https://github.com/user-attachments/assets/f85a4a03-89a3-48c8-bda7-38e72854ce1f" /> After the fix: <img width="1179" height="808" alt="image" src="https://github.com/user-attachments/assets/7b0b31ba-10f5-412b-837b-8399c78c5bac" /> Forward-Port-Of: odoo/odoo#235823
This fix prevents an error in Documents when a CRM lead linked to an upload request has been deleted. The related document now handles the missing record safely, so users can open Documents without seeing a traceback.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
Documentation and clarification updates
This change adds a signed contributor license agreement record for Trung Tin Nguyen. It is an administrative update that confirms the contribution can be accepted under Odoo's contribution rules.
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
2 changes
Resolved issues and error corrections
This update makes the rating cards in Website Slides use the same background color as the rest of the page. It improves visual consistency so the interface looks cleaner and more aligned with the website theme.
Original PR description
PR #229272 sets the background color of the portal chatter to `body-bg`, aligning it correctly with the other parts of the chatter and website themes. However, `website_slides` module has a customized scss variable to change its main body background color which makes the background color for the rating cards (chatter top) being different in this module. This change sets the `--body-bg` in this customized scss to the same variable used for the background color, aligning the background colors with each other. Before: <img width="1182" height="552" alt="image" src="https://github.com/user-attachments/assets/6aba4609-e99c-48de-8af7-a97029859fab" /> After: <img width="1097" height="555" alt="image" src="https://github.com/user-attachments/assets/0d4ed53b-6d83-4eba-8499-0d38b10b4234" />
This change prevents errors when connecting to certain Swedish blackbox devices that only support an older protocol version. The system now checks the device version first and only sends commands it can understand, improving receipt registration reliability.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99008
4 changes
Enhancements to existing features
This update makes the Indonesian E-Faktur Coretax export compute VAT-related values using the correct tax groups, which helps avoid incorrect invoice data in the XML file. It also adds a new tax group, updates related tax definitions, and restricts when the Coretax XML can be downloaded to reduce the risk of generating an invalid export.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267)
Resolved issues and error corrections
Balance sheet lines now correctly respect the selected date range in cross-report comparisons. This ensures users see consistent figures when comparing periods and avoids misleading totals in financial reporting.
This fix ensures the editor’s color picker can see custom colors already used on the page, including for background colors. As a result, users get a consistent selection of page colors and can reuse existing branding colors more easily.
Original PR description
Before this commit, the colorpalette for the background color would not display custom colors already on the page. The issue appeared in 17.0 and worked in 16.0 before the conversion of wysiwyg to owl. github.com/https://github.com/odoo/odoo/pull/118966 The "getEditableCustomColors" method was not forwarded and therefore we used the default function, returning nothing. Steps to reproduce the issue: - Add a snippet - Set the background / font color of the snippet to a custom color - Add another snippet - Open the colorpicker for the text color (The colorpicker have access to the custom color set above) - Open the colorpicker for the background color (The colorpicker does not have access to the custom color set above) task-3806989
Documentation and clarification updates
This change updates the Adhoc Contributor License Agreement documentation to include additional members. It matters because it keeps the project’s legal records current for contributors and helps ensure future contributions are properly covered.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr