Daily updates from Odoo
Wednesday, October 22, 2025
14 changes · 18.0
Enhancements to existing features
The device homepage now shows a clearer warning when downloading the SSL certificate fails. This helps users understand what went wrong directly on the page, reducing the need to inspect system logs or request technical support.
Original PR description
We improved the certificate status warning displayed on the homepage to avoid having to check the logs to know what went wrong while downloading the SSL certificate.
Resolved issues and error corrections
This update ensures French VAT report submissions sent to ASPOne follow the required format rules. It helps prevent submission errors by using the expected address field and limiting postal code and city values to accepted lengths.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
Website editors can now open link previews for frontend pages like Contact Us or shop category pages without browser errors or incorrect warnings. The link popover also shows available page descriptions, making it easier to verify and manage links while editing content.
Original PR description
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. -…
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. - Click on a link to a frontend page, such as "Contact Us". - An error was thrown in the browser console. - Also, the link popover did not show the page description (even if it existed). This commit: - Fixes the error that occurred in the browser console. - Adds support for frontend website pages in the link popover. - Displays the page description in the linkpopover, if available. (The page description refers to the SEO field that can be set via: Site > This Page > Optimize SEO > Description) Commit 2: b8908f3 Before this commit: the condition to check if an url is internal is not complete as the user could user the odoo instance domain instead of the real domain. The check if an internal url is a frontend one is rather naive as there are cases where the url ends with a number but actually not leading to a record. Reproduction for the second use case: 1. create a link with frontend url for example `/shop/category/16` 2. click on the link, when it loads the preview, a warning pops up After this commit, the cases explained above are included. task-4971829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now correctly finds matching text even when it appears after a line break in longer descriptions or formatted content. This ensures automated rules and filters trigger as expected when using "contains" searches across multi-line text.
Original PR description
Problem: When the ilike comparator is applied in filtered_domain, it is unable to match text beyond a newline character (\n). This is due to the regex being used not having the DOTALL flag. Purpose: Add the DOTALL flag to the re.compile arguments when defining like_regex. Steps to Reproduce on Runbot: 1. Create an Automation Rule on the Task model with an Apply On condition of Description contains "test". 2. Create a Task and add an Info Banner element, then either within the element or afterwards include the "test" text, then save. 3. The automation rule does not trigger. opw-5134374
Delivery label printing now includes every attached label file in the chatter instead of printing only the first one. This ensures shipments with multiple label files are handled correctly, reducing manual reprints and fulfillment errors.
Original PR description
Before this commit, only 1 label get printed even if multiple files are in the chatter After this commit we handle the cases with multiple files + revert suppression of public method for API opw-5181209 Forward-Port-Of: odoo/enterprise#97805
Public ecommerce customers could get stuck after a successful payment because the system hit an internal access error while confirming accounting records. This fix ensures the payment confirmation can complete reliably when restricted journal security settings are enabled.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189
When users crop an image manually and then apply a shape, Odoo now keeps their chosen crop instead of reverting to the original image. Reset controls are also shown and styled more consistently, making image editing in the website editor clearer and more reliable.
Original PR description
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task…
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task [3678061](https://www.odoo.com/odoo/my-tasks/3678061), all shapes were applied using a 1:1 ratio for better UI. However, we didn’t account for cases where the user had manually cropped the image. In such cases, the shape was being applied to the original image with forced 1:1 cropping, ignoring the user's manual crop. Fix: Previously, applying a shape always cropped the image to 1:1 if crop was required and the aspect ratio wasn't already 1:1. This caused the user's custom crop area to be discarded. Now, a new `is-manual-crop` attribute is introduced. If present, the default 1:1 crop is skipped, preserving the user's manual crop. Also, the reset button didn’t appear for flexible crops(not using fixed ratios like 1:1 or 2:3) due to aspect ratio being 0/0. We now add the `o_we_image_cropped` class on save and remove it on reset to properly show or hide the reset button. After cropping, the reset button appears in red, while the transform reset button is grey. To maintain consistency, we are adding the `o_we_bg_danger` class to transformation button. This PR aims to respect the user’s manual crop when applying shapes. task-4718769
Website pages in right-to-left languages now load dynamic styling using the visitor's selected website language instead of the session language. This prevents portal pages with chatter from showing excessive blank horizontal space, improving usability for Arabic and other right-to-left users.
Original PR description
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll horizontally to the left Result: there is a huge amount of whitespace scrollable to the left. Cause: In 18.0, the chatter has an hidden textarea .o-mail-Composer-fake with position "left: -10000px; top: -10000px;". But the chatter assets (portal.assets_chatter_style) are called dynamically with getBundle which is using the session lang instead of the website lang. So the bundle is gotten with the wrong lang and the CSS is not rtlcss'ed and this create big whitespace to the left of the page. Fix: set the website request language when getting bundle for the frontend. Note: this PR also create a TestLangUrlCommon to prevent TestLangUrl tests of being run a second time in TestControllerRedirect. opw-5013485 Forward-Port-Of: odoo/odoo#223575
Point-of-sale orders are now synchronized one at a time instead of in large batches, reducing the risk of timeouts, missing orders, or incomplete synchronization. Loyalty coupon confirmations are also handled per order so rewards stay accurate even when syncing is delayed.
Original PR description
`syncAllOrders` method is now splitting the list of orders to synchronize them one by one. This allows to have better control over each order synchronization and error handling. Some customer were experiencing issues when synchronizing too many orders at once, leading to lost orders or orders not being synchronized properly. For example, synchronizing orders that needs to be invoiced takes too long and can lead to timeout issues. By synchronizing orders one by one, we ensure that each order is properly synchronized before moving to the next one. --- Modification in `pos_loyalty` module to adapt to this change: The `confirm_coupon_programs` method is now called for each order individually, instead of being called once for all orders in the `payment_screen`. This ensures that coupon programs are confirmed correctly for each order even when orders synchronization is delayed
This fixes an issue where deliveries linked to split manufacturing orders showed only the quantity from the original order, not the full produced amount. Businesses using make-to-order manufacturing will now see accurate delivery quantities after validating backorders, reducing shipping and fulfillment confusion.
Original PR description
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to…
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to reproduce ----- - Unarchive MTO route - Create a stored product - Routes MTO & Manufacturing - Empty BoM - Create a Sale Order for 3 units of the product & confirm it - Go to the linked MO and split it in 2 (quants of 1 and 2) - Confirm both MOs (and produce) - Go to the sale's delivery > The delivery's move only shows 1 unit of the product Why the move quantity is only 1 ----- After confirming the first of the 2 backorder productions, when we manufacture the product, we go through https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054 Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 Which creates a SML for the delivery move when reserving it https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858 https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971 This in turn triggers the computation of the move's quantity since it depends on the move's lines https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383 Our move ends up with a quantity of 1. When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 This means we don't create a new SML for the delivery move, so the quantity stays at 1. Why there is no move_dest_id ----- When splitting the production, we go through https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829 We create new a MO and SM for the backorder. The SM is created here https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915 When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656 So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78 In the write, we get to a line where we access the production's state https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931 This triggers a recompute of the field. https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552 In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800 The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f). https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167 ----- Ticket: opw-4865082
Project and Sales administrators can now open and update SMS templates used for projects and tasks without hitting an access error. This fixes incorrect access rules so authorized managers can maintain customer communication templates as expected.
Original PR description
**Issue** Project administrators are not able to manage SMS templates related to project models. **Steps to reproduce** - Have `project_sms` and `sale_sms` installed. - Have a regular user (not admin) with Project: "Administrator" and Sales: "Administrator" rights. - Go to Project/Task kanban view > cog icon on top of columns > edit > try to open/modify the SMS template. Issue: access rights error **Cause** - the rule in `sale_sms` is problematic because it is the only record rule affecting read operations, while other modules only target CUD operations. It has the effect of restricting read operations for Sale:Administrator users. - the rule in `project_sms` was referencing the wrong models, SMS templates are linked to `project.project` and `project.task`. opw-4908909 Forward-Port-Of: odoo/odoo#228590
This fix ensures landed costs are applied only to the relevant remaining quantity in a lot, rather than the lot’s total remaining quantity. This prevents overstated inventory values when only part of a lot is affected, improving the accuracy of stock valuation and product costing.
Original PR description
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the…
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the correct base values ## Cause: The cost repartition used `lot_id.quantity_svl` that's the total quantity of the lot , which leads to an incorrect ratio when only part of the lot is impacted As a result, the landed cost amount can be overstated, depending on the difference between the lot's total remaining_qty and the move's remaining_qty This logic only works when all `stock.valuation.layer` of the lot are involved, which is not always the case https://github.com/odoo/odoo/blob/e72b25fffc8f07c51e9a72fe6310e8dd046da793/addons/stock_landed_costs/models/stock_landed_cost.py#L125-L142 ## Steps to reproduce: - Enable Lots & Serial Numbers in Settings - Create a product (Tracked by lot + Valuated by Lot + AVCO) - Create and validate two receipts for the same product and lot - Open Inventory > Products > Lots / Serial Numbers page of Inventory and select your lot (The cost should be 0) - Add Landed Costs for the first receipt - Add a line for a cost of 100$ and compute (You’ll see that one line with 100$ should be added) - Confirm the Landed Cost and click Valuation (The value of the line is doubled to 200$) - On the Lot/Serial Number page of your lot, the cost is also double that the expected value opw-5128570
The scheduled check for Mexican electronic invoice status now rotates through all eligible invoices instead of repeatedly checking the same first batch. This helps ensure cancellations or status changes from the SAT portal are detected across the full invoice set.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.This fix ensures Argentine vendor bills for foreign suppliers consistently use the expected “Invoices and Receipts from Abroad” document type. It also aligns customer invoice defaults so foreign customers and suppliers receive the same suggested document type based on the selected journal, reducing manual corrections and compliance risk.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635