Monday, November 17, 2025
12 changes · 17.0
Resolved issues and error corrections
Users can now export records even when the list is grouped by a property field. This fixes a crash that happened during export and restores a normal workflow for grouped task lists.
Original PR description
Step to reproduce
- open a task
- add a property field , say test
- add values for this field in few records
- go to list view and group by test
- select a record from result and export it (from Action btn)
Observation:
- traceback
```
File "/home/odoo/17.0/addons/web/controllers/export.py", line 486, in base
groupby_type = [Model._fields[x.split(':')[0]].type for x in groupby]
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: 'task_properties.b60ee9baefee14a8'
```
Cause:
- The issue is caused by splitting, which didn't considered property field
- it tried to look for `task_properties.b60ee9baefee14a8` in _fields which causes KeyError
FIx:
- split the field name properly to bring out actual field name while considering granularity as well as the property fields
opw-5159155
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe employee org chart button now opens the Hierarchy view on mobile instead of defaulting to the Kanban view. This makes it easier for users to see reporting lines and navigate employee relationships on smaller screens.
Original PR description
Steps to Reproduce: - Open an employee record. - Set managers for the employee. - Open the employee’s form view on mobile. - Click org chart stat button. Before: - On mobile, the org chart button opened the Kanban view by default. After: - On mobile, the org chart button now opens the Hierarchy view by default. task-5245129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes each Flutterwave payment reference unique by adding a timestamp suffix before sending it to the payment provider. It helps avoid payment creation errors in test and reset environments where the same reference could otherwise be reused.
Original PR description
The `/payments` endpoint of the Flutterwave v3.0.0 API expects unique `tx_ref` parameters (matching Odoo's payment transaction `reference` field) to be passed. This is guaranteed by a UNIQUE() SQL constraint in Odoo, but testing sometimes involves dropping the database, leading to transaction references being repeated at the provider level for a given merchant account. This commit singularizes all transaction references by suffixing them with the current timestamp, ensuring that the `tx_ref` API parameter remains unique across transaction reference sequences.
When a sales order creates a purchase order, Odoo now makes sure the chosen supplier is actually valid. This prevents purchase orders from being created with an expired or unsuitable vendor when the customer is not one of the product’s suppliers.
Original PR description
**Issue** A PO triggered by a SO could have an invalid vendor selected. **Steps to reproduce** - Install Sale and Purchase apps - Create a product with: - Two routes: MTO and Buy (Inventory tab) -…
**Issue**
A PO triggered by a SO could have an invalid vendor selected.
**Steps to reproduce**
- Install Sale and Purchase apps
- Create a product with:
- Two routes: MTO and Buy (Inventory tab)
- Two sellers in this order (Purchase tab):
1. With an expired `end_date`
2. With a valid `end_date`
- Create a SO for that product with a client that is **not** one of the vendors
→ A PO is created with the first vendor instead of the second (valid) one.
**Cause**
In the method `_run_buy`, to retrieve the vendor for the PO, `_select_seller` is called with the associated partner of the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L62C1-L66C52
That method calls `_get_filtered_sellers` with that associated partner:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L699
Which returns an empty recordset because every seller record is filtered out since every one of them has an associated partner different than the one set on the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L673C1-L674C25
Then, in `_run_buy`, the fallback is to call `_prepare_sellers` with no param, and to select the first one found:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L70C1-L72C18
And since, `_prepare_sellers` sorts the records according the sequence (among other thing but not the end_date):
https://github.com/odoo/odoo/blob/1478cbcfbf8d1e0184fce6236c5201ba4b59a159/addons/product/models/product_product.py#L653
it will select the first one (here, the one with an expired end_date)
**Solution**
One option would be to not indicate the vendor when calling `_select_seller` in `_run_buy`, but this would prevent specifying a vendor explicitly.
Instead, add a better fallback where we call `_select_seller` again without specifying the vendor, ensuring a valid seller is selected even when the SO partner doesn’t match any vendor.
opw-5145683This fix ensures the “View Quotation” button in purchase emails opens the website tied to the correct company, instead of always using the default site. It helps users and suppliers land on the expected page when multiple company websites are in use.
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
This update prevents an error when viewing a quotation preview after customizing the sales report with Studio. It makes the preview use the same data naming as the edited report, so the document renders correctly instead of failing.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5251932
This fix stops the website from showing technical error pages when an unusual product setup creates a rental order without valid dates. Instead of exposing a traceback to customers, the system now handles the problem more gracefully during checkout.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045
This fix ensures leave accrual balances are calculated correctly when an accrual allocation’s start date is changed. As a result, employees now receive the right number of accrued days according to the configured plan, avoiding undercounted balances.
Original PR description
Version: * 17.0 Steps to Reproduce: 1. Create an accrual plan with: * Accrued gain time: At the start of the accrual period * Carry-over time: Other * Carry-over date: 1 January * Add a milestone where the employee accrues 2 days monthly, with a milestone reached = 0 days. 2. Create a new allocation: * Set allocation Type to accrual allocation * Select the accrual plan created above * Set date_from to the 1st of the previous month Issue: * The expected accrued days are 4, but the system only calculates 2. Fix: * When changing the `date_from` value, set `already_accrued` to False. * This ensures `_process_accrual_plans` runs `_add_days_to_allocation` properly and recalculates the correct accrued days. After: * Accrued days now calculate correctly based on the accrual plan. task-5236714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a printing setting in the Windows IoT printer driver that was causing PDF labels to shift on Zebra printers. It helps ensure labels print in the right position again, reducing wasted labels and manual adjustments.
Original PR description
Adding the argument "-dPDFFitPage" in the printer driver for the windows IoT broke the alignment when printing PDF labels on Zebra printers. Issue introduced in #232866 opw-5220275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem in the Barcode app where creating a manufacturing order could leave out the required component lines. It ensures the order is processed correctly when product tracking is not enabled, so users can confirm production without missing materials.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163
Odoo now matches Mollie’s actual payment setup by no longer enabling iDEAL by default and by removing Sofort from the linked methods. This reduces confusion during payment provider activation and avoids showing options that are not immediately available or are being deprecated.
Original PR description
**[FIX] payment_mollie: remove iDEAL from the default payment methods** When a new Mollie account is created, it only accepts card payments out of the box. In Odoo, both the Cards and iDEAL payment methods were activated by default upon enabling the payment provider, while iDEAL required manual activation from Mollie's dashboard. --- **[FIX] payment_mollie: remove Sofort from the linked payment methods** See https://help.mollie.com/hc/en-us/articles/20904206772626-SOFORT-Deprecation-30-September-2024ard.
When a delivery tied to a subscription is returned, the system now correctly updates the delivered quantity on the related sales line. This ensures subscription billing and reporting stay accurate after returns, avoiding overcounting delivered goods.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406