Wednesday, April 1, 2026
18 changes · saas-18.3
New functionality added to Odoo
This update adds the IoT Base module to Odoo's translation management system (Weblate), enabling the module to be translated into multiple languages. The change includes translation files for over 20 languages, making the IoT Base functionality accessible to users worldwide in their preferred languages.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#254996 Forward-Port-Of: odoo/odoo#254667
Resolved issues and error corrections
This update fixes a bug where the wrong contacts were being added as followers to tax report entries, causing them to receive unwanted notifications. Additionally, a cron job that processes tax submission status has been improved to correctly handle multiple records instead of only processing the last one.
Original PR description
The method call that is supposed to subscribe the current user to the closing entry when posting XBLR used the User id as a Contact id. This caused random contacts to be added as followers of the chatter thread and as a result receiving notifications for it. The fix is simply using the id of the User's Contact instead. Also, as discussed with prro on Discord, fixed the cron clearing its dictionary each loop. opw-5886621 Forward-Port-Of: odoo/enterprise#107843
Fixed an issue where subscription product billing periods were not showing when products were added to website pages using the product snippet editor. The billing period information is now properly displayed on product cards, matching the behavior shown on the shop page.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943 Forward-Port-Of: odoo/enterprise#112171
This fix resolves an issue where the "Load more" line in financial reports was being incorrectly hidden when the "Hide lines at 0" option was enabled. The fix ensures that "Load more" lines remain visible even when hiding zero-value lines, allowing users to access additional report details as needed.
Original PR description
When activating the 'Hide if 0' option, the 'Load more' line is hidden. Fix: Filtering out the lines with empty columns (Load more lines) from the zero lines. Steps: - Open GL (occurs with other reports as well), and open configuration for this report - Set Load more limit to 1, and hide if zero to optional - Go back to GL report and select the 'Hide lines at 0' option -> Load more lines are hidden as long as the zero lines opw-5953725 Forward-Port-Of: odoo/enterprise#109380
This fix corrects how shifts are split when using the daily view in the planning schedule. Previously, splitting a shift within a single day would incorrectly snap the resulting shifts to standard working hours (8am-5pm), creating duplicate shifts with wrong timeframes. Now, shifts are properly split at the exact time requested, preserving the original shift boundaries.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243 Forward-Port-Of: odoo/enterprise#105991
This fix corrects a bug where users could incorrectly change the "Recurring" setting on subscription products that have confirmed sales orders. Previously, rapid clicks on the setting could bypass the intended protection. The fix now properly validates changes against the server's current value instead of the form's temporary state, ensuring the system correctly prevents unauthorized modifications.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server. Forward-Port-Of: odoo/enterprise#110877
This fix addresses an issue where text formatting (bold, italic, etc.) on iOS Safari was not working correctly due to improper cursor positioning. The change adjusts where the cursor is placed after applying formatting, ensuring that Safari properly recognizes and displays the formatted text. This improves the text editing experience for iOS Safari users.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256370 Forward-Port-Of: odoo/odoo#249253
This update fixes a problem where website assets fail to load properly after design changes in multi-database environments. When a user modifies website styling (like theme colors), the system regenerates assets but couldn't find them immediately due to database synchronization delays. The fix ensures assets are properly available right after regeneration, preventing broken website displays.
Original PR description
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created…
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env. In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle. Steps to reproduce: 1. Configure Odoo with a PostgreSQL primary/replica setup. 2. Open a website in edit mode. 3. Trigger an asset regeneration (for example by changing a theme color). 4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle. Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env. opw-6034833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255530
Optional product tables in sales documents were not displaying with the correct report styling due to DOM structure differences. This fix applies the proper styling to these tables so they appear consistently with other report tables. Users may need to update their document layout settings for color changes to take effect.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This fix resolves an issue where refunds created from invoices with duplicate line items (same product, price, and discount) were incorrectly matched. The system now prevents matching the same invoice line multiple times and ignores line labels during matching, ensuring accurate refund processing for Jordan EDI compliance.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This fix prevents the system from creating false absence records for employees whose employment contracts haven't started yet. Previously, when running the absence detection process, employees with future contract start dates would incorrectly be marked as absent, creating negative overtime records. The system now properly checks contract dates before flagging absences.
Original PR description
### Steps to reproduce: - Create an employee with contract starts in the future - Activate the Absence Management from attendance settings - Run the cron of Absence Detection - Notice an absence attendance got created for the emp with the future contract ### Cause: We don't check for contracts start dates when fetching absent employees and we get expected attendance for them from their working schedule so we create -ve overtime for them. ### Fix: We filter the absent employees on their running contracts. It has been fixed in since 18.4 in this commit https://github.com/odoo/odoo/commit/5db242416522524849a20eb83df3937c193c98d3 opw-5942239 Forward-Port-Of: odoo/odoo#253358
Users encountered an access rights error when trying to create private tasks (tasks with no project and no assigned users). This fix automatically assigns the task creator as a user when a private task is created, ensuring they have proper access to their own task. This resolves a frustrating error that prevented users from creating private tasks while maintaining the ability to modify existing tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242216
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
This update improves the demo payment provider by adding validation checks to ensure the payment provider is properly configured before processing transactions. This prevents errors and ensures a smoother payment experience for users testing the demo payment functionality.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Fixed an issue where the bold formatting button would not remove bold styling when the selection included embedded components like files. The editor was incorrectly considering non-editable elements when determining whether to apply or remove bold formatting, causing the toggle to get stuck in "apply" mode. This fix ensures only editable content is evaluated when toggling text styles.
Original PR description
When determining whether the "bold" action is about adding bold or removing bold, non-editable text nodes are also taken into account. Because of this, if the selection contains an embedded component such as `/file`, it always considers bold was not applied on all nodes, and should therefore be applied. The action thus never removes bold. This commit fixes this by only taking into account the editable nodes. Steps to reproduce: - Go to a "To do" note - Add a few lines of text - Add a `/file` in the middle - Select all - Press Ctrl+B: bold is applied on the surrounding text - Press Ctrl+B again => Bold was not removed from the surrounding text task-5955977 Forward-Port-Of: odoo/odoo#249816
This fix improves how Odoo extracts embedded files from PDF documents. Previously, PDFs with a specific organizational structure (/Kids nodes) would not have their embedded attachments extracted, resulting in empty bills when uploading such PDFs to the accounting dashboard. The fix now supports both standard and hierarchical PDF file organization methods, ensuring all embedded content is properly detected and extracted.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#252523
This update fixes a display problem in the website editor where product category previews were not showing correctly. The issue was caused by missing variable definitions that prevented proper styling from being applied. This ensures that when users preview different layout options in the editor, all visual elements display as intended.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr