Daily updates from Odoo
Friday, January 2, 2026
13 changes · 18.0
Enhancements to existing features
This update adds a helpful link within the Accounting Settings to Odoo's documentation on Deferred Expenses and Revenue management. This provides users with immediate access to detailed information and guidance on using this important accounting feature, improving clarity and reducing support requests.
Original PR description
In the Accounting Settings, add a "?" icon that points at the Odoo documentation on Deferred Expenses and Revenue management. task-5418388
Resolved issues and error corrections
This update corrects a typo in the dashboard name and updates the labels for key scorecards to use average values instead of totals. These changes improve the clarity and accuracy of the restaurant's sales performance data displayed in the spreadsheet dashboard.
Original PR description
Desired behavior after PR is merged:
- Fix typo in first sheet name: 'Dahsboard' -> 'Dashboard'.
- Rename scorecards to reflect average values:
- 'Total revenue per guest' -> 'Avg revenue per guest'.
- 'Total revenue per order' -> 'Avg revenue per order'.
Task: [5447108](https://www.odoo.com/odoo/project/2328/tasks/5447108)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a persistent error message that appeared after purchasing a gift card within the Point of Sale (POS) system. Previously, a pop-up error remained visible even after the purchase was validated. This change removes the error message, providing a smoother and more reliable user experience for customers buying gift cards.
Original PR description
Description of the issue/feature this PR addresses: on point of sale, when we buy gift card then validet, keep pop up error at js code Current behavior before PR: on point of sale, when we buy gift card then validet, keep pop up error at js code Desired behavior after PR is merged: on point of sale, needed not pop up error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The fix corrects a restriction in user permissions, ensuring all accounting users, regardless of access level, can view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692
This update fixes a previous issue where documents uploaded through the system couldn't be downloaded. Now, users will see a popover with a download link for documents, streamlining the process. The attachment toolbar is also hidden for a cleaner user experience.
Original PR description
Before this commit: the document uploaded by /image cannot be downloaded on clicking. After this commit: we open a popover for document without the editing buttons. The user may download the document by clicking the link. Also the toolbar is hidden for attachments. task-3648796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241121 Forward-Port-Of: odoo/odoo#236705
This update fixes a minor issue where the UBL XML invoices were incorrectly including 'Invoice address' in the customer's name. The change ensures that the commercial partner's name is used, aligning with standard Odoo XML generation practices and improving invoice accuracy. This ensures consistent and correct data formatting for UBL invoices.
Original PR description
The dict-to-xml helpers were still using `partner.display_name` which includes the 'Invoice address' suffix. Changed to use `partner.commercial_partner_id.display_name` when partner name is not available, to match the fix in https://github.com/odoo/odoo/pull/232819 for the standard XML generation. task-4614564
This update reverses a recent change that was causing problems with the invoice PDF download feature. The previous behavior, which didn't allow downloading proforma invoices as PDFs, has been confirmed as the correct functionality. This reverts a bug fix that introduced a display issue.
Original PR description
This reverts commit a1251a8adc0c0f6639f653e414784f37326f82a1 The previous behavior as been confirm to be expected The change caused some issue where the PDF option wasn't displayed anymore opw-5111272
This update resolves a dependency issue within the Brazilian e-commerce module (l10n_br_edi_sale_fiscal_reform) that was preventing proper functionality. The change ensures the module correctly relies on its necessary dependencies, improving stability and accuracy of sales reporting in Brazil. This addresses a technical configuration error.
Original PR description
l10n_br_edi_sale_fiscal_reform depends on l10n_br_edi_sale, which depends on both l10n_br_edi and sale, but not explicitly on l10n_br_avatax_sale. runbot-exception-762 [runbot-error-237690](https://runbot.odoo.com/odoo/runbot.build.error/237690)
This update fixes a crash that occurred when switching tabs while a receipt was being generated in the Point of Sale system. The fix ensures the receipt printing process reliably completes, even with user interaction, by correctly managing the timing of component rendering. This improves the overall user experience and prevents lost receipts.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#239008
This update resolves an issue where column totals were consistently displayed in grid views, even when configured to hide them. The fix ensures that the 'hide_column_total' attribute is correctly applied, providing users with the option to remove column totals from their grid views for a cleaner display.
Original PR description
**Issue:**
Even though everything exists in the javascript component, the attribute "hide_column_total" of a gridview does not actually hide the column total.
Steps to reproduce:
create a grid view with the hide_column_total parameter. Something like:
```
<grid string="Salary Grid" hide_line_total="1" hide_column_total="1">
<field name="grid_country_id" type="row" section="1"/>
<field name="grid_field_category_id" type="row"/>
<field name="name" type="row"/>
<field name="grid_salary_level_field_id" type="col"/>
<field name="grid_salary_amount" type="measure"/>
</grid>
```
Cause of the issue:
The attribute "hide_column_total" is loaded through the javascript, but the resulting option ("hideColumnTotal") is neved used. Therefore, the column total always appearThis update fixes an issue where the left pane in the Point of Sale interface was sometimes shrinking too small, making text unreadable. The fix ensures the pane maintains its intended width, improving the user experience. The problem was intermittent and related to how the layout elements interacted.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359
This update corrects a missing detail in a recent invoice view update. The fix ensures that QR codes and payment information are now correctly included on invoices, aligning with local regulations. This improves data accuracy and compliance for Co-EDI reports.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922
This update fixes an issue where refund messages incorrectly displayed the customer as the author instead of the user who initiated the refund. The change ensures that the logged-in user is always identified as the author of refund, capture, and void transaction messages, improving data accuracy and reporting. This resolves a discrepancy in user attribution for payment transactions.
Original PR description
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module…
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module and enable the `demo` payment provider. - Create a new quotation and from the `gear` icon, select `Mark Quotation as Sent`. - From the `gear` icon, choose `Generate a Payment Link`, and copy the link. - Open the link in an incognito window, and complete the payment. - Return to the original tab and open the payment transaction from the chatter. - Click `Refund` > `Refund` and observe the `author` of the messages in the chatter. **Observation:** The refund messages entry shows the customer as the author instead of the logged-in user who executed the refund. **Root Cause:** At [1] and [2], when the logged-in user is not a superuser, the code assigns the customer (`self.partner_id`) as the author, even during `refund`, `capture`, and `void transactions`, resulting in an incorrect message author. **Fix:** This commit ensures that during refund, capture, and void transactions, the message author is set to the logged-in user instead of the customer. [1]: https://github.com/odoo/odoo/blob/bbf3bd7b0e1d3e015350f9c959fad056384e2318/addons/account_payment/models/payment_transaction.py#L223 [2]: https://github.com/odoo/odoo/blob/5cf325dfff1ffbc1c4b4d0bcfc44ac9f55ea7c51/addons/sale/models/payment_transaction.py#L110 **Before:** <img width="1910" height="624" alt="5379376_before" src="https://github.com/user-attachments/assets/decdd620-d741-488e-9dec-e5c8c9bafc48" /> **After:** <img width="1917" height="622" alt="5379376_after" src="https://github.com/user-attachments/assets/5f38f3c3-fd2c-489e-afc9-d7a356fde23a" /> opw-5379376 Forward-Port-Of: odoo/odoo#239224