Daily updates from Odoo
Friday, October 17, 2025
42 changes · saas-18.4
New functionality added to Odoo
This update adds automated test coverage for key Point of Sale sales order interactions, including quotation handling, order lines, discounts, and down payment data. It helps reduce the risk of future regressions in POS sales workflows without changing day-to-day user behavior.
Original PR description
Task: [#4945627](https://www.odoo.com/odoo/my-tasks/4945627)
Community PR: [#221920](https://github.com/odoo/odoo/pull/221920)
Runbot: https://runbot.odoo.com/runbot/bundle/saas-18-3-hoot-pos-sale-ltra-390474
---
This commit adds Hoot tests for the `pos_sale` module:
- components
- control_buttons
- onClickQuotation (1)
- orderline (1)
- models
- pos_order_line
- getSaleOrder (3)
- saleDetails (2)
- setQuantityFromSOL (2)
- pos_order
- _getIgnoredProductIdsTotalDiscount (1)
- services
- pos_store
- onClickSaleOrder (4)
Also add a product used for down payments and create a sample sale order with two lines to support the tests.
Forward-Port-Of: odoo/odoo#221920Enhancements to existing features
Refreshing webhooks from the settings now clears the existing product links from the point of sale before sending a fresh menu to UrbanPiper. This helps ensure the external ordering platform receives an up-to-date menu and avoids stale product mappings.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Payroll users can now see and manage contract offers directly from the employee form without needing recruitment permissions. This gives payroll officers the access they need for offer and contract work while keeping responsibilities aligned with their role.
Original PR description
Previously, the Offers smart button on the employee form was only available to recruitment users. This limited visibility for payroll officers who also need access to contract offers. This commit Changes the button visibility to hr_payroll.group_hr_payroll_user in hr_employee_views.xml. Adds missing access rights in ir.model.access.csv for hr.group_hr_user (inherited by payroll users). Updates the module manifest to include the new security CSV. The goal is to ensure payroll users can access and manage offers directly without requiring recruitment rights. task-5085078
Users can now choose which IoT printer is used for shipping labels instead of the system automatically using the first available matching printer. This helps warehouses route labels to the correct printer for each operation type and avoids confusing errors when no printer is linked.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. backport of odoo/enterprise#86818 Task: 4792491 Forward-Port-Of: odoo/enterprise#97269 Forward-Port-Of: odoo/enterprise#95794
Changing inventory valuation settings on very large product categories is now much faster. This reduces delays and timeouts for businesses managing many product variants, making stock accounting configuration changes more reliable.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231206
This update adds test coverage for Indian electronic invoicing when exports are made without a Letter of Undertaking and prices already include tax. It helps ensure the taxable base is reported consistently with the invoice total, reducing the risk of incorrect compliance data.
Original PR description
Add test for export without LUT and price included tax, but base should be equal to invoice total. Forward-Port-Of: odoo/odoo#231943 Forward-Port-Of: odoo/odoo#231614
Bank journals now highlight invalid statements more clearly and avoid showing misleading statement or balance information. This helps accounting teams spot issues sooner, keep imported statement files attached, and prevent accidental deletion of transactions linked to valid statements.
Original PR description
This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473 Forward-Port-Of: odoo/odoo#222447
Bank statement screens now make invalid statements easier to spot and act on, including dashboard alerts, warning indicators, and clearer balance highlighting. The update also protects valid statement transactions from deletion and keeps imported statement files attached for better traceability.
Original PR description
* accountant|bank_statement_import This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473 Forward-Port-Of: odoo/enterprise#92078
This update adjusts tax rounding behavior for Mexican electronic invoicing so totals align more reliably with localization requirements. It helps reduce discrepancies in invoices and tax reporting when amounts are rounded.
Original PR description
Forward-Port-Of: odoo/enterprise#97220 Forward-Port-Of: odoo/enterprise#96809
Resolved issues and error corrections
This update ensures accounting localization tests always run with the required sample data installed. It helps keep automated testing consistent across versions and reduces the risk of test failures caused by missing setup data.
Original PR description
In later versions, we improve the testing suite to avoid having to install demo data in order to reduce the testing time. In order to keep the testing configuration simple across versions, we force the installation of demo data instead of only asserting that demo is installed before launching the script. Forward-Port-Of: odoo/odoo#231925 Forward-Port-Of: odoo/odoo#231660
Reverse charge taxes are now reported with the correct payable tax amount instead of showing zero. This helps Romanian SAF-T reports match tax authority expectations and reduces the risk of incorrect compliance filings.
Original PR description
When a reverse charge tax is used, we export a `TaxInformation` with a zero amount instead of the real amount of the tax. The tax authority requires to show the tax to pay and doesn't care about the tax to receive... In order to fix this, we only sum the tax details of lines having positive repartition lines. opw-5125678 Forward-Port-Of: odoo/enterprise#97315 Forward-Port-Of: odoo/enterprise#97117
The website SEO Auto-Fill action now works correctly on system pages such as login, signup, password reset, and donation payment pages. This prevents an error from interrupting users and allows SEO fields to be filled as expected.
Original PR description
Steps to Reproduce: 1.Go to the website and open a system page such as: /web/login /web/signup /web/reset_password /donation/pay 2.In the top menu, go to Site → Optimize SEO. 3.Click the Auto-Fill button. 4.Observe that a traceback appears. Before this commit: Clicking the Auto-Fill button caused a traceback error because pageTextContentEl was null due to wrong selector. As a result, getElementsByTagName could not be accessed. In this commit: We provide the correct querySelector value so that pageTextContentEl properly references the intended DOM element. This fix prevents the error and ensures that the SEO Auto-Fill button works correctly, populating all required fields without issue. task-4974618 Forward-Port-Of: odoo/odoo#220769
The payslip export option that led users to a missing page has been disabled in Payroll. This prevents confusion and avoids a 404 error when working with payslip records in debug mode.
Original PR description
Steps to reproduce: ------------------------- 1. Install `hr_payroll` module 2. Enable debug mode and click on Become Superuser 3. Go to All Payslips and open any payslip record 4. Click on the…
Steps to reproduce: ------------------------- 1. Install `hr_payroll` module 2. Enable debug mode and click on Become Superuser 3. Go to All Payslips and open any payslip record 4. Click on the Export Payslip button Observation: ------------------------- A 404 (Page Not Found) error appears when clicking the Export Payslip button Issue: ------------------------- The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359 The route was never reintroduced afterward, but the Export Payslip button remained in the view. As a result, clicking it leads to a 404 error Solution: ------------------------- 1. Temporarily bypass the `action_export_payslip` function. 2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button opw-5115946 Forward-Port-Of: odoo/enterprise#97361 Forward-Port-Of: odoo/enterprise#96359
Fixes a website builder issue where cancelling language selection after a save prompt could leave the save button disabled with a loading indicator. This helps users continue editing normally and reduces confusion during website customization.
Original PR description
debug test added in https://github.com/odoo/odoo/pull/229843
This fixes a display issue in mass mailing emails where dynamic placeholders could move onto their own lines after a mailing became read-only, such as after being sent. Sent mailing content now keeps placeholders in the intended position, preserving the original email layout for recipients and reviewers.
Original PR description
In editable fields, the Web Editor currently adds the data-oe-t-inline attribute to items that are identified as needing to be displayed inline However, this attribute is added by the editor and removed on save. As a result, if the previously-editable field is ever set to readonly (for example: a mailing that is sent no longer allows users to edit its body), then the inline property appears to be lost: an inline dynamic attribute suddenly looks like it's on its own line. Steps to reproduce: - Create a mailing - Add a dynamic attribute in the middle of a line - Send the mailing - You will see a carriage return directly before and after the dynamic attribute Fix: The mass_mailing html field now applies the current inlining logic to readonly HTML. task-4852246 Forward-Port-Of: odoo/odoo#227651
This fix ensures French VAT report submissions to ASPOne use the correct character limits for company name and address fields. It helps prevent rejected or invalid XML-EDI filings caused by fields being too long or incorrectly split.
Original PR description
The aim of this commit is making sure that the field Designation, DesignationSuite1, DesignationSuite2, AdresseVoie and AdresseComplement are correctly filled. Indeed, the XSD implied that these fields have to be respectively 35, 35, 35, 30 and 35 characters max. [Documentation 2025](https://www.aspone.fr/files/tutoriaux/xmledi/Documentation_XML-EDI.zip) no task id Forward-Port-Of: odoo/enterprise#97335 Forward-Port-Of: odoo/enterprise#97199
Customers and staff now see the correct message when a package is too heavy for all available Sendcloud shipping methods. This prevents an unexpected system error and helps users understand why delivery cannot be processed.
Original PR description
When a package exceeds the maximum weight supported by all shipping methods, the system raised an error (`KeyError: 'name'`) because the `stock.move` field was removed in commit #211488. This fix replaces the deprecated `stock.move.name` reference with the product name to correctly display the overweight message. opw-5137167
This fixes internal website testing helpers so plugins are included consistently, including when testing translation mode. The change helps prevent missed test coverage and improves confidence that website translation features behave correctly.
Original PR description
[FIX] website: always add plugin with test helper addPlugin and similar The test helper `addPlugin` and other similar helpers added the plugin with the registry entry `website-plugins`. This entry is not used in translate mode, thus the plugins added were not present for tests about translate mode. To also add the plugin for tests of translate mode, this commit changes the implementation of `addPlugin` to patch `WebsiteBuilder` instead. It also changes the implementation of other helpers that were doing the same things to instead call `addPlugin`. task-5176469
Swedish Bankgiro and Plusgiro accounts now include the required bank identifier information when generating SEPA payment files and Peppol invoices. This prevents missing clearing numbers and helps Swedish payments and e-invoices process correctly without changing behavior for other banks or countries.
Original PR description
… number Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents…
… number Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts. This commit introduces overrides for SE-specific account types: _get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML. _skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file. This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries. Backport of https://github.com/odoo/enterprise/commit/0534491bcd7eed7d246bea85d6ac217a80af815b Forward-Port-Of: odoo/enterprise#97330
Project sharing pages now display tags in the same light style as the rest of the interface. This removes a visual inconsistency that could make shared project views look less polished or harder to read.
Original PR description
Before this commit, the project sharing was using the dark style for tags even though the rest of the views are in light mode. Removing the tags_list.dark.scss file from the imported file in the manifest fixes this issue. task-5130176 Forward-Port-Of: odoo/enterprise#96751
Uruguayan electronic invoices now correctly include invoice lines with a zero value by marking them as free delivery. This ensures required information is sent to the tax authority and avoids missing lines in electronic invoice records.
Original PR description
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by…
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount ## Steps to reproduce 1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 2. Add a line with quantity 1. price 0 3. Add a second line with quantity 1, price 500 and discount 100% ## Before this PR 1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery. 4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all ## After this PR Both lines are informed to DGI using the invoice indicator 5 (Free Delivery) You can check this on to generate CFE XML in demo mode (not need to connect to UCFE) If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file. References [Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691) LATAM 1350 / ADHOC task 53445 Forward-Port-Of: odoo/enterprise#89808
The update prevents bill creation from failing when an Indian GST tax unit includes multiple companies and the main company lacks a purchase journal. The system can now use a valid purchase journal from the wider tax unit, helping teams create bills from IRN records more reliably.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. Forward-Port-Of: odoo/enterprise#97255
Administrators can now retry or cancel SMS messages sent automatically by the system without running into an access error. This helps support and operations teams resolve failed delivery or notification messages directly from technical settings.
Original PR description
## Issue: In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An…
## Issue: In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised ## Cause: When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS ## Steps to reproduce: - Install an app like stock_sms to create blocking entries - Create and confirm a Delivery - Choose Send SMS - Enable developer mode - Search for the technical settings SMS - Retry sending the automatically sent SMS opw-4904157 Forward-Port-Of: odoo/odoo#230733
Customers who must sign in before using the online store are now sent back to the cart, shop, product, or checkout flow they were trying to access. This prevents lost checkout progress after creating appointments or proceeding to payment, improving the buying experience.
Original PR description
**Steps to reproduce:** - Install eCommerce and Appointment - Set `Ecommerce Access` to `Logged in users` in Settings > Website - Go to the website without logging in - Create an appointment - Proceed to make the payment - You will get redirected to the sign-in page due to the setting - After logging-in the system doesn't redirect back to the checkout form **Issue:** When the user is not logged and the setting is applied, the user is directly sent to the login page without further redirection. **Fix:** Added redirect param to the original url target. opw-4965735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230282 Forward-Port-Of: odoo/odoo#229346
Posting vendor bills now preserves the related analytic items when analytic accounts are set on bill lines. This prevents missing analytic reporting data in cases such as journals without Auto-Check on Post or when accounting lock dates apply.
Original PR description
To reproduce: 1. Ensure Analytic Accounting is activated in the accounting settings 2. Uncheck the option Auto-Check on Post in the Vendor Bills journal 3. Create a vendor bill and set analytic…
To reproduce: 1. Ensure Analytic Accounting is activated in the accounting settings 2. Uncheck the option Auto-Check on Post in the Vendor Bills journal 3. Create a vendor bill and set analytic accounts in at least one line 4. Post the vendor bill 5. Go to Accounting > Analytic Items 6. No analytic item was created for the vendor bill In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines. Cause: In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted. Solution: The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals. opw-5053179,opw-5154394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231874
This fix prevents certain automatically created document attachments from being uploaded to external cloud storage. It helps ensure files needed by document-related business processes remain handled in the expected local document flow.
Original PR description
Some models' attachments will automatically become document attachments which may be used in business code of documents. This commit avoids uploading these attachments to the cloud storage. 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#231628
This fixes invoice cost calculations for dropshipped kit products when purchase prices are manually changed. Businesses will now see cost of goods sold journal entries that match the actual purchase order value, improving margin and accounting accuracy.
Original PR description
**Problem:** When confirming the invoice of an order delivered via dropship for some kit bom product with fifo/avco comp, if the price was manually set on the purchase order, the invoice lines…
**Problem:** When confirming the invoice of an order delivered via dropship for some kit bom product with fifo/avco comp, if the price was manually set on the purchase order, the invoice lines generated for the cogs are inaccurate **Steps to reproduce:** - In settings enable dropshipping, automatic account and anglosaxon accounting - Create a kit product with one component. - Set the route as Dropship for the component. - add a vendor in the purchase tab of the component. - set the cost of the component at 2 - Set the product category to AVCO (Automated) for the component and the product. - Create and confirm a sales order with a quantity of 2 for the product. - On the purchase order set the unit price at 20 for the component. - Confirm the purchase order, then validate the delivery and create the customer invoice. - Confirm the invoice **Current behavior:** In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 22 **Expected behavior:** The value should be 40, in accordance with the purchase order **Cause of the issue:** In the mrp_account override of _compute_average_price, the stock move has no bom because it was generated from the purchase order, so this condition will be true https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L67 This is not a problem, however the problem comes from the fact that move.product_id is already equal to qty_to_invoice \*component_quantity. https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L73 Multiplying it a second time by qty_to_invoice is an error. For instance in our steps, qty_to_invoice is 2, compenent_quantity is 1 and move.product_qty is 2. So when calling _compute_average_price for the comp, we call it with a qty_to_invoice parameter of 4 instead of 2. As a result, because the candidates svls only have a quantity of 2, there will be we a missing quantity. https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/stock_account/models/product.py#L927-L934 So the result will be the average between the quantity on the purchase order (20) and the standard price (2). Which is why the account line has a value of 22 (2*11) opw-4985440 Forward-Port-Of: odoo/odoo#229956
German POS certification exports now use the order creator when the assigned order user is missing. This prevents session closing from being blocked during required DSFinV-K export generation, helping shops complete end-of-day operations more reliably.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. Although the exact reproduction steps are not consistently found, this issue is recurrent. This change makes the code more robust by defaulting to the order's create_uid when the user_id is empty or missing, ensuring the transaction export data remains valid. opw-5123890 Forward-Port-Of: odoo/enterprise#96002
The website team section now only applies avatar sizing rules to team member photos, not to images added in descriptions. This prevents description images from being incorrectly resized on mobile pages, improving the visual presentation for visitors.
Original PR description
Scenario:
- Add s_company_team snippet ("Meet our team" with avatar side by side
with description)
- Add an image in the description (small or big)
- See the page with mobile
Result: all images in the description get a fixed 50% max-width (from
18.0 a 8rem height) which was only meant for the avatar image.
Fix: be more specific with the selector to target only the avatar. The
selector .row.s_col_no_resize > .o_not_editable img.o_editable_media
should only target the intended avatar.
opw-4997932
Forward-Port-Of: odoo/odoo#231793
Forward-Port-Of: odoo/odoo#225412This fix prevents the Chilean electronic invoice email import from crashing after the first XML attachment is processed. Businesses using Chilean electronic invoicing can process incoming supplier documents more reliably and with better performance.
Original PR description
Description of the issue/feature this PR addresses: Fixes https://github.com/odoo/odoo/issues/230014. Current behavior before PR: Crashes after processing the first XML because of savepoint implementation. Desired behavior after PR is merged: No crash. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change restores the previous currency translation behavior for cumulative translation adjustments in accounting reports. It prevents year-over-year balance sheet revaluations from using an inappropriate current rate, helping financial statements remain accurate.
Original PR description
This reverts commit c440bb52d19b8dcec8b708509973c4095a577b34 as it doesn't work as expected in year-over-year re-evaluation in balance sheets. task-5085888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231823 Forward-Port-Of: odoo/odoo#231718
Financial reports now use the proper closing exchange rate for currency translation adjustments instead of the current rate. This helps ensure balance sheets and partner/accounting reports show more accurate currency conversions for period-end reporting.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888 Forward-Port-Of: odoo/enterprise#97320 Forward-Port-Of: odoo/enterprise#97271
Odoo eCommerce sites can again share product feeds with Google Merchant Center to improve product visibility and keep listings current. The feed no longer includes shipping details, making it faster and more reliable, with product limits and caching added to support scalability.
Original PR description
In [^1], a new feature was introduced to allow users to synchronize their eCommerce with Google Merchant Center and increase their product visibility, keep stock status updated, and improve product…
In [^1], a new feature was introduced to allow users to synchronize their eCommerce with Google Merchant Center and increase their product visibility, keep stock status updated, and improve product listings. However, the initial implementation attempted to include shipping information in the feed, which required computing rates for every product, carrier, and country. This quickly became infeasible due to performance constraints and third-party carrier rate limits, forcing us to disable the feature [^2]. This commit reintroduces the GMC feed without shipping details, making it lightweight and reliable. To ensure scalability, we also (i) enforce a limit of 5000 products per feed, and (ii) introduce a caching mechanism to avoid recomputing expensive product data (e.g., prices) for subsequent requests. ~~task-5049357~~ task-5144256 See also: - https://github.com/odoo/upgrade/pull/8605 [^1]: https://github.com/odoo/odoo/pull/186976 [^2]: https://github.com/odoo/odoo/pull/224649 Forward-Port-Of: odoo/odoo#225536
This change prevents Chilean electronic invoice email processing from leaving the system transaction in a broken state when an attachment cannot be decoded. It helps scheduled email imports recover cleanly from expected document errors and continue handling invoices more reliably.
Original PR description
During l10n_cl_edi's fetchmail cron, if the decoding of a DTE attachment fails, `_create_records_from_attachments` rolls back the transaction, which prevents the savepoint in `_fetch_mail` from being…
During l10n_cl_edi's fetchmail cron, if the decoding of a DTE attachment fails, `_create_records_from_attachments` rolls back the transaction, which prevents the savepoint in `_fetch_mail` from being restored. Doing a commit/rollback within a `cr.savepoint()` is not correct. Since a new transaction is started, the savepoint no longer exists. Failing to restore the savepoint leaves the transaction in a broken state. Thus, we need to remove either the savepoint or the commit + rollback performed by `_create_records_from_attachments`. See https://github.com/odoo/odoo/issues/230014 We can remove the savepoint because `_extend_by_attachments` already catches exceptions which typically represent decoding errors (such as ValidationError, UserError, ValueError, psycopg2.errors.IntegrityError). These errors are recoverable from a transaction point of view; the import fraw recover from them by leaving an empty invoice with the attachment. Other errors are typically not recoverable and it does not makes sense to attempt to recover from them using a `cr.savepoint()`. opw-5147385
This fixes an issue where generating payroll runs in a multi-company setup could be blocked by access restrictions. Businesses using Swiss payroll can now create pay runs for the right company more reliably, reducing payroll processing interruptions.
Restaurant floor plans now place tables correctly when staff drag them on tablets or mobile devices. This prevents layout mistakes and makes table management smoother on smaller screens.
Original PR description
Task: [#4383744](https://www.odoo.com/odoo/project/1737/tasks/5045938) --- On mobile and tablet devices, the floor plan removes top and left padding to position tables closer to the top-left corner and avoid unnecessary scrolling. However, dragging a table did not take these offsets into account, resulting in incorrect placement during the action. Forward-Port-Of: odoo/odoo#231042
Mexican electronic invoices now correctly include customs permit numbers in the generated XML when they are entered on invoice lines. This helps businesses meet CFDI documentation requirements and avoid missing import information on printed or shared invoice files.
Original PR description
Lines with customs number did not have the node NumeroPedimento in their cfdi xml. - With l10n_mx_edi_landing, create an invoice. - On the move line add a custom number. - Print the invoice, look for NumeroPedimento in the xml. In the method l10n_mx_edi_add_invoice_cfdi_values the key informacion_aduanera_list contained the information about the custom number. However, it was not added to the l10n_mx_cfdi_values. opw-5097386 Forward-Port-Of: odoo/enterprise#95773
Companies based outside the EU can now save valid European VAT numbers without being blocked by country-specific VAT validation. This helps international businesses record tax identifiers correctly when they operate or are registered for VAT in Europe.
Original PR description
****Behavior:**** **Current:** When a company is assigned a VAT number, the integrity of the VAT is checked according to the rules of the company's country except when a EU country is assigned an other EU country's VAT, then the integrity of the VAT is checked according to the other EU country's rules. **Expected:** We want to allow Foreign companies to have valid European VAT numbers. **Steps to reproduce:** - Create a new contact, select company and add any name - Select a country that is not in the EU and has implemented the VAT system (Ex: China, Australia | Some countries, like the US or some smaller countries, don't have an implementation in Odoo, or just dont use VATs, in that case they are allowed to put whatever in the VAT field) - Input a valid EU VAT number in the Tax ID field (ex: FR17698800935) - when saving, the system should raise a Validation Error. opw-5080231 Forward-Port-Of: odoo/odoo#231177
This fix improves how Odoo calculates and rounds taxes that are already included in a product price, preventing small mismatches where totals could be off by a cent. It also simplifies the underlying tax calculation logic, making country-specific tax rules easier to maintain and reducing the risk of similar rounding issues in invoices, discounts, POS orders, and tax summaries.
Original PR description
== Fix bug price-included == Suppose a line of 24.99 with a 20% tax price-included. base: 24.99 / 1.2 = 20.825 tax: 20.825 * 0.2 = 4.165 If we round both, we get 20.83 + 4.17 = 25.0 != 24.99 == Split and simplify round_base_line_tax_details == Easier implementation of this method to be easier to understand and easier to be customized (see PT override). Also, we now use the aggregate methods to aggregate the amounts instead of doing that by hand. opw-4505888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231640 Forward-Port-Of: odoo/odoo#228437
This fixes the Indian localization setup so SEZ LUT fiscal positions use the correct SEZ LUT taxes instead of export LUT taxes. Businesses using this tax configuration should see more accurate tax handling for SEZ LUT transactions.
Original PR description
For SEZ LUT Fiscal the taxes were wrongly mapped with Export LUT In this commit, We fix the SEZ LUT Fiscal are mapped correctly with SEZ LUT taxes --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232111
This fix prevents valid PDF font names containing special characters from being rewritten in a way that can break PDF processing. It helps ensure documents with affected fonts can still be generated or modified reliably, such as when adding banners to reports.
Original PR description
Patch the following commit locally: https://github.com/py-pdf/pypdf/commit/8c542f331828c5839fda48442d89b8ac5d3984ac Issue: A PDF files contain `/FontName /TimesNewRomanGreek#5Bbold#5D`. While this is…
Patch the following commit locally: https://github.com/py-pdf/pypdf/commit/8c542f331828c5839fda48442d89b8ac5d3984ac Issue: A PDF files contain `/FontName /TimesNewRomanGreek#5Bbold#5D`. While this is a valid font descriptor, it gets converted to `/FontName /TimesNewRomanGreek[bold]` in `NameObject.read_from_stream` through `unhexlify` (see the complete call stack below) The converted value is not longer valid as `[` marks the start of a `ArrayObject`. The character should have been escaped back to `#5B` before being written in a new document. ```python /home/odoo/git/odoo/odoo/addons/account/models/ir_actions_report.py(37)_render_qweb_pdf_prepare_streams() -> stream = pdf.add_banner(stream, record.name or '', logo=True) /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(288)add_banner() -> new_pdf.write(output) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(935)write() -> self.write_stream(stream) /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(127)write_stream() -> super().write_stream(*args, **kwargs) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(908)write_stream() -> self._sweep_indirect_references(self._root) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1057)_sweep_indirect_references() -> data = self._resolve_indirect_object(data) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1102)_resolve_indirect_object() -> real_obj = data.pdf.get_object(data) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_reader.py(1256)get_object() -> retval = read_object(self.stream, self) # type: ignore /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(841)read_object() -> return DictionaryObject.read_from_stream(stream, pdf, forced_encoding) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(270)read_from_stream() -> value = read_object(stream, pdf, forced_encoding) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(834)read_object() -> return NameObject.read_from_stream(stream, pdf) /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(469)read_from_stream() -> name = NameObject.unnumber(name) > /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(450)unnumber() -> while i >= 0: ``` opw-4991601 Forward-Port-Of: odoo/odoo#229489
Miscellaneous changes
opw-5018450 Forward-Port-Of: odoo/odoo#231654 Forward-Port-Of: odoo/odoo#231394
Original PR description
opw-5018450 Forward-Port-Of: odoo/odoo#231654 Forward-Port-Of: odoo/odoo#231394