Tuesday, December 23, 2025
22 changes · 19.0
New functionality added to Odoo
This update adds the ability to generate Peruvian 5th and 6th Inventory and Balance reports within the general ledger. These reports require specific data from account and company settings, and are created using direct SQL queries for efficiency, as they don't need a user interface.
Original PR description
Adding 'Inventory and Balance' export option to the Peruvian general ledger report, and fields required for these reports to account_account and res_company. Report lines are handled with direct SQL queries since no UI display is required for this one, and some elements needed are outside of the scope of the usual reports model. task-4057152 Forward-Port-Of: odoo/enterprise#89744
Enhancements to existing features
Restaurant self-order QR code PDFs now show the table number alongside the Odoo logo. This makes it easier for staff to identify and distribute the correct QR code for each table, reducing setup confusion.
Original PR description
Before this commit: ====================== It was difficult to identify which table a QR code belonged to when viewing the generated QR code PDFs. After this commit: ====================== The table number is now displayed between the Odoo logo in each table’s QR code, making it easier to recognize and differentiate table QR codes. Task-5217734 Forward-Port-Of: odoo/odoo#233935
Resolved issues and error corrections
Malaysia electronic invoice down payment lines now use the required fixed classification code, while regular invoice lines continue using their product-based classification. This helps businesses submit compliant invoices and avoids errors caused by incorrect classification on down payments.
Original PR description
Ensure downpayment lines are assigned a fixed classification code ("022"), while other lines retain their product-based classification.
Task-5356913
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#240717
Forward-Port-Of: odoo/odoo#239831Internal users who are not part of a livechat will no longer see a misleading confirmation when closing the chat window. The prompt now appears only for actual participants, making the experience clearer and aligned with user permissions.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When an internal user who is not a member of a livechat channel opens a chat window for a…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When an internal user who is not a member of a livechat channel opens a chat window for a conversation in “looking for help” mode, closing the window incorrectly displays the Leave Conversation confirmation dialog. This is misleading because non-members cannot actually end the livechat session—the confirmation dialog suggests an action they do not have permission to perform. **Current behavior before PR:** ---------------------------------------------- - Non-member internal users see the close confirmation dialog - The dialog implies they can leave/end the livechat, which is not true - UI shows functionality that does not apply to them - Poor user experience and inconsistent behavior **Desired behavior after PR is merged:** ---------------------------------------------- - Confirmation dialog is shown only to actual livechat members(assigned agent or visitor) - Non-members close the chat window immediately without any prompt - UI accurately reflects real permissions - Clearer and more consistent livechat experience Task-5384846 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr
Fixed a display issue in the Website module where the Sales 3 navigation menu could spill outside its intended area when many menu items were added. This keeps website headers looking clean and ensures visitors can use the navigation reliably.
Original PR description
Scenario: - edit the website navbar and set template "Sales - 3" (penultimate) - edit menu to add several menu items that will be larger than possible Result: the menu overflows Cause: a parent element of the menu doesn't overflow, so when computing autoHideMenu where we compute what overflow the list of menu, nothing overflows it since the overflow already happened in the limitless parent element. Fix: using CSS to prevent the parent from overflowing. opw-5178552 __pr note:__ this is happening in 17.0 but I'm targeting 18.0 since the ticket is in 18.0 and code is the same in 18.0 up to master. Forward-Port-Of: odoo/odoo#240433
Guest users can still view pinned messages, but they will no longer see the unpin button they are not allowed to use. This avoids confusion from showing an action that would fail, while keeping full pin and unpin functionality available for internal users.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages, but…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages, but the server correctly rejects their unpin requests. This creates confusion and a poor user experience where external users see functionality that doesn't work for them. **Current behavior before PR:** ---------------------------------------------- - Guest users see the unpin button on pinned messages - Clicking the unpin button results in server rejection - UI shows functionality that guest users cannot actually use **Desired behavior after PR is merged:** ---------------------------------------------- - Guest users cannot see the unpin button on pinned messages - Internal users continue to have full pin/unpin functionality - UI accurately reflects user permissions and capabilities - Better user experience with appropriate access control Task-5033295 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240763 Forward-Port-Of: odoo/odoo#229211
This update reorganizes HTML editor tests so each scenario runs independently, reducing the risk of shared timeouts and unreliable results. It also removes confusing test helper code, making future maintenance easier without changing customer-facing behavior.
Original PR description
Description of the issue/feature this PR addresses: I. Grouping multiple testEditor in a single test is bad practice because the timeout of it is then shared between the different testEditor calls rather than each having their own separate timers. This PR splits the calls of each testEditor to its own test. II. This PR removes helper functions used to create different types of tags. Instead of simplifying the code, these helpers introduced unnecessary complexity and confusion. task-5375867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240937 Forward-Port-Of: odoo/odoo#240345
Live chat visitors no longer see an internal messaging status indicator when the chat bubble is collapsed. This keeps the visitor experience cleaner and avoids exposing information that is only relevant to internal users.
Original PR description
Before this commit, IM status was visible by livechat visitor in chat bubble, i.e. when folding chat window. This commit hides the showing of IM status for livechat visitors. Task-5435992 Before / After <img width="85" height="83" alt="Screenshot 2025-12-22 at 14 40 22" src="https://github.com/user-attachments/assets/8f5a0935-1d08-456e-baad-16651a2ecf00" /> <img width="78" height="71" alt="Screenshot 2025-12-22 at 14 40 35" src="https://github.com/user-attachments/assets/b9e40587-0864-40d3-b321-758368bd5122" />
This fix restores the font controls while editing website translations. Users can again change the size of selected translated text, making translation updates easier and preserving formatting flexibility.
Original PR description
The commit 6e1e359ec6a7ae23cfa7d7c96380f845c7fdcfe5, in addition to its main changes, removed a few plugins from translation mode. This was not needed, and it removed the font plugin, preventing the user from changing the size on a range of text. This commit undo that changes. Steps to reproduce: - Open website builder in translate mode - Select a range of editable text - Bug: you cannot change the size of the text task-5222402
When users reply to an internal note, the message composer now automatically regains focus even if it was already open. This removes an extra click and makes replying faster and smoother.
Original PR description
**Current behavior before PR:** When the composer is already open, clicking reply on a note does not refocus the composer. The user must manually click inside the composer before typing. **Desired behavior after PR is merged:** When clicking reply on a note, the composer is automatically focused, even if it was already open, allowing the user to continue typing immediately. task-[5410878](https://www.odoo.com/odoo/project/1519/tasks/5410878) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Some Belgian and Dutch chart of accounts labels were corrected so they match the intended English account names. This helps users see accurate account descriptions in localized accounting setups and reduces confusion when reviewing financial records.
Original PR description
Following odoo#227754, a couple of translations for changed accounts need to be updated to correctly reflect their english name. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Project app issue where subtasks could remain visible in Kanban after being archived and restored, even when users had chosen to hide subtasks. Subtask visibility now consistently follows the Show/Hide Subtasks setting, reducing confusion in task boards.
Original PR description
Steps to reproduce: - Install the Project app. - Create a task and a subtask under it. - Archive the subtask, then unarchive it. - Untoggle the Show Sub-Tasks Issue: Subtask remains visible in Kanban even when Show Sub-Tasks is untoggled. Cause: When a subtask is archived, the PR https://github.com/odoo/odoo/pull/148342 forces `display_in_project' to True Fix: Remove the logic that sets display_in_project to True on archived subtasks, since their visibility is now managed by the Show/Hide Subtasks toggle. task-5075134 Forward-Port-Of: odoo/odoo#230263
Mobile invoice entry now shows only taxes that match the invoice type, instead of mixing sales and purchase taxes. This helps users pick the right tax more easily and reduces accounting entry mistakes when working from a phone or small screen.
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Create an new invoice - Add an invoice line - Click on the Taxes field => Both purchase and sales taxes are available Solution ======== Copy the domain from the desktop list view https://github.com/odoo/odoo/blob/fcc677e900c2fccb9fa0bd88ef01c559cadfa08a/addons/account/views/account_move_views.xml#L1051-L1055 We also add the corresponding context and options opw-5124536 Forward-Port-Of: odoo/odoo#240116 Forward-Port-Of: odoo/odoo#237724
This update resolves a problem with the Chile invoice PDF report, where text was incorrectly formatted and overflowing. The fix ensures the invoice layout is correct, preventing vertical text and page overflows, resulting in a professional and readable invoice for Chilean customers.
Original PR description
Steps to reproduce: 1. Install l10n_cl_edi. 2. Create an invoice with a customer having a Chile address. 3. Print "Invoice PDF copy (Chile)". Issue: The PDF layout is broken: some text is rendered vertically and the content overflows across multiple pages. Cause: The footer right column row did not have an explicit width, causing wkhtmltopdf to shrink the container and wrap text letter by letter. Fix: Set w-100 on the inner row to stabilize the layout and prevent vertical text rendering. Before Fix : <img width="408" height="313" alt="image" src="https://github.com/user-attachments/assets/1d61412d-cfd3-48df-a4d4-eabd10df4865" /> After Fix: <img width="409" height="320" alt="image" src="https://github.com/user-attachments/assets/3a098227-7e43-44f0-9266-b4b0023f382c" /> opw-5348151 Forward-Port-Of: odoo/enterprise#102111
This update fixes an issue where employee and manager feedback was reset to default templates when an appraisal was reopened. The fix ensures that previously entered feedback is preserved, streamlining the appraisal process and improving user experience. The change was triggered by a bug in how the system handled appraisal state transitions.
Original PR description
Steps to reproduce: 1- Create new appraisal 2- Confirm appraisal 3- Edit employee and manager feedbacks 4- Set the final rating for the appraisal 5- Mark appraisal as done 6- Reopen appraisal Issue: The feedbacks of both the employee and manager are reset to the default template. They should be unchanged. Cause: Both the reopen and reset buttons used to call the the same action "action_back" which would set the state of the appraisal to "1_new", there is a compute that is triggered by the change in state which updates the appraisal's department_id which in turn triggers two other computes for the employee and manager feedbacks, those computes have a condition that if the state of the appraisal is '1_new', then the feedbacks should be reset to the templates. Fix: Make each button call its own action and make the reopen action set the state to '2_pending' instead of '1_new'. Furthermore make the reset action also reset the final rating for the appraisal. Task-5411661
This update fixes a usability issue where the barcode display for manufacturing orders was difficult to read in dark mode due to poor color contrast. The changes adjust text and background colors to ensure clear visibility, improving the user experience when working in dark mode.
Original PR description
*: stock_barcode Before this commit: ======================= When accessing a manufacturing order via Barcode in `dark mode`, the producing bar of the finished product is difficult to read due to…
*: stock_barcode Before this commit: ======================= When accessing a manufacturing order via Barcode in `dark mode`, the producing bar of the finished product is difficult to read due to poor colour contrast. Steps to reproduce: ======================= 1. Install the `mrp` module. 2. Switch to dark mode. 3. Open any manufacturing order using Barcode. 4. Observe the producing bar for the finished product. - The text on the producing bar is hard to read because the colour of text does not provide sufficient contrast. - Additionally, for products tracked by `lot or serial number`, when the same product is added multiple times, the barcode view groups these entries into a single grouped line, causing the same visibility issue in both MO and normal `picking/transfer` operations. Cause of the Issue: ======================= In dark mode, both the text and background colour of the producing bar are light, resulting in low colour contrast and making the text difficult to read. Additionally, the `text-muted` class applied to the `units of measure (UoM)` further reduces readability. After this commit: ======================= Updated the text colour of producing bar and background colour of grouped lines to use a darker shade for better visibility in dark mode. Also, removed the `text-muted` class used on `UOM` to improve redability. TaskID-5117608
This update fixes an issue where product attributes weren't shown on order lines. The change ensures that all product attribute names are now correctly displayed, improving order clarity and accuracy for users. This was caused by a change in how attribute data was constructed within the system.
Original PR description
Before this commit: --- - When an order was placed with product attributes, the attribute details were not shown on the order line. After this commit: --- - The product attribute names are now correctly displayed on the order line. Cause: --- - Until saas-18.2, the attribute string was built using the product’s display name and `attribute_line_ids`, which only included never type PTAV entries. - Starting from saas-18.2, the attribute string is constructed solely from `attribute_line_ids`, which now includes all PTAVs. task-5244869 Forward-Port-Of: odoo/enterprise#99007
This update resolves an error that prevented users from successfully sending customer statements. The fix ensures the system correctly handles scenarios where a custom email template isn't used, defaulting to the current user's email address to avoid a technical error.
Original PR description
Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the…
Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the `account_reports` module. - Go to `Invoicing` > `Customers` > `Customers`. - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`. - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`. **Error:** `ValueError: Expected singleton: mail.template()` After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from. This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior. [this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7 [1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246 [2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693 [3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892 sentry-7106576491 Forward-Port-Of: odoo/enterprise#102532 Forward-Port-Of: odoo/enterprise#102219
This update resolves a failing test within the MRP work order module, identified by a Runbot error. The issue stemmed from an incorrect count of analytic lines created during a setup process, specifically related to employee time tracking. This fix ensures the test now passes and maintains the stability of the MRP work order functionality.
Original PR description
fixing runbot error https://runbot.odoo.com/odoo/runbot.build.error/234639 on test test_mrp_analytic_account_employee_from_widget introduced by this PR https://github.com/odoo/enterprise/pull/85517
**cause of the error:**
Because there is a resource.calendar.leave without calendar_id,
without resource_id and at a date after today :
during the setupclass, when the employee is created,
_create_future_public_holidays_timesheets() creates an account.analytic.line.
So at the end of the test ,
self.env["account.analytic.line"].search([('employee_id', '=', self.employee1.id)])
returns 2 records instead of 1.
runbot-234639
Forward-Port-Of: odoo/enterprise#102338
Forward-Port-Of: odoo/enterprise#102282This update aligns the positions of the 'view-contact' and 'livechat-info' buttons within the WhatsApp channel interface. Previously, they were in opposite locations, which was causing confusion for agents. This change ensures a more intuitive and consistent experience for live chat and WhatsApp support agents.
Original PR description
The thread action 'view-contact' is somewhat like 'livechat-info', in that this action redirects to relevant info to the whatsapp user and livechat-info is a panel with all info on the visitor and…
The thread action 'view-contact' is somewhat like 'livechat-info', in that this action redirects to relevant info to the whatsapp user and livechat-info is a panel with all info on the visitor and more. The position of both buttons were the total opposite in discuss app: - 'livechat-info' was put as the 1st panel one before panels - 'view-contact' was dead last. There are differences, with 'livechat-info' being a panel and 'view-contact' a redirect button. However, each are important buttons for the type of conversation that justify them being in their own group right now. Since the buttons are mutually exclusive by the channel type, there's reason to have them share the same position. This commit moves the position of 'view-contact' in discuss header thread actions to be the same as 'livechat-info', that is as the 1st action in the list. This makes its position consistent with livechat info, thus agents of live chat and whatsapp would appreciate the 2 button placement being consistent. Task-5431313 <img width="1760" height="231" alt="Screenshot 2025-12-18 at 21 02 24" src="https://github.com/user-attachments/assets/ee2baf91-0d9a-49ca-91ac-a7781b33e57b" />
This update fixes a misleading error message displayed when deleting sale orders with associated appointments. Previously, users received an incorrect instruction to reduce order quantities. Now, the system correctly informs users that they must cancel the order before deletion, aligning with expected business processes and improving user experience.
Original PR description
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.…
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed. Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion. Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed: "You can not delete a sent quotation or a confirmed sales order. You must first cancel it." Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed: "Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead." Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Delete the sale order with the booking 5. Observe the incorrect error message being displayed opw-5092349 Forward-Port-Of: odoo/enterprise#100371
This update corrects a recent change that incorrectly included legal reserves in the Belgian Balance Sheet reports. This change was unnecessary as legal reserve requirements have been removed since 2024. This reversion ensures accurate reporting for our Belgian clients.
Original PR description
In #95062, the BE Balance Sheet was changed to include Legal Reserves. However, since this is not needed since 2024, this change can be reverted. no-task