Daily updates from Odoo
Tuesday, May 27, 2025
31 changes
4 changes
Resolved issues and error corrections
This update corrects a formatting problem in the VoIP contact information display. It helps prevent incorrect or confusing text from appearing when users view call contact details.
This change fixes an unreliable automated test in Web Studio navigation. It helps reduce false failures in the release process, making validation more dependable without changing the user experience.
Original PR description
runbot-error-224154
The VoIP softphone now shows a pause icon when an active call is placed on hold. This gives users clearer visual feedback in both the softphone top bar and systray, reducing confusion during calls.
Original PR description
This commit modifies the icons displayed in the softphone interface to provide clearer feedback on call status. Now, when the ongoing call is on hold, the user will see a pause icon in the top bar and the systray item.
This update corrects how Mexican e-commerce checkout handles tax ID validation after a related platform change. It helps prevent validation errors during website sales for customers entering VAT or tax details.
Original PR description
In PR https://github.com/odoo/enterprise/pull/75974, it was forgotten that the return value for _run_vat_checks had changed.
2 changes
Resolved issues and error corrections
The barcode manufacturing workflow no longer errors when users run quality checks during immediate production. This helps manufacturing teams complete quality controls reliably from the barcode app without interrupting production processing.
Original PR description
*: quality_control, quality_mrp Issue Before This Commit ======================== The barcode application for the 'Manufacturing' operation type triggered an error when attempting to perform a quality check during immediate productions. Steps to Produce: ================= - Create a new product (with or without a BoM, both scenarios are valid). - Set up a quality point for the product with operation set to 'Manufacture' and control per 'product'. - Open the barcode application and create a new Manufacturing Order (MO). - Scan the newly created product or use the "+ Add Product" option. - Click the "+1" button to indicate the product has been manufactured. - Click the "Quality Checks" button. With this commit, Quality Checks can now be successfully performed during immediate productions. Task: [4502322](https://www.odoo.com/odoo/my-tasks/4502322)
Kenya payroll calculations now include NSSF contributions when applying the pension contribution cap for taxes. This helps payroll tax calculations stay aligned with Kenyan legal requirements and reduces the risk of incorrect tax amounts.
Original PR description
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126
25 changes
Resolved issues and error corrections
Odoo now keeps bus messages for longer before cleanup, reducing the chance that users miss updates after a temporary disconnection. Administrators can also adjust the retention period to fit their operational needs, with a safer default of 24 hours.
Original PR description
Before this commit, the bus GC would remove every message older than 120 seconds. This could lead to missed messages if a disconnection occurred during the GC process. To minimize the impact of GC, the retention window should be extended. This commit introduces the `bus.gc_retention_seconds` config parameter, which allows customizing this window. The default is set to 24 hours, which seems reasonable (messages won't be cleared overnight). Since the GC will now process larger batches, the deletion is not made with a direct query: no need to fetch all records before calling `unlink`, no need to schedule other vacuums when the batch is too big.
Point of Sale now clears outdated quotation data after a down payment so it can reload the latest order details before settlement. This prevents incorrect settlement results, such as product quantities being reset, and helps ensure quotations paid through POS remain accurate.
Original PR description
## Issue: Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling. ## Reason: During the down payment…
## Issue: Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling. ## Reason: During the down payment process, the PoS adds new lines to the sale order. These are added during the order validation stage. However, the updated order lines are not written back to IndexedDB. If the user attempts to settle the order without reloading the session or clearing the cache, the PoS relies on stale data from IndexedDB. This causes Odoo to see outdated `order_lines`, usually only the original item(s), leading to incorrect behavior such as product quantities resetting to 0. ## Fix: To ensure data consistency, we explicitly remove the affected sale orders from IndexedDB after the down payment is completed. This forces the PoS to re-fetch the updated order from the backend. The re-fetch happens through the `missingRecursive` function, which will retrieve the complete and up-to-date sale order data, including the new order lines, ensuring accurate behavior during the settlement process. ## Steps to reproduce: 1. Create a service product with "Ordered quantities" as the invoicing policy. 2. Create a quotation using this product. 3. Open the PoS. 4. Click "Actions" → "Quotations" → select the quotation. 5. Choose the "Down Payment" option (any type) and set amount/percentage. 6. Pay the order. 7. Again, go to "Actions" → "Quotations" and select the same order. 8. Click "Settle the order". 9. At this point, Odoo will incorrectly reset product quantity to 0. OPW-4811612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order lines for products with non-variant or custom attributes now keep the product name as the main display name instead of showing the attribute name. This also ensures related tasks created from confirmed orders use the correct product-based name, reducing confusion for sales and project teams.
Original PR description
This reverts commit 2094747717be Versions -------- - 18.0+ Steps ----- 1. Create a service product that creates a task on order confirmation; 2. add an attribute that does not create variants; 3. add…
This reverts commit 2094747717be Versions -------- - 18.0+ Steps ----- 1. Create a service product that creates a task on order confirmation; 2. add an attribute that does not create variants; 3. add the product to an order; 4. confirm the order. Issue ----- 1. The task is named as the attribute. 2. The line's `display_name` shows the attribute instead of the product. Cause ----- Commit 2094747717be removed the extra new line that was added before attribute-based line descriptions for custom attributes and attributes that create no variants. This did not impact the task or display name in previous versions, as the default sale order description started with the product name, and could be replaced. But as of 18.0, while the default sale order description still starts with the product name, it's no longer possible to replace it, hence it gets skipped to get the first line of the editable description, which in this case is the attribute name. Solution -------- By re-adding the empty line before the attribute descriptions, the display & task names will fall back on the product name. See commit 47d223759f07 for display name & c3877b2acd74 for task names. Also adds a test to prevent regression. opw-4792351
Point of Sale session reports now correctly show counted amounts when bank payments include refunds or other negative transactions. This prevents mismatched payment totals and gives businesses more reliable end-of-session reporting.
Original PR description
Before this commit, if a session included negative bank payments resulting in a negative total, the session report displayed incorrect counted amounts and mismatched values for the bank payment method. opw-4714251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents pivot report exports from crashing when a numeric field is used in the row grouping. Business users can now download CSV or Excel exports from affected reports reliably, including reports such as Sales Analysis.
Original PR description
Steps to reproduce: - Go to any Report (Ex: Sale Analysis) - Switch to the pivot view - Add on y-column any **int** field - Download as csv Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file. opw-4762807 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
Invoice PDFs now handle unusually long tax group names without pushing the total amount off the page. This keeps invoice totals readable and avoids layout problems when printing or sharing invoices.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Tax closing accounts are now kept separate from tax line and default payable or receivable accounts, preventing incorrect tax closing amounts. The update also makes these tax authority accounts reconcilable, helping businesses match bank payments or refunds more easily.
Original PR description
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable, but non-trade. That way users can easily reconcile bank transactions with the tax authorities. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/enterprise/pull/85693
The accounting system now consistently runs the expected follow-up actions when an invoice becomes paid or enters payment processing. This helps prevent missed business workflows that depend on invoices being recognized as paid, such as updates, notifications, or related automations.
Original PR description
Before: - _invoice_paid_hook() was only triggered during reconciliation. After: - _invoice_paid_hook() is now reliably triggered in _compute_payment_state() when an invoice transitions to "paid" or "in_payment". task-4277444
Calendar popovers now display each task property with its own label instead of reusing the general container label. This makes custom property information clearer and consistent with how standard fields are shown.
Original PR description
Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes cases where purchase and sales replenishment flows could assign the wrong customer to internal warehouse transfers when different fulfillment routes were mixed. Businesses using cross-dock, make-to-order, and stock-based purchasing together will get more accurate picking documents and fewer delivery-processing mistakes.
Original PR description
When mixing cross-dock (XD), MTO and MTS products, it may lead to incorrect partners on the pickings. To reproduce the issue: 1. Enable Multi-Routes 2. Edit the warehouse: 2-steps reception, 2-steps…
When mixing cross-dock (XD), MTO and MTS products, it may lead to
incorrect partners on the pickings.
To reproduce the issue:
1. Enable Multi-Routes
2. Edit the warehouse: 2-steps reception, 2-steps delivery
3. Unarchive MTO route
4. Setup 3 products:
- Storable
- Routes:
- All with buy
- One MTO
- One XD
- Same supplier
5. Create and confirm one SO for each product (starting with XD one),
each one with a different customer
6. Validate the generated replenish
7. Confirm the PO
8. Process the receipts
Error: The internal pickings have the same defined partner, the
customer of the XD product.
There are two issues:
- The destination address of a purchase is defined on the PO level,
not the POL one
- When looking for a PO, the `_run_buy` mechanism doesn't filter on
the destination address
This explains why:
- All purchases are gathered on the same PO
- On the internal pickings, we will find the first destination address
Even though the first point is convenient, since the destination
address is defined on the PO level, it leads to incorrect results.
However, changing this on stable is too risky. The only (and sad)
thing we can do so far is the creation of an ICP that would split
all PO based on their destination address. On master, this address
will be defined on POL level.
OPW-4552316Fixes an issue in the homeworking calendar where changing the time format could trigger an error when moving between calendar views in debug mode. This makes calendar navigation more reliable for users who adjust time display settings.
Original PR description
**Issue**:
an error is thrown in debug mode when switching between calendar views ("year", "week", etc.) after changing the time format.
**Steps to reproduce:**
- ensure hr_homeworking_calendar is installed
- activate debug mode
- Calendar > change the time format
opw-4684831The Point of Sale mobile screen now keeps the search dropdown visible above the orders list. This fixes an issue that made searching orders difficult or unusable on smaller screens.
Original PR description
The search field dropdown was being rendered behind the orders list in mobile view, making it unusable. This commit adds a higher z-index to the search field dropdown to ensure it's rendered above the orders list. opw-4654710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening a combo product on the website no longer fails when one of its linked combo items was deleted. This avoids a customer-facing error page and keeps the online shop usable even when product data has changed.
Original PR description
If a user tries to open a combo product on the website and the combo item has been deleted, a traceback will appear. Steps to reproduce the error: - Install ``website_sale_stock`` module - Create…
If a user tries to open a combo product on the website and the combo item
has been deleted, a traceback will appear.
Steps to reproduce the error:
- Install ``website_sale_stock`` module
- Create ``Product A`` > product type: ``Goods`` > Save
- Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) >
Add ``Product A`` in combo item
- Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A``
- Delete ``Product A``
- Go to Website > Shop > Open ``Product Combo A``
Traceback:
```
File "/home/odoo/src/odoo/addons/website_sale_stock/models/product_combo.py", line 25, in _get_max_quantity
return max(max_quantities) if (None not in max_quantities) else None
ValueError: max() iterable argument is empty
```
https://github.com/odoo/odoo/blob/4d3b220b0ec6e718f962979b3f271ea161997322/addons/website_sale_stock/models/product_combo.py#L21-L24
Here, when the user deletes the product, ``self.combo_item_ids`` becomes empty,
resulting in ``max_quantities`` being an empty list ([]),
which causes the above traceback.
sentry-6589160704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers can now add a Pricer Sales Pricelist while creating a product variant before it has been saved. This prevents an error that interrupted product setup and improves the reliability of the product form workflow.
Original PR description
An error occurs when a user attempts to set the **Pricer Sales Pricelist** on a product variant that has not yet been saved. **Steps to reproduce:** - Install the `pos_pricer` module. - Open the form view of **Product Variants**. - Without saving the record, try to add a **Pricer Sales Pricelist**. - Observe the error. **Error:** `KeyError: False` **Cause:** When the product variant is unsaved, `product.id` is `False`, leading to a `KeyError` at [1], because `False` is not a valid key in the result of method `_compute_price_rule()`. [1] - https://github.com/odoo/odoo/blob/d352cfcfe0fe8c161392f3c39ea3e64b7c98bd69/addons/product/models/product_pricelist.py#L140 This commit ensures that users can add a 'Pricer Sales Pricelist' to a product variant, even before saving it. Sentry - 6598605111
Website editors can now delete all text from a button, save the page, and still edit that button later. This prevents buttons such as “Apply Now!” on job pages from becoming inaccessible after content cleanup.
Original PR description
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is…
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inherited `display: block` from a floated parent, which added a `<br>` in empty blocks. Solution: Preserve the ZWS for inline empty elements with `data-oe-field="arch"`, ensuring the element remains editable after save. Steps to reproduce: 1. Navigate to `/jobs/experienced-developer-4`. 2. Open the web editor. 3. Delete the text inside the "Apply Now!" button. 4. Save the page. 5. Reopen the web editor. → The button is no longer editable. opw-4737255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where pressing Tab inside a table header cell could cause an error. Users can now navigate tables with header cells more reliably without interrupting their editing work.
Original PR description
Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Document tags can now display the custom tooltip text set by users instead of always showing the tag name. This makes tag details clearer when hovering over tags in document views and avoids misleading or incomplete hover text.
Original PR description
Before this commit --- The tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. (The tooltip was not fetched.) After this commit --- We fetch and display the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 A sibling https://github.com/odoo/enterprise/pull/79496 updating xml and utilizing this change
This fix makes list column width handling more reliable, especially for right-to-left layouts and custom integrations that may not pass newer options. It helps prevent display issues or errors in list views while preserving compatibility for existing custom code.
Original PR description
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was…
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes no issue in standard odoo. However, as reported in [2], there is a world where `options` is undefined. I couldn't really find how, as it works fine even with the suggested culprit [3]. So this commit simply adds a fallback, which makes sense in stable in case there would be custom code calling those `listViewWidths` functions without options. In master though, we expect from people to adapt their code with respect to this change. [1] https://github.com/odoo/odoo/pull/210584 [2] https://github.com/odoo/odoo/issues/211243 [3] https://github.com/OCA/web/tree/18.0/web_remember_tree_column_width closes #211243 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
Changing the unit of measure while processing a receipt in the barcode app now updates the reserved quantity to match. This prevents mismatches between recorded received quantities and demand/reservation figures, improving stock accuracy.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- Create a receipt for 200 units of P1
- Mark it as To Do
- Go to the barcode module and start processing the receipt
- Edit the quantity:
- Set it to 2 and change the UoM to Dozen
- Save
Problem
The quantity done is correctly set to 2 dozens, But the reserved quantity remains 200
Solution:
When the UoM is changed, compute and update the reserved quantity accordingly
OPW-4716104Manufacturing barcode screens now show and group by-products by their destination location instead of the source location. This reduces confusion for production operators and allows by-product lines to be edited even when source-location scanning is mandatory.
Original PR description
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This…
Issue Before This Commit:
============================
In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.
Steps to Reproduce:
============================
- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
- The lines are grouped by Source Location.
- If you edit by-product line then user has option to edit source location.
- If the MO operation type has Source Location scan as mandatory,
user can't edit by-product line.
With This Commit:
============================
- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
users can still edit by-product lines.
This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.
task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)The Documents app now defaults Kanban views to show the most recently updated documents first. This fixes a sorting issue that could make new or unopened documents difficult to locate, helping users find recent files faster.
Original PR description
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096
The Italian Libro Giornale Journal Audit PDF report now handles long journal item descriptions without disrupting the layout. This ensures debit and credit amounts remain visible in printed reports, improving reliability for audit and accounting documentation.
Original PR description
Before this PR: When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.  After this PR: The Libro Giornale Journal Audit report now correctly handles journal items with long descriptions. The report template has been modified to ensure proper column width distribution, preventing the Name column from expanding excessively. The Debit and Credit columns are now consistently displayed in the PDF report regardless of description length.  OPW-4788257
Updates internal test data so tax group receivable and payable accounts follow the latest accounting validation rules. This helps ensure accounting, tax report, localization, and subscription tests continue to reflect compliant account setup without changing customer-facing functionality.
Original PR description
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249
This fix prevents an error in Mexican electronic invoicing for Point of Sale when a cashier selects a company contact on the payment screen. Orders are now only marked for invoicing once the required customer information is complete, reducing checkout interruptions.
Original PR description
Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831
Document tags now display the custom tooltip text configured for them when users hover over a tag, instead of always showing the tag name. This makes tag guidance clearer for users and ensures the existing Tooltip field works as intended across document-related views.
Original PR description
[FIX] documents: display tag tooltip on hover when possible Before this commit, the tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. After this commit, the system correctly fetches and displays the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 # (older) sibling PR: https://github.com/odoo/odoo/pull/210147