Thursday, December 18, 2025
12 changes · saas-18.2
Resolved issues and error corrections
Down payment invoice lines in Malaysia e-invoicing now use the required fixed classification code, while regular product lines continue using their product-based codes. This helps ensure Malaysian electronic invoices are generated with the correct tax classification and reduces compliance errors.
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#239831This fix removes temporary editor overlays when the website editor is closed or destroyed. It prevents hidden leftover elements from building up after repeated edit-and-save cycles, helping keep the editing experience stable.
Original PR description
This commit ensures that local overlays are correctly removed when the Editor and `LocalOverlayPlugin` are destroyed. Steps to reproduce (observable after 18.4): - Go on website - Enter edit mode - Save - Repeat entering edit mode and saving - Inspect the DOM: oe-local-overlay elements keep accumulating, only one is non-empty The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. task-5380409 Forward-Port-Of: odoo/odoo#239644
This fixes an issue where a user's chat presence could remain outdated after they returned from being inactive. Business users benefit from more accurate availability information in discussions and messaging, reducing confusion about whether someone is online or away.
Original PR description
Before this commit, the user's presence might not be updated after returning from inactivity. This occurs because the status service only sends an update if the user was away during the previous update. However, this condition doesn't account for cases where the update was never sent. Forward-Port-Of: odoo/odoo#239321 Forward-Port-Of: odoo/odoo#239202
The activity menu now separates filter preparation from the step that opens the related action. This makes it easier for other Odoo apps to customize activity behavior without duplicating existing logic, reducing maintenance risk while preserving the current user experience.
Original PR description
The `openActivityGroup` method in `ActivityMenu` currently handles both the preparation of filters (domains, contexts) and the actual execution of the action. This coupling prevents other modules from intercepting the action execution to inject specific behaviors—such as loading a specific server-side action or specialized views—without completely overriding the method and duplicating the filter logic. This commit extracts the final execution step into a new method `executeActivityAction`. This allows extending modules (e.g., `documents`) to customize the action load (e.g., to ensure specific JavaScript hooks are initialized) while relying on the base implementation for domain and context generation. Task-5187045 Forward-Port-Of: odoo/odoo#238377
Forum post editing no longer offers image size choices that cannot be saved correctly. This prevents users from selecting 25% or 50% image sizes that would be lost after publishing, reducing confusion when creating forum content.
Original PR description
Problem: When creating a new forum post with an image set to "50%" or "25%" size, the post is saved with the original image size instead of the selected one. Cause: The `Post.content` field has `strip_style=True`, which removes any inline `style` attributes before saving. Since image size ratios were applied using `style="width: 50%"`, the width information was lost. Solution: Disable image size options that depend on inline `style` attributes, as they cannot be preserved when saving forum posts. Steps to reproduce: 1. Go to Forum. 2. Create a new post. 3. Add an image and set its size to 50% or 25%. 4. Save the post — the image appears with its original size. opw-5173917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234354
Employee logins in restaurant Point of Sale now respect the configured default screen, such as opening the register/products page instead of always showing the floor plan. This prevents staff from landing on the wrong screen and helps keep opening workflows consistent with business settings.
Original PR description
Steps to reproduce ------------------ 1. For a restaurant, set the default page as "register", i.e. the products page 2. Enable 3. Now login with an employee, and notice that the page after the login page is the floor page, not the products page as set in the configuration of (step 1). Why the issue ------------- After successfully logging in, we were redirecting the user either to the products page, always if it's not a restaurant, or to the floor page, always if it's a restaurant. That means we were not taking into consideration, for the restauarnt case, whether the default page is the floor page or the products page. The fix ------- Now we redirect users after logging using the `defaultPage` getter, which takes into consideration the `default_page` cofiguration for a restaurant PoS. opw-5359514
The TDS entry wizard now warns users whenever a vendor's PAN is missing, regardless of the withholding tax rate. This helps teams consistently collect required PAN details from vendors and avoids relying on rate-based conditions that could hide the reminder.
Original PR description
Simplified the condition to show warning whenever the partner’s PAN is missing in the TDS entry wizard, instead of checking for lower TDS rate. The warning’s purpose is only to alert users to collect PAN from vendors, so rate based check was removed. task-5245353 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235436
Fixed an issue where adding a calendar to a personal dashboard showed only the header and not the calendar itself. Users can now view embedded calendars properly from My Dashboard, making dashboard shortcuts more useful and complete.
Original PR description
--- ## Short functional explanation of the error When adding a calendar to a personal dashboard, only the header shows. The calendar itself doesn't show. ## Reproduction Steps 1. Go to calendar and click on the cog next to it. 2. Click on Dashboard > add. 3. Go to the Dashboard app > My Dashboard. ### Expected behavior The calendar should show under the header. ### Unexpected behavior Only the header shows. ## Origin of the issue The calendar wrapper in the CSS style wasn't specified. --- opw-5242329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235459
This update resolves an issue where archived employees were still appearing in the timesheet section of helpdesk tickets. The fix ensures that timesheets only display entries for currently active employees, improving data accuracy and usability. This prevents confusion and ensures timesheet reporting reflects the current team roster.
Original PR description
**Steps to Reproduce:** - Install hekpdesk_timesheet. - Go to settings, enable timesheets - Archive an employee. - In a ticket, try to add a timesheet entry. **Isuue:** Archived employees are also appearing under timesheets tab. **Fix:** Passed a context so that only active employees appear in the selection. task-5078763 Forward-Port-Of: odoo/enterprise#95137
This update fixes an issue where product documents would stop appearing on product pages after a document version was updated. The fix ensures that the product document record is correctly linked to the latest document version, maintaining accurate product information. This improves data consistency and prevents disruptions to product listings.
Original PR description
**Steps to reproduce:** 1. Install `sale_management` and `documents`. 2. Go to settings > check `product` under Files Centralization. 3. Create a product and add a document to it using the smart button. 4. Update the version of that document from the *Manage Versions* action on the document page. **Issue:** - After updating the document version, the linked document no longer appears on the product page. **Cause:** - The product page displays records from the `product.document` model, but its `ir_attachment_id` was not updated when the document’s version changed. **Solution:** - Update the `ir_attachment_id` on the corresponding `product.document` record when the document version is updated. opw-5144041 Forward-Port-Of: odoo/enterprise#99226
This update resolves an issue where ECO applications were failing due to incorrect references to attached documents. Specifically, the system was pointing to the wrong attachment record, leading to database errors. This fix ensures ECO applications run smoothly by correctly linking documents.
Original PR description
When applying an ECO, the system incorrectly sets the origin_attachment_id of a product.document to a product.document record itself instead of its related ir.attachment. As a result, if the incorrectly referenced ir.attachment is missing, the ECO will attempt to reference a record that does not exist, leading to a foreign key violation during action_apply. Steps to reproduce: 1.) Create an mrp.eco record 2.) Upload a document, take note of the product.document ID 3.) Unlink the ir.attachment with ID = (document ID + 1) (+1 is to account for the .copy within action_apply) 4.) Run eco.action_apply 5.) Observe SQL Constraint Expected result: The ECO should correctly link the product.document to its related ir.attachment. Actual result: origin_attachment_id may point to an unrelated ir.attachment, causing constraint violations when those attachments do not exist. opw-5050263 Forward-Port-Of: odoo/enterprise#94958
This update fixes an issue where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix prevents multiple validation attempts, ensuring accurate stock tracking and avoiding potential errors. This improves data integrity and reduces the risk of discrepancies.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#100356
Forward-Port-Of: odoo/enterprise#95329