Friday, December 19, 2025
17 changes · saas-18.4
Enhancements to existing features
This update ensures IoT boxes automatically align with the latest database version, improving data consistency and reliability. The system checks the database nightly and triggers a restart of the IoT boxes to apply the necessary code changes. This prevents discrepancies between the database and the IoT box’s code.
Original PR description
This PR adds the code which checks every midnight to see if the version of the database has changed. If so, it will update the iot box's code to align it to the database version Note: 1) the existing iot boxes will need to restart to get this cron job 2) Outside of database upgrade the code won't be upgraded with the cron Forward-Port-Of: odoo/odoo#240308 Forward-Port-Of: odoo/odoo#239049
Resolved issues and error corrections
This update fixes an issue where contacts without names or email addresses in Odoo's chatter interface were displaying as 'Unnamed'. Now, when a contact lacks this information, the system will automatically show their display name instead, providing a more user-friendly experience. This ensures all recipients are clearly identified within conversations.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#229832 Forward-Port-Of: odoo/odoo#213545
Documentation and clarification updates
This pull request updates the Adhoc Corporate Legal Agreements (CLA) by adding new members. This ensures Odoo continues to comply with legal requirements and maintain appropriate agreements with its contributors. The change is purely a legal update and does not impact the Odoo software itself.
Original PR description
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 Forward-Port-Of: odoo/odoo#240304
This update simplifies the TDS (Tax Deducted at Source) warning system. Now, the system alerts users to collect a vendor's PAN (Permanent Account Number) whenever it's missing, rather than based on the TDS rate. This ensures users are consistently prompted to gather the necessary information for compliance.
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#240471 Forward-Port-Of: odoo/odoo#235436
This update fixes an issue where Chilean invoices generated as PDFs incorrectly displayed unit prices with decimal points. The change ensures that unit prices align with Chilean localization rules by removing decimal formatting, resulting in a more accurate and professional invoice presentation.
Original PR description
**Steps to reproduce:** * Install the *l10n_cl* module with demo data. * Switch the environment to the **CL** company. * Create a customer invoice containing at least one invoice line. Enter a…
**Steps to reproduce:** * Install the *l10n_cl* module with demo data. * Switch the environment to the **CL** company. * Create a customer invoice containing at least one invoice line. Enter a **price_unit with decimals** (e.g., *99.56*). * Confirm the invoice. * Download and open the generated PDF from the invoice form. **Observed behavior:** * The **unit price** rendered in the PDF is displayed as a rounded decimal value (e.g., *100.00*), even though *Chilean* localization does **not** use decimal representation for unit prices. **Cause:** * The QWeb template uses `t-options` to format float values with **two-decimal precision**, forcing decimals to appear in the PDF. **Fix:** * Reduce the formatting precision in the PDF template so that **no decimal points** are displayed, matching Chilean localization rules. **Before Fix** <img width="783" height="319" alt="image" src="https://github.com/user-attachments/assets/e5ea5a38-a77a-4d64-9aae-672940734ea4" /> **After Fix** <img width="794" height="316" alt="image" src="https://github.com/user-attachments/assets/c47d2f0a-b4ea-428e-bf57-23584c34bf5c" /> --- opw-5234563 Forward-Port-Of: odoo/odoo#238059
This update ensures that user presence status is consistently updated after periods of inactivity. Previously, updates were missed if the user hadn't been away during the last status check. This improvement guarantees accurate user presence information for all users.
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#239458 Forward-Port-Of: odoo/odoo#239202
This update resolves a technical problem that could cause errors when processing invoices with multiple CAF (Contribution Authority File) documents. The fix ensures the system correctly identifies and uses the lowest starting number for CAFs, preventing database errors and ensuring accurate invoice processing. This improves stability and reliability for users.
Original PR description
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting…
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number. This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB. Steps to reproduce: - Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5) - Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example). - Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset. In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled. opw-5414350 Forward-Port-Of: odoo/enterprise#102385
This update fixes an issue where the out-of-stock message on product pages was appearing as a single, overflowing line. The change ensures line breaks are preserved, allowing the message to wrap correctly and display properly within the product badge, improving the user experience. This resolves a visual inconsistency and enhances the clarity of product availability information.
Original PR description
- Before saas-18.4, the [out-of-stock](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L8) message was rendered as…
- Before saas-18.4, the [out-of-stock](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L8) message was rendered as plain text without any layout-specific classes, allowing the message to wrap naturally. **Reference of version saas-18.3** <img width="1920" height="768" alt="2025-12-16_18-53" src="https://github.com/user-attachments/assets/d7670fa4-6808-40d7-9bad-768d0637f366" /> - From saas-18.4, the [out-of-stock](https://github.com/odoo/odoo/blob/saas-18.4/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L13-L16) message is rendered using `t-out`, which outputs plain text and collapses line breaks, causing the message to appear on a single line and overflow when used with `d-inline-flex`. See screenshots in the PR description (Before fix). <img width="1920" height="672" alt="2025-12-16_14-28" src="https://github.com/user-attachments/assets/927080cd-f2b0-45cd-ae0a-2917699c05f6" /> - Updated the layout to replace `d-inline-flex` with `d-flex` and apply `text-break` on the message container so long and dynamic texts wrap correctly inside the badge. See screenshots in the PR description (After fix). <img width="1918" height="682" alt="2025-12-16_14-31" src="https://github.com/user-attachments/assets/2cafdc61-e494-468a-9d41-08ab3c83b041" /> opw-5274850 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
This update resolves an issue where German Sale Order reports were missing the 'Position' column and had broken formatting. The fix corrects a calculation error in the report template, ensuring that each sale order line is numbered correctly and the report displays properly.
Original PR description
Before this commit, when printing a Sale Order using the German localization, the "Position" column in the PDF report was empty. Additionally, the table formatting was broken due to this missing data. This issue occurred because the index variable used to calculate the line number in the report template (QWeb) was incorrect. This commit fixes the index logic in the report template. Now, the "Position" column correctly displays sequential numbers (1, 2, etc.), and the table formatting renders correctly. ticket-5225647 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
This update fixes a potential parsing error in the HTML editor by ensuring it correctly identifies block-level elements, even when they are hidden using `display: none`. Previously, hidden elements could cause parsing failures. This change improves the overall stability and reliability of the HTML editor when dealing with complex QWeb templates.
Original PR description
Problem: When nodes have `display: none` (for example a QWeb `t-else` node with a false condition), `isBlock` incorrectly fails when checking them. Solution: If a node has `display: none`, fall back to checking its `tagName` against `blockTagNames`. This ensures consistent behavior regardless of the node visibility. Steps to reproduce: - Open “Appointment: Attendee Invitation”. - Add a list item to the list in the content. - Save. - A QWeb parsing error occurs. opw-5268806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239482
This update fixes a bug where forum post images set to specific sizes (50% or 25%) weren't being saved correctly. The system was stripping inline styles, preventing the intended image resizing. This change disables the use of inline styles for image sizing in forum posts, ensuring images are displayed as intended.
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#240442 Forward-Port-Of: odoo/odoo#234354
This update fixes a visual issue where animation options within select and button group controls appeared cramped when placed on the same row. The change ensures that select text remains fully visible and button labels are displayed completely, improving the user experience and overall appearance of these controls.
Original PR description
Fix animation options layout when a select and a button group share the same row. Ensure the select text remains visible and the buttons show their full labels (e.g. for "onScroll"). | Before | After | | ------------- | ------------- | | <img width="290" height="39" alt="image" src="https://github.com/user-attachments/assets/4fb367fe-77f0-4038-ac2c-c0d856aeba8f" /> | <img width="288" height="40" alt="image" src="https://github.com/user-attachments/assets/99402e23-4144-42bf-81b1-7ddec0c35cfe" /> | | Before | After | | ------------- | ------------- | | <img width="290" height="36" alt="image" src="https://github.com/user-attachments/assets/39f1a6d0-3ba5-4c80-b452-5c5ba03cee2d" /> | <img width="289" height="39" alt="image" src="https://github.com/user-attachments/assets/482f84cc-7600-4510-91d7-1d6ad9d63937" /> | task-5353509
This update fixes a technical issue in the Point of Sale module that caused orders to be unnecessarily resynced and sent to the blackbox multiple times. The change prevents marking orders as 'dirty' after a write operation, resolving a synchronization loop. This improves system performance and data consistency.
Original PR description
Backport of what have be none in this PR: https://github.com/odoo/odoo/pull/231719
- Before this commit, after doing `await this.data.write("pos.order", [order.id], { nb_print: order.nb_print });` the order was marked as dirty. This was causing issue for the next `sync_from_ui` causing this order to be resynced and then send twice to the blackbox.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a technical issue where sales orders were being sent to the blackbox service multiple times. The fix ensures that sales data is only transmitted once, improving data accuracy and reducing unnecessary processing load. This is a routine maintenance fix.
Original PR description
This fix ensure we don't send twice the same NS (normal sale) to the blackbox. We only push the order to the blackbox if it does not contain a signature yet.
This update adds a new test helper within the spreadsheet module, streamlining the process of adding rows during testing. This enhancement ensures more robust and reliable testing of the spreadsheet functionality, ultimately improving the quality of the Odoo application. This aligns with our commitment to rigorous testing practices.
Original PR description
This commit adds a test helper to add a row. See enterprise PR 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 Forward-Port-Of: odoo/odoo#238730 Forward-Port-Of: odoo/odoo#238293
This update resolves a bug where inserting rows into a Quote calculator spreadsheet caused field syncs to disappear. The fix ensures that field syncs remain active even after adding new rows, maintaining data consistency within the spreadsheet. This improves the reliability of the Quote calculator for users.
Original PR description
Steps to reproduce: - create a Quote calculator spreadsheet - add a field sync on A1 - autofill it down on a few cells - select row B - right click and "Insert row above" => some field syncs disapeared Forward-Port-Of: odoo/enterprise#101367 Forward-Port-Of: odoo/enterprise#101066
This update resolves an issue causing dynamic website snippets to flicker between visible and hidden states. The fix ensures snippets are initially invisible and only display content when available, restoring the intended behavior. This improves the overall website appearance and user experience.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523 Forward-Port-Of: odoo/odoo#240036 Forward-Port-Of: odoo/odoo#238305