Daily updates from Odoo
Wednesday, October 22, 2025
31 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.
This change improves how sales orders find their related projects by adding a database index. It can reduce delays when working with sales orders linked to many projects, without changing user-facing behavior.
Original PR description
This commit adds an index on `project.project. reinvoiced_sale_order_id`, because the search in `sale.order. _compute_project_ids` might not be selective enough based on `sale_order_id`, which is a related field using `sale_line_id`. Since it's related, there is only a where clause on `sale_line_id IS NOT NULL`, which might not be selective enough and leads to a Seq. Scan of the `project_project` table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Saudi e-invoices now preserve the negative amount on tax-exempt invoice lines instead of sending it as a positive value. This prevents avoidable ZATCA validation warnings and helps ensure invoices with refunds, discounts, or negative exempt lines are reported accurately.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
This fix prevents module updates from failing when default tracking sources or mediums have been renamed or duplicated by users. It helps keep CRM live chat and UTM tracking data stable during upgrades without disrupting existing customizations.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
The HTML editor toolbar no longer appears when users select non-editable content inside an editable area, such as protected report elements. This reduces confusion and prevents users from seeing editing options that do not apply, while still allowing toolbar editing for icons.
Original PR description
Before this commit: The toolbar appeared even when selecting a contenteditable false element within the editable area. For instance, while editing a report, clicking on a non-editable element like a delivery slip would still show the toolbar. After this commit: The toolbar is hidden when the selection is within contenteditable false elements or consists only such elements. Exception: The toolbar remains visible for icons, as they are editable by the toolbar. Tests are added. task-4309925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The blog sidebar's "Add some" tag link now opens the correct backend tag management page instead of sending users to the homepage. This helps website editors quickly add or manage blog tags without hitting a broken navigation path.
Original PR description
Scenario:
- go on frontend to a blog post without tag
- edit the page and in Customize enable the sidebar
- click on "Add some" link in tag section
Result: the link is like /odoo/action-/1?menu_id=451 and redirects to
the homepage.
Cause: there is no action variable set in the view from 16.0 up to master,
not having the action worked in URL that contained the model and record id
before 18.0 update (9cf0b8c256589ccd71b01bd28bd2e595848ff45e) but it
doesn't work with /action-{action_id}/{res_id}.
Fix: using the model route directly (that is what we would be redirected
if we used the old URL path).
opw-4706629
opw-4783643Public 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
Long mailing list names now stay within their designated area instead of covering nearby fields. This keeps the Marketing mailing list view readable and easier to use when lists have lengthy names.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This change makes an automated mail test more consistent by setting a visual border value explicitly. It helps prevent environment-specific differences from causing build failures, improving reliability for future updates.
Original PR description
Problem: Runbot build fails due to different resulting `border-color` values. Cause: The default `border-color` can change depending on the environment, leading to non-deterministic behavior. Solution: Specify the `border-color` explicitly to ensure consistent results. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Spanish point-of-sale receipts now correctly display the company's state name instead of empty brackets. This avoids confusing or incomplete receipt details for businesses using simplified invoices in Spain.
Original PR description
**Steps to reproduce:** - Set a spanish company, set the state - Set the "Simplified Invoice" journal in the settings - Go to PoS and make a purchase - On the receipt, empty brackets are shown where the state should be **Why the fix:** Before this commit, we checked that the company had a state set, and if it had, we displayed *state_id[1]* between brackets. Even if the state_id existed, this is not the correct structure for the state_id, so *state_id[1]* did not exist, and we displayed only the brackets. We now display the correct state name, still between brackets. opw-5098212
The website editor now correctly applies speed changes made with the slider for animated background shapes. This restores expected visual customization behavior when users design pages with animated snippets.
Original PR description
Steps to reproduce: - Drop a snippet - Add a background shape (e.g. Rainy 05) - Use the slider to change the speed - Nothing happens This commit is adapting `CSS_ANIMATION_RULE_REGEX` as it was too restrictive, the space after the colon is now optional. task-5170549
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 change fixes how Odoo's web test tools handle custom responses during automated testing. It helps ensure tests behave as intended when a developer supplies a complete response, reducing misleading test results and improving development reliability.
Original PR description
Before this commit, when an 'onRpc' handler would return a 'Response' object, it would still be wrapped in a JSON-RPC payload (under the 'result' key) if the "content-type" header specified that it was a JSON-RPC. However, if a 'Response' object is returned by the handler, it usually means that the response should be that object as-is, as it was created with the desired final parameters. This commit ensures that 'Response' values are returned as they are, instead of being wrapped in a JSON-RPC payload object. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Fixed an Accounting issue where grouping customer invoices by sent status showed every invoice in both the Sent and Not Sent groups. Users can now rely on this grouping to accurately review which invoices have or have not been sent.
Original PR description
### Issue: The groups "Sent" and "Not Sent" display all the invoices. ### Steps to reproduce: - Go in Accounting > Customer > Invoices - Create a custom GroupBy with "Sent" - Unfold the groups: all invoices appear in each group ### Cause: `web_read_group` returns the groups with their length and the domain corresponding. When unfolding `web_search_read` uses the given domain to get the records to display. Here the issue comes from the domain returned, it contains `['move_sent_values', '=', 'sent']`, but `move_sent_values` is a computed field that doesn't have a `_search` method so the domain doesn't filter on this field. ### Solution: Add the method `_search_move_sent_values` to search on `is_move_sent`. opw-5164650
This fixes a formatting issue where page numbers could split across two lines in folder-style report footers when using the Montserrat font. Keeping the page number on one line improves the professional appearance and readability of generated reports.
Original PR description
The folder layout is using the same footer than the `external_layout_standard` but when using Montserrat, the page number wraps in 2 lines on the folder layout. It's missing a `text-nowrap` class. task-4942402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The blog archive preview test no longer depends on the English name for October. This prevents the test from failing when the website is used in another language, improving reliability for multilingual sites.
Original PR description
Before this commit the blog_tags_with_date tour tried to select the October option by label. In other locales the month label differs and the tour could not find it, so the tour aborted at that step. Steps to reproduce: - Change the website language to one where October has another name. - Run the blog_tags_with_date preview tour. The tour now selects the first month option by index, independent of labels. runbot-233321
A typo in the Web Studio field name was corrected from "Multine" to "Multiline". This improves clarity for users configuring views and helps avoid confusion when selecting field types.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
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
Fixed a visual issue in the timesheet month view where text could spill into the timer and total/footer areas when users increased text size and scrolled horizontally. This keeps timesheet information easier to read and avoids confusing overlapping content.
Original PR description
Steps to reproduce: - Open timesheets and change to Month scale. - Increase text size a little bit. - Scroll to the right side Issue: - You can see runover text being visible in timer button cell of Total row and Footer row. Reason: - It is due to z-index problem as z-index-* is deprecated from https://github.com/odoo/odoo/pull/165568 (from saas-17.4+). Fix: - Replace it with Bootstrap z-index class notated as z-*(-1 to 3) task-4949182
Code cleanup and technical improvements
This change reorganizes how inventory accounting prepares product revaluation data. It makes the process easier for custom extensions to adapt without changing standard behavior for everyday users.
Original PR description
This allows to make it hookable by custom addons This was split from https://github.com/odoo/odoo/pull/160527 cc @pfertyk @sys-odoo @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228204
Miscellaneous changes
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#82978