Monday, February 2, 2026
7 changes · 19.0
New functionality added to Odoo
This update enhances the Odoo POS system by allowing automated SMS and WhatsApp notifications to customers regarding order status updates – from initial placement to completion. This improves customer communication and provides real-time updates, leading to a better customer experience and potentially increased order accuracy.
Original PR description
… to warn the client about order status This task aims to provide a solution for communicating the status of various customer orders. Now, the POS can send an SMS or a WhatsApp message when an order at the self-service is placed, either through WhatsApp, SMS, or both. When the order is completed, the customer can also be notified. task : 5246552 community pr : https://github.com/odoo/odoo/pull/235389
Enhancements to existing features
This update enhances the user experience by adding a cursor pointer to the headers of statement summaries within the Enterprise module. This allows users to easily navigate and explore the detailed financial information presented in these reports, making it more intuitive and efficient.
Original PR description
This improves the user experience by indicating that the headers are clickable. No task ID Forward-Port-Of: odoo/enterprise#105023
Resolved issues and error corrections
This update resolves a problem where creating new contract templates in California within Odoo Enterprise 19.0 and later was blocked. The fix corrects a validation error that incorrectly checked the state filing status in the wrong module, ensuring proper contract template creation functionality. This improves the payroll process for US companies operating in California.
Original PR description
### Impacted versions: 19.0 and later ### Steps to reproduce: - Install l10n_us_payroll - Select California (CA) as the address for US company - Try to create new contract template ### Current behavior: state_filing_status should be validated in hr.employee instead of hr.version Task: [5458566](https://www.odoo.com/odoo/project/49/tasks/5458566)
This update resolves a bug preventing users from validating stock pickings after an invalid operation. The previous fix incorrectly blocked validation, now the system relies on the existing Mutex mechanism for sequential processing, ensuring accurate validation and preventing duplicate attempts.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on…
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on Validate > Invalid operation - Scan a Serial number #### > You can not click on validate anymore ### Cause of the issue: The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since orm call returns an error the the call the validate method is interupted at this orm call and the line https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133 ### Fix: We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 : https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135 we have the guarantee that the records will not be validated twice. opw-5388297 Forward-Port-Of: odoo/enterprise#104963 Forward-Port-Of: odoo/enterprise#103835
This update fixes an issue where users couldn't see all available Starshipit delivery services. The fix ensures Odoo sends complete order details to Starshipit, allowing users to select the correct service based on their shipment information. This improves the user experience and ensures accurate delivery options.
Original PR description
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this…
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup. Expected behaviour: Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume). Steps to reproduce: 1. Create new delivery method 2. Configure Starshipit API credentials. 3. Attempt to select a service. 4. Observe that not all service is shown from the available options. Cause of the issue: Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods. Fix: Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them. Forward-Port-Of: odoo/enterprise#103316
This update fixes an issue where credit notes didn't properly reverse commissions. The change ensures that a negative commission line is created for credit notes, accurately reflecting refunds and enabling correct commission calculations. This improves the accuracy of financial reporting related to credit note adjustments.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **partner_commission** modules. * Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab. * Create and…
**Steps to reproduce:** * Install the **Accounting** and **partner_commission** modules. * Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab. * Create and confirm a customer invoice with multiple lines (e.g. 750, 750). * Then go to **Dashboard → Transactions**, create a new transaction (e.g. 750) and reconcile it with the created invoice. * Create a **credit note** from the invoice and confirm it. * Open the contact and access **Purchase Orders** from the stat button. **Observed behavior:** * Only the commission line from the original invoice appears in the partner purchase order. * No **negative commission line** is created for the credit note. **Cause:** * Credit notes reused the original commission linkage instead of generating a dedicated commission entry. * This prevented commission reversal from being recorded for refunds. **Fix:** * Generate a **separate commission line** with a negative amount for each credit note. * Assign a dedicated `commission_po_line_id` to credit notes. * Copy only the `referrer_id` to credit notes, not the original commission line reference. opw-5357773
This update resolves an error that prevented users from correctly previewing subscription details. The issue stemmed from how recurring products were being handled within subscription sections, specifically when accessing pricing information. This fix ensures accurate display of subscription content during the preview process.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_subscription with demo data. 2. Create a new subscription and add a Section and a Subsection. 3. Add a recurring product (Invoice_policy =…
Steps to reproduce:
-------------------
1. Install sale_subscription with demo data.
2. Create a new subscription and add a Section and a Subsection.
3. Add a recurring product (Invoice_policy = 'order') and configure a recurring plan.
4. Confirm the subscription and click Preview.
Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
Error while rendering the template:
AttributeError: 'NoneType' object has no attribute 'collapse_prices'
Template: sale_subscription.subscription_portal_content
Reference: 1713
Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
(1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
(1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```
Cause:
------
`_get_invoiceable_lines` does not treat subsection lines as children of their parent section.
As a result, `lines_to_report` contains a subsection without its corresponding section,
leaving current_section set to None and causing the traceback when accessing current_section.collapse_prices.
Solution:
---------
Ensure subsection lines are appended together with their parent section
when an invoiceable line is encountered
Related community PR: https://github.com/odoo/odoo/pull/241634
opw-5367739