Daily updates from Odoo
Friday, October 17, 2025
205 changes
7 changes
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
12 changes
Resolved issues and error corrections
This fix improves how Odoo rounds taxes that are already included in prices, preventing small one-cent mismatches between line totals and tax breakdowns. It also simplifies the underlying tax calculation flow, making localized tax rules easier to maintain.
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#228437
SAF-T reports now show the required tax payable amount when reverse charge taxes are used, instead of reporting zero. This helps Romanian tax filings reflect the amounts tax authorities expect and reduces the risk of incorrect compliance reports.
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 payroll screen no longer exposes an export payslip action that led users to a missing page. This avoids confusion and prevents employees or administrators from encountering a 404 error when viewing payslips 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
Dynamic placeholders in email mailings now keep their intended placement when a mailing becomes read-only after being sent. This prevents unwanted line breaks around personalized content, helping sent mailings display as designed.
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
French VAT report submissions to ASPOne now use the correct maximum lengths for key company name and address fields. This helps prevent rejected or invalid electronic filings caused by values that exceed ASPOne’s required format.
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
This fixes Swedish Bankgiro and Plusgiro handling so payment and e-invoice files include the required bank identifier and clearing number. Businesses using these Swedish account types should see fewer rejected or incomplete SEPA payments and Peppol BIS 3 invoices, while other bank flows remain unchanged.
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
Fixed an issue where vendor bills with multiple vehicles could cause the tax report to fail when taxes were split across different accounts. Tax report calculations now keep vehicle-related tax lines matched correctly, improving reliability for companies using Fleet and Accounting together.
Original PR description
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50%…
**Steps to reproduce:** 1. Install the *Fleet* and `accounting` modules. 2. Create a new purchase tax. 3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund. 4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines. 5. Check the *Tax Report*(account>tax), including the date of this vendor bill. **Observed behavior:** * Tax lines linked to the current asset account are merged. * Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`). * This mismatch triggers an error in the tax report. **Root cause:** The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles. **Solution:** Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error. opw-5013757 Forward-Port-Of: odoo/odoo#228422
Project sharing pages now show tags in the same light visual style as the rest of the page. This removes an inconsistent dark tag appearance, making shared project views look cleaner and more coherent for users.
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 include invoice lines that have a zero price by marking them as free delivery. This ensures these lines are reported correctly to the tax authority, avoiding missing information in submitted CFE documents.
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
Creating bills from Indian e-invoice data now works more reliably for tax units with multiple companies. The system can find an available purchase journal across the tax unit instead of failing when the main company does not have one configured.
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 generated by the system without being blocked by 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 eCommerce are now sent back to the correct shopping or checkout page after logging in. This prevents abandoned appointment or purchase flows caused by being left on the sign-in page instead of continuing payment.
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
7 changes
Resolved issues and error corrections
A broken Export Payslip action in Payroll is disabled because it led users to a Page Not Found error. This prevents confusion when viewing payslips, especially in debug or superuser mode, without affecting normal payroll processing.
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
Error messages for US payroll and payment processing now use the same bank field label that users see on the form. This helps users quickly identify the missing or incorrect bank information needed to complete payroll or NACHA payments.
Original PR description
The label shown in the res.partner.bank form view depends on the show_aba_routing field. If we don't show the correct label in these error messages it's not clear to the user what field they have to fill. task-5052996
Swedish Bankgiro and Plusgiro accounts are now handled correctly when generating SEPA payment files and Peppol invoices. This prevents missing bank details in payment exports and helps ensure Swedish invoices meet required electronic invoicing rules.
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 show tags using the same light styling as the rest of the page. This fixes a visual inconsistency that could make shared project views look mismatched 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 that have a zero value by marking them as free delivery. This helps ensure invoices sent to the tax authority are complete and compliant when businesses provide free items or fully discounted lines.
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 failures when creating vendor bills from IRN data in Indian GST reports for tax units with multiple companies. It now looks for a valid purchase journal across the full tax unit instead of only the main company, helping bill creation complete 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
This fix prevents German POS session closing from failing when an order is missing its assigned user during required DSFinV-K export generation. The system now uses the order creator as a fallback, keeping export data valid and reducing operational disruption.
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
23 changes
Resolved issues and error corrections
This update corrects an issue in account reports where some report calculations could use the wrong record context. The fix helps ensure financial report values are computed reliably and reduces the risk of incorrect report output.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
Shipping label printing can now use a printer selected for each delivery operation type instead of automatically choosing the first available compatible printer. This helps warehouses route labels to the right printer by default, reducing manual work and printing mistakes.
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. Task: 4792491 Forward-Port-Of: odoo/enterprise#97034 Forward-Port-Of: odoo/enterprise#86818
Customer statement emails sent from a child contact now generate the correct PDF attachment instead of an empty statement. The Customer Statement button is also hidden when there are no transactions or no amount due, reducing confusion for accounting users.
Original PR description
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and…
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and confirm it. 3. Go to the child contact and open the Customer Statement smart button. 4. Download the PDF → data is shown correctly. 5. Send the statement → the attachment in the sent mail is empty. **Issue:** - When sending customer statements via email from a child contact, the generated PDF attachment contains no data, showing empty amounts and transactions. - Additionally, the "Customer Statement" button was still visible even when the total due was zero. **Cause:** - The button visibility condition checks for `total_due == 0.0 and not has_moves`, which didn’t properly cover all use cases. **Solution:** - Update button visibility condition to: `invisible="not has_moves or total_due == 0"` ensuring it is hidden when there are no moves or the total due is zero. **opw-5009182** Forward-Port-Of: odoo/enterprise#96017 Forward-Port-Of: odoo/enterprise#93162
This fix corrects how bank synchronization actions are triggered from the bank journal status area. As a result, customer-facing actions that previously failed to be sent should now work as intended.
Original PR description
The aim of this commit is fixing the usage of doActionButton. In this commit [[1]], we added two usages of doActionButton but it was wrongly done. It means, for a functional POV, that the action is never send to the customer. [1]: https://github.com/odoo/enterprise/commit/379f8bf0d9f55dda1998750fd5cbe48a2d84b00e
This update adds test coverage to ensure Indian GSTR-1 reporting handles sales involving reverse charge tax and SEZ supplies with LUT correctly. It helps reduce the risk of incorrect tax report submissions for businesses operating under these GST scenarios.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931 Forward-Port-Of: odoo/enterprise#95669 Forward-Port-Of: odoo/enterprise#87486
Argentina VAT report exports now generate both required text files for Type C vendor bills and invoices without taxes. This helps businesses meet AFIP filing requirements and avoids incomplete report downloads.
Original PR description
…afip code '0' **Description of the issue/feature this PR addresses:** This PR addresses an issue identified in the generation of .txt files for invoices that utilize AFIP tax code '0' **Current behavior before PR:** The system is only generating one of the two .txt files required by AFIP for specific invoice types. Affected Cases: - Invoices of type 'C'. - Invoices that have no taxes. **Desired behavior after PR is merged:** Two .txt files should be generated for all invoice types, as per AFIP requirements. [HERE](https://app.screencastify.com/watch/2mtioGVxEOwW0rAHJS2v) is a video replicating the issue: 1. In localization Argentina, create a vendor bill type 'C' 2. In 'Tax Return' report, filter by date and 'Tax Type: Purchase' 3. Download .ZIP file and see only one .txt Forward-Port-Of: odoo/enterprise#96052
The AI assistant in the website builder now works correctly when used on product pages. This prevents a "Missing Record" error and lets users continue editing product descriptions without interruption.
Original PR description
__Current behavior before commit:__ Using `/ai` in the website builder sends the record id as a string leading to an error in the backend because `browse` expects an integer as input. __Description of the fix:__ Use `search` instead of `browse` to support id sent as string as well as to validate ACL and existence of the record. __Steps to reproduce the issue on runbot:__ 1. Go to `/shop`. 2. Click on a product. 3. Open the website builder. 4. Enter `/ai` in the description below the product title. => A "Missing Record" error appears. Forward-Port-Of: odoo/enterprise#95163
Shipping label printing through IoT can now use a selected printer for each picking type instead of automatically choosing the first matching printer. If a shipping label or document is printed without a linked IoT printer, users now receive a clear error message instead of a technical traceback.
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#97396 Forward-Port-Of: odoo/enterprise#95794
The Point of Sale settlement flow now handles cases where a previously loaded customer has been removed from the database. This prevents reload errors and helps keep PoS operations running smoothly after customer record cleanup.
Original PR description
Before this commit, if a previously loaded partner was deleted from the database, reloading the PoS would trigger an error because the partner record could no longer be found. opw-5137871 Forward-Port-Of: odoo/enterprise#97173 Forward-Port-Of: odoo/enterprise#96491
The AI live chat website block now behaves more consistently with website themes and editing tools. This improves the visitor experience with cleaner design, better readability, smoother fullscreen behavior, and stronger accessibility support.
Original PR description
Resolve theme options compatibility, editing behavior, accessibility and design problems affecting UX and standards compliance. Adherence to theme options: - Apply border-radius correctly to target…
Resolve theme options compatibility, editing behavior, accessibility and design problems affecting UX and standards compliance. Adherence to theme options: - Apply border-radius correctly to target elements - Fix bg-color applying to text-area instead of intended container Edition: - Remove resize/style options on the column since these are not retained on save - Fix the preview that mismatch with actual rendered result - Resolve title/form misalignment in edit mode - Ensure "OR" text readability across different background colors - Preserve container size when the "fullscreen" feature is activated Accessibility: - Add missing focus state for form fields - Add role="presentation" to icons - Add role="button" to anchor tags functioning as buttons Design: - Reduce oversized title font size - Adjust container width on xl and xxl breakpoints - Smooth fullscreen transition to prevent abrupt activation | 19.0 | this PR | |--------|--------| | <img width="1092" height="424" alt="image" src="https://github.com/user-attachments/assets/5cd85204-b9af-4810-9458-c4c96dad562d" /> | <img width="1083" height="409" alt="image" src="https://github.com/user-attachments/assets/b83f2d18-0135-4f5d-b420-11f58070c8a3" /> | task-5089787 Forward-Port-Of: odoo/enterprise#94767
The General Ledger now shows the Initial Balance line first when using the Load more option. This prevents missing or duplicated ledger entries when users load account lines in smaller batches.
Original PR description
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General…
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General Ledger - Change the Load more limit in the options to a small number, i.e. 4 - Open the General Ledger and unfold an account with more than 10 lines - There is no Initial Balance line, it appears when clicking "Load more" ### Cause: The General Ledger query have this line `ORDER BY 2, move_name, 1`. Here 2 refers to the date and 1to the `account_move_line.id`. But the initial balance line has these columns equal to `NULL` so this ORDER BY will place it at the end of the results. When the limit is smaller than the total number of lines, the initial balance is not fetched by the query. **Additional issue** The limit is incremented several times. In our case, we set the option at 4. It gets incremented [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_report.py#L7172) because the load more option is triggered, and also [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L239) for no apparent reason (it is not needed "for the Initial balance"). So the query is called with `limit=6`, six lines are retrieved when clicking on "Load more". Considering a scenario where there are 10 lines for the account (with the initial balance) and "Load more limit" set to 4: - The first query gets the lines 1-6 but only 1-4 are displayed. - Clicking "Load more", the offset is 4, the query gets the lines 5-10. 10 being the initial balance, it is put in first position by [this piece of code](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L79-L91). So the lines displayed are 10, 5, 6, 7 - Last click on "Load more", offset is 8, query gets 9 and 10, displays 10, 9. In the end, one line is not displayed, and the initial balance is displayed twice. ### Solution: Add `NULLS FIRST` in `ORDER BY` to always have the Initial Balance as the first line returned by the query. Also remove the unnecessary `limit+1`. opw-5105652 Forward-Port-Of: odoo/enterprise#96136
Odoo Studio now avoids saving an invalid link setting when users create a related field pointing to partner child contacts. This prevents crashes during later field updates and keeps customized sales order forms more reliable.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97274 Forward-Port-Of: odoo/enterprise#96950
This fixes an issue in Point of Sale Enterprise that could cause an error when opening Studio from the preparation activity display. The change improves reliability for users customizing or managing the preparation display workflow.
Original PR description
This commit prevents a NewId to be used in a domain when opening studio from the activity display. runbot error #233396 Forward-Port-Of: odoo/enterprise#97332
SAF-T reports now show the required tax payable amount when reverse charge taxes are used, instead of reporting zero. This helps ensure Romanian tax filings match authority expectations and reduces the risk of incorrect compliance reporting.
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
Fixed an issue where opening the AI assistant from a blog record could show an error instead of starting normally. The system now checks for planned activities only when that type of record supports them, preventing disruption for website blog users.
Original PR description
Currently, an error occurs when the user clicks on the AI icon at the top. Steps to Reproduce: - Install the `website_blog` module. - Go to `Website > Configuration > Blog > Blogs`. - Open any `blog`…
Currently, an error occurs when the user clicks on the AI icon at the top. Steps to Reproduce: - Install the `website_blog` module. - Go to `Website > Configuration > Blog > Blogs`. - Open any `blog` and click the `AI icon` at the top. `AttributeError: 'blog.blog' object has no attribute 'activity_ids'` This error occurs after [this commit]. When the user clicks the AI icon, it attempts to create an AI channel and fetch planned activities if any exist. However, the blog.blog model does not have the activity_ids attribute because it does not inherit from mail.activity.mixin. As a result, the error is raised [1]. This commit ensures that the system only checks for activities if the record has the activity_ids attribute; otherwise, it returns empty data, indicating no activities found. [1]- https://github.com/odoo/enterprise/blob/64fa9e46f6195bd4312130cce33b94a129584523/ai/models/mail_thread.py#L12 [this commit]: https://github.com/odoo/enterprise/commit/7333dc779c75479c708edb7ecd1c0a0d4d2ae619 sentry-6942245851 Forward-Port-Of: odoo/enterprise#97136
Project portal users can now use a back button from the shared project Gantt view. This makes navigation easier and reduces friction when moving between shared project information and the portal.
Original PR description
Currently, project portal users cannot easily navigate back from the project portal view.This commit adds a back button in the gantt view of project sharing to improve navigation. Also, the project sharing gantt view is added in this commit- https://github.com/odoo/enterprise/pull/80545/commits/daaea2742a9ee786045ea805941eb3e8374c99d1 task: 5075423 Forward-Port-Of: odoo/enterprise#95461
Fixes a bank reconciliation issue where choosing a write-off account with a default tax could remove an already matched bill or invoice. Users can now add the account without losing existing reconciliation work, reducing manual rework and errors.
Original PR description
In the Bank reconciliation widget, users can click a button to set the account to write off the remaining balance. However, if the chosen account has a default tax set, the widget will lose any existing matches with invoices. Steps to reproduce: - Have an account with a default tax - Create a bill with a total - Create a bank statement for a greater amount - Open the bank reconciliation widget - In the created statement, first add the bill, then click 'Set Account,' and choose the account with tax Issue: Bill matching will be lost. This occurs because we remove and recreate the matching line, but we don't keep the line to be reconciled. opw-5002624 Forward-Port-Of: odoo/enterprise#96006
Spreadsheet pivots now let users drill into related fields even when a dimension is already selected, while still preventing duplicate selections of the exact same dimension. Date and datetime fields can also be selected again with different granularities, making analysis by day, month, or year more flexible.
Original PR description
Before this commit: - Once a dimension (e.g, 'Customer') was selected in a pivot, it could not be used for drilling into related fields, preventing cross-model exploration. - Date and datetime fields could not be re-selected to use different granularities (day, month, year, etc.). After this commit: - The pivot forbids re-selecting the exact same dimension but still allows users to drill and select fields from related models. - Date and datetime fields remain selectable to allow choosing different granularities, improving flexibility in pivot analysis. Task: [5114511](https://www.odoo.com/odoo/2328/tasks/5114511) Forward-Port-Of: odoo/enterprise#95898
Uruguayan electronic invoices now include zero-value lines in the official CFE submission as free delivery items. This prevents missing invoice details when reporting free products, deliveries, or fully discounted lines to the tax authority.
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
This fix removes now-unnecessary extra request details from a database API call after the underlying service was corrected to handle them automatically. It reduces redundant handling in the database synchronization flow without changing expected user-facing behavior.
Original PR description
Since odoo/internal#3823 the `ids` and `context` arguments erroneously became mandatory on the SaaS `/json/2/<__model__>/<__method__>` route, as the override was missing default values. Since odoo/internal#3830 added these default values, there is no need to add these arguments any more, and this commit removes them from the method BaseApi:post_json2 of the databases module. Task-id: none Forward-Port-Of: odoo/enterprise#97098
Creating a vendor bill from an IRN now correctly looks for a purchase journal across all companies in the tax unit, not just the main company. This prevents bill creation failures for multi-company tax units when the main company lacks a purchase journal.
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
This fix ensures several company name and address fields in French VAT report submissions are filled within ASPOne's required length limits. It helps prevent rejected or invalid XML-EDI filings caused by values that are too long.
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
This fix ensures Mexican electronic invoice XML attachments are created with the correct file type even when the user has limited permissions. It prevents related accounting documents from being missed when document centralization is enabled.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97325 Forward-Port-Of: odoo/enterprise#95197
45 changes
Resolved issues and error corrections
This fixes several inventory costing issues so stock values better reflect actual quantities, locations, and recent cost corrections. Businesses should see more reliable FIFO/average cost calculations, valuation reports, and cost of goods sold figures, with expanded tests to reduce future regressions.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Closing a session from a kiosk configuration now behaves like the dashboard Close Session button instead of opening the point of sale interface. This prevents staff from being redirected to the wrong screen and makes kiosk session management more consistent.
Original PR description
Currently when you're on the config of a kiosk, the link `Click here to close the session` opens the session. This was never intended when we have a kiosk. Now, if we have a kiosk, when selecting this link it will close the session the same way it does when selecting the button `Close Session` on the dashboard. opw-5024837
This fix ensures date-based filters are converted using the daylight saving time rules for the date being searched, rather than the current date. This prevents records from being included or excluded incorrectly around seasonal time changes.
Original PR description
Description of the issue/feature this PR addresses:
When casting a date to a datetime during conversion of domains, we should take the DST of the date instead of now.
Current behavior before PR:
`[('dt_field', '>', '2022-01-01')]` uses the DST of now which may or may not be +1h.
Desired behavior after PR is merged:
`[('dt_field', '>', '2022-01-01')]` would use the DST of the given date.
runbot.build.error/232914
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a point-of-sale rental test so it correctly uses an order quantity that remains visible after recent ecommerce payment filtering changes. It helps ensure paid online orders can still be handled reliably in POS workflows without test failures.
Original PR description
Because of https://github.com/odoo/odoo/pull/230809, it will cause the quotations/orders menu to filter out any sale orders which have an unpaid amount of 0. The test_rental_pos test tries to create a sale order with a quantity of 0 and then settle it in the POS, but because of the filter, the sale order will not show up in the menu causing the test to fail. This PR is to increase the quantity in the sale order to 1 so that the order shows up and the test can be executed properly. Task-5138081
The automated click testing tool will now avoid the Attendance onboarding menu because it opens a tablet-focused kiosk screen that the test cannot leave. This prevents false test failures and helps keep backend quality checks stable without changing the experience for regular users.
Original PR description
This commit blacklists the attendance Onboarding menu in clickbot since that menu redirects the user to kiosk app which is a custom app for tablet mode and so the clickbot cannot go back in backend when it enters in the kiosk.
Online orders that were already paid through ecommerce are now recognized correctly when opened in the Point of Sale. The POS will account for the existing payment or hide fully paid orders, helping staff avoid charging customers twice.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5138081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes now-unnecessary extra information from database API calls after the underlying SaaS route was corrected. It reduces redundant handling in the databases module and helps keep synchronization behavior aligned with the platform defaults.
Original PR description
Since odoo/internal#3823 the `ids` and `context` arguments erroneously became mandatory on the SaaS `/json/2/<__model__>/<__method__>` route, as the override was missing default values. Since odoo/internal#3830 added these default values, there is no need to add these arguments any more, and this commit removes them from the method BaseApi:post_json2 of the databases module. Task-id: none
The online store no longer shows an “Undefined” label under a product name when a shopper selects a variant combination that is not available. This keeps product pages cleaner and avoids confusing customers during variant selection.
Original PR description
## Versions
19.0+
## Issue
"Undefined" is displayed under a product' name when selecting an unavailable variant configuration.
## Steps to reproduce
- Activate variants in the Settings' App;
- Create a product with 2 attributes ("A" and "B") and 2 values ("c" and "d") for each attribute;
- Click on the "Configure" button for attribute "A":
- Select the first value:
- Add an exclusion line applied on the same product and value "c" of attribute "B" ("B:c").
- Go to the product's eCommerce page:
- Select the unavailable configuration (A:c and B:c).
## Cause
A condition introduced on line https://github.com/odoo/odoo/blob/609ce29d5232707f7c6d05a7b82909cd3b09c75a/addons/website_sale/views/templates.xml#L2476 relies on `visible_tags` which is not defined because based on `product_variant.all_product_tag_ids` where `product_variant` is empty as the selected variant is archived.
opw-5145405The project setup test now prepares the milestones setting before the guided tour runs. This prevents test results from changing depending on whether demo data is installed, improving reliability without changing normal user workflows.
Original PR description
When running test_01_project_tour, the milestones feature is enabled on one of the projects. When doing so, if the project_milestone global option isn't enabled, it gets enabled automatically. When…
When running test_01_project_tour, the milestones feature is enabled on one of the projects. When doing so, if the project_milestone global option isn't enabled, it gets enabled automatically. When such a global feature is enabled while saving a project, the web client executes a reload_context action (see the onRecordSaved override in `@project/views/project_form/project_project_form_controller`). This is why the tour step that clicked on the save button got an `expectUnloadPage: true` attribute. However, when the demo data are installed, some projects are already created, including projects that have the milestones feature enabled. Therefore, the global option does not get enabled during the tour, and the page does not get reloaded in this case. With this commit, we enable the global option before running the tour, so that the behavior can be consistent between executions on databases where the demo data are or are not installed. Runbot-build-error-id: [232962](https://runbot.odoo.com/odoo/runbot.build.error/232962)
This fixes visual issues in the Mail chat message composer, especially in compact windows and on small screens. Text now aligns better, mention links no longer cause small layout shifts, and the composer stays within the visible screen area.
Original PR description
This commit fixes several HTML composer styling issues: - The HTML composer html did not align vertically with the text area when the chat window is in small UI mode. - The mention/redirect links had a border and causing slight layout shifts when applied to the composer. This is now fixed by using outline instead of border. - The maximum height of the HTML composer was not constrained on small screens, causing it to overflow the screen. This is now fixed by using a max-height relative to the viewport height. task-5022254 after: <img width="435" height="346" alt="image" src="https://github.com/user-attachments/assets/cfd309d6-f6a4-4d7c-8694-2a86504193e7" /> <img width="454" height="782" alt="image" src="https://github.com/user-attachments/assets/6ce924b6-9df7-4831-890d-59ec37ea18c9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mass mailing content now keeps dynamic placeholders in the correct position when a mailing becomes read-only after sending. This prevents unwanted line breaks and restores missing editor styling, so sent emails display as intended.
Original PR description
In editable fields, the Html 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…
In editable fields, the Html 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 editable body 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. -- https://github.com/odoo/odoo/pull/229049 deleted several duplicated styles exclusive to the HTML builder from html_editor:common.scss, which were also present in qweb_plugin.scss. However, the mass_mailing html editor does not take into account this file to determine styles within the editor iframe (nor does it use any plugin in readonly mode.) To fix this, the missing styles are duplicated into mass_mailing, to be used in both editable and readonly modes. task-4852246
The Argentine VAT report export now correctly generates both required AFIP text files for type C invoices and invoices without taxes. This helps businesses submit complete tax reporting files and avoid missing-document issues with AFIP.
Original PR description
…afip code '0' **Description of the issue/feature this PR addresses:** This PR addresses an issue identified in the generation of .txt files for invoices that utilize AFIP tax code '0' **Current behavior before PR:** The system is only generating one of the two .txt files required by AFIP for specific invoice types. Affected Cases: - Invoices of type 'C'. - Invoices that have no taxes. **Desired behavior after PR is merged:** Two .txt files should be generated for all invoice types, as per AFIP requirements. [HERE](https://app.screencastify.com/watch/2mtioGVxEOwW0rAHJS2v) is a video replicating the issue: 1. In localization Argentina, create a vendor bill type 'C' 2. In 'Tax Return' report, filter by date and 'Tax Type: Purchase' 3. Download .ZIP file and see only one .txt Forward-Port-Of: odoo/enterprise#96052
The General Ledger now keeps the Initial Balance line at the top when users load account entries in smaller batches. This prevents missing or duplicated ledger lines and gives finance teams a complete, correctly ordered view of account activity.
Original PR description
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General…
### Issue: The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option ### Steps to reproduce: - Accounting > Configuration > Accounting Reports > General Ledger - Change the Load more limit in the options to a small number, i.e. 4 - Open the General Ledger and unfold an account with more than 10 lines - There is no Initial Balance line, it appears when clicking "Load more" ### Cause: The General Ledger query have this line `ORDER BY 2, move_name, 1`. Here 2 refers to the date and 1to the `account_move_line.id`. But the initial balance line has these columns equal to `NULL` so this ORDER BY will place it at the end of the results. When the limit is smaller than the total number of lines, the initial balance is not fetched by the query. **Additional issue** The limit is incremented several times. In our case, we set the option at 4. It gets incremented [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_report.py#L7172) because the load more option is triggered, and also [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L239) for no apparent reason (it is not needed "for the Initial balance"). So the query is called with `limit=6`, six lines are retrieved when clicking on "Load more". Considering a scenario where there are 10 lines for the account (with the initial balance) and "Load more limit" set to 4: - The first query gets the lines 1-6 but only 1-4 are displayed. - Clicking "Load more", the offset is 4, the query gets the lines 5-10. 10 being the initial balance, it is put in first position by [this piece of code](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L79-L91). So the lines displayed are 10, 5, 6, 7 - Last click on "Load more", offset is 8, query gets 9 and 10, displays 10, 9. In the end, one line is not displayed, and the initial balance is displayed twice. ### Solution: Add `NULLS FIRST` in `ORDER BY` to always have the Initial Balance as the first line returned by the query. Also remove the unnecessary `limit+1`. opw-5105652 Forward-Port-Of: odoo/enterprise#96136
Gift Card and E-Wallet products now appear in the Point of Sale even when the store is limited to selected product categories. This ensures staff can consistently sell these payment-related products without extra category setup.
Original PR description
Before this commit: =================== If the PoS configuration is restricted to specific categories, but the Gift Card and E-Wallet products do not have any category assigned, these products will not be visible in the PoS UI. After this commit: ==================== Gift Card and E-Wallet products are now always visible in the PoS UI, regardless of whether a PoS category is assigned or not. Purpose: ============ Gift Card and E-Wallet products should always be available for sale in the PoS. This ensures they can be sold physically from the PoS UI without requiring category assignment. Task-5103770 Forward-Port-Of: odoo/odoo#231626 Forward-Port-Of: odoo/odoo#228395
Electronic payments registered from an invoice will now keep the payment transaction connected to that invoice. This improves payment traceability and helps users see the full invoice-to-payment relationship correctly.
Original PR description
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the…
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the issue/feature this PR addresses: **The payment transaction was not being linked to the invoice for electronic payments.** To resolve this, I passed the current invoice IDs as context through action_register_payment in the account.move.line model. Then, I retrieved this context value in _prepare_payment_transaction_vals of the account.payment model to set the invoice_ids Many2many field. Current behavior before PR: The payment transaction is not linked to the invoice for electronic payments. Desired behavior after PR is merged: The payment transaction will be correctly linked to the invoice for electronic payments. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208520 Forward-Port-Of: odoo/odoo#197091
The Point of Sale due settlement flow now handles cases where a previously loaded customer has been deleted. This prevents reload errors and helps keep checkout and payment follow-up workflows running smoothly.
Original PR description
Before this commit, if a previously loaded partner was deleted from the database, reloading the PoS would trigger an error because the partner record could no longer be found. opw-5137871 Forward-Port-Of: odoo/enterprise#97173 Forward-Port-Of: odoo/enterprise#96491
The date picker now clearly shows when a date option is disabled and cannot be selected. This reduces confusion for users by making unavailable dates visually distinct after a previous interface change removed the default disabled styling.
Original PR description
In this commit fa3bfb0a696c20ae51cd0f37f737fcf211007c4a, the o_date_item_cell was changed from a button to a div. This made the style of disabled cells not show that its not unclickable, making it confusing for users. Solution is to add specific style for the disbaled o_date_item_cell component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231562 Forward-Port-Of: odoo/odoo#231249
This fixes an issue in Odoo Studio where creating a related field to a contact’s child records could save incorrect relationship settings. The change prevents crashes during later form updates, making Studio-created customizations safer and more reliable.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97274 Forward-Port-Of: odoo/enterprise#96950
This fix restores a safer way for Odoo to identify manually created field names while avoiding unnecessary system work. It helps keep custom field behavior reliable without adding performance overhead.
Original PR description
The use of IrModelFields method `is_manual_name` was [reverted](https://github.com/odoo/odoo/pull/212579) for the sake of efficiency and avoiding instanciating models when not really needed. The use of an overridable method is still needed ([reference](https://github.com/odoo/odoo/pull/145154)). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224524
Fixes an issue where opening the website editor on the login page incorrectly marked the form as changed. This prevents confusion for editors by avoiding a false unsaved-change state, with no impact on normal visitor login behavior.
Original PR description
Before this commit, part of the `/web/login` page was immediately marked as dirty when the editor opened. This happened because `UserSwitch` component used a `t-portal` directive that rendered an element outside the `owl-component` tag, causing it to be tracked by the mutation observer. After this commit, the `t-portal` directive is ignored when in edit mode. A side effect of this solution is that the "Choose a user" button is hidden during editing, but this button was already non-editable and non-clickable during edit. **How to reproduce the problem** 1. Navigate to "/web/login" 2. Activate edit mode 3. The "o_dirty" class is present in the login form Forward-Port-Of: odoo/odoo#230602
Users can now create their first timesheet even if they do not have access to the company’s internal project. The system avoids selecting a project they cannot access by default, preventing an error and allowing the timesheet process to continue.
Original PR description
To reproduce: ============= - make the internal project of the company for invited internal users only - with internal user that doesn't have access to the internal project, and no previous timesheet created, try to create a timesheet - you get a traceback Problem: ======== when not having a previous timesheet, in the default value we set project_id based on the internal project of the company. But if the user doesn't have access to this project, it raises an access error. Solution: ========= check if the user has access to the internal project of the company, if not, use `False` as default value. opw-5119839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229818
This update prevents a timing issue that could cause Odoo Discuss calls to fail while a peer-to-peer connection offer is being processed. It improves call reliability by ensuring delayed responses no longer use outdated connection information.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/205198, the handling of an offer can be arbitrarily delayed by the `acceptOffer` callback. This could lead to a traceback when the reference to `peer` is stale by the time the event is handled. Forward-Port-Of: odoo/odoo#231620
Checkout progress labels are now translated correctly when shoppers use a website in another language. This improves the checkout experience for multilingual stores by avoiding English-only step names.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a website; 2. enable a new language (other than English); 3. use website in this language; 4. go to checkout. Issue ----- The checkout steps on the top-left aren't translated. Cause ----- Commit dbd22d93183f2 added the `website.checkout.step` model. Like `website.menu`, they have a default record that gets set on initialization, which is then gets used to create a new record per website. The issue is that when enabling a new language, it only translates the default records. The records that are website-specific remain unchanged. Solution -------- Because they function the same we as `website.menu`, we can use the same approach that was taken to translate website menus, and add a `_load_module_terms` override to `ir.module.module`, constructing a SQL query that copies the translations from the default records to the website-specific records. opw-4985676 Forward-Port-Of: odoo/odoo#223019
The sale product configurator now uses screen space better on mobile when optional products include custom attribute fields. This keeps the text input and cart button easier to view and use, reducing friction for shoppers on smaller screens.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a product attribute with a single custom value; 2. add the attribute to a product A; 3. set product A as an optional product of product B; 4. go to product B's product page in mobile view; 5. click on the cart button. Issue ----- The custom text field takes up way too much real estate. Cause ----- The template isn't fully adapted for mobile view. Solution -------- Change `d-flex` to `d-lg-flex` on the `ptal` element, making the attribute name & input online display in-line on large screens. Additionally, change some bootstrap classes to also have the cart button button displayed within the screen. opw-5114495 Forward-Port-Of: odoo/odoo#231744 Forward-Port-Of: odoo/odoo#230743
This fixes an issue that prevented certain related list-style fields from being created when no matching inverse link existed. It improves reliability for custom data models and reduces setup blockers for configurations that rely on related records.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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#231720 Forward-Port-Of: odoo/odoo#231187
Spreadsheet pivots now let users explore related fields from dimensions they have already selected, while still preventing exact duplicates. Date fields can also be reused with different time groupings, making analysis more flexible and reducing blocked reporting workflows.
Original PR description
Before this commit: - Once a dimension (e.g, 'Customer') was selected in a pivot, it could not be used for drilling into related fields, preventing cross-model exploration. - Date and datetime fields could not be re-selected to use different granularities (day, month, year, etc.). After this commit: - The pivot forbids re-selecting the exact same dimension but still allows users to drill and select fields from related models. - Date and datetime fields remain selectable to allow choosing different granularities, improving flexibility in pivot analysis. Task: [5114511](https://www.odoo.com/odoo/2328/tasks/5114511)
Point of Sale session names now stay continuous when saving cash details fails. This prevents confusing gaps in session numbering and makes session records easier to track and audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. opw-5100163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230007 Forward-Port-Of: odoo/odoo#229532
This update fixes an issue where changing text color in the HTML editor could accidentally recolor a larger surrounding section when an icon was nearby. Users can now apply colors more precisely to their selected content, reducing unexpected formatting changes.
Original PR description
After this [commit], we'd have an issue when we tried to change a color and there was an `fa` icon next to our selection. Instead of changing the color of only the selection it would change it for the closest element with `color`, `background-color`, or `background-image` style properties. To reproduce the bug: - Set selection on an element that has a color style property on its parent, and the parent has .fa icon but not directly on our element - Try to change its color => Color of the whole parent changes task-5107147 [commit]: https://github.com/odoo/odoo/commit/927f4b973932d14961c148e13473017651a60dc0 Forward-Port-Of: odoo/odoo#231490 Forward-Port-Of: odoo/odoo#229311
This fix prevents an internal temporary record reference from being used when opening Studio from the activity display in Point of Sale. It helps avoid a runbot error and improves reliability for users configuring or reviewing preparation displays.
Original PR description
This commit prevents a NewId to be used in a domain when opening studio from the activity display. runbot error #233396 Forward-Port-Of: odoo/enterprise#97332
This update corrects how hierarchy-based searches work when some related records are not directly accessible to the current user. It helps ensure business data queries return the expected results while still respecting access rules.
Original PR description
We introduced a regression in https://github.com/odoo/odoo/pull/170009 for 'child_of'/'parent_of' operators on relational fields: With a domain leaf like `[('X2X', 'child_of', ids)]` where the X2X comodel has `_parent_store=True`, we don't take into account inaccessible children from the current user. That's incorrect, and we already fixed this behavior in ae038904face6766d93695dcaa9b07346d05282a, but the test added targeted 'res.partner' which has `_parent_store=False`.
Fix it by using a `_search()` on the sudoed comodel instead of the 'any' operator. In 19.0 we should use 'any!' operator instead.
Forward-Port-Of: odoo/odoo#231540
Forward-Port-Of: odoo/odoo#231458This fix ensures Mexican electronic invoice XML files are created with the correct file type even when the user lacks certain technical permissions. It prevents related accounting documents from being missed when document centralization is enabled, improving reliability for accounting workflows.
Original PR description
When creating an XML attachment as a user without Write access on the ir.ui.view model, the Mimetype will be set to plain/text. In particular, this causes issues when Accounting centralization is enabled in Documents, as the corresponding Document will only be generated if the Mimetype is application/xml. Creating the XML as Superuser avoids this issue. Similar to https://github.com/odoo/odoo/pull/124507 opw-5057038 Forward-Port-Of: odoo/enterprise#97258 Forward-Port-Of: odoo/enterprise#95197
Manufacturing order validation now handles cases where no finished move lines exist. This prevents unexpected crashes when posting labor costs from work orders, helping production teams complete validations more reliably.
Original PR description
In some cases, a Manufacturing Order may not have any finished move lines. When posting labor costs from work orders, it tries to access the first finished move in order to retrieve its account. If no finished move exists, this leads to a traceback at MO validation. This commit ensures a proper fallback account is used when no finished moves are linked to the MO, avoiding unexpected crashes. opw-4858696 opw-5066266 Forward-Port-Of: odoo/odoo#229339
Tooltip text in live chat, mail, point of sale, and web screens is now included in translation handling. This helps users see helpful on-screen hints in their selected language instead of untranslated text.
Original PR description
Unless you tell Owl to do so, custom attributes like data-tooltip aren't translated. This commit adds the data-tooltip attribute to the list of translated attributes when missing. *: im_livechat, mail, point_of_sale, web Forward-Port-Of: odoo/odoo#231541 Forward-Port-Of: odoo/odoo#231006
SAF-T exports now report the tax payable amount correctly when reverse charge taxes are used, instead of showing zero. This helps Romanian tax reporting match authority expectations and reduces the risk of incorrect declarations.
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 Payroll app no longer shows a payslip export button that led users to a missing page. This prevents confusion and avoids a 404 error when viewing payslips in debug/superuser 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
This update ensures accounting localization tests always include demo data when they run. It keeps test behavior consistent across versions and helps reduce avoidable test failures without affecting day-to-day users.
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
The website SEO Auto-Fill action now works correctly on system pages such as login, signup, password reset, and donation payment pages. This prevents users from seeing an error when optimizing these pages and allows required 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 import screen now correctly handles cases where users are offered more than one sample import template. This prevents a page crash and slightly improves the layout of the template download buttons.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.
Forward-Port-Of: odoo/odoo#231715
Forward-Port-Of: odoo/odoo#231407The Belgian payroll salary configurator now checks the active company before applying Belgian-specific salary calculations. This prevents incorrect handling in other company contexts and ensures the gross salary is shown where expected.
Original PR description
Gross Salary did not appear previously as the extending function _get_compute_results in 10n_be_hr_contract_salary was returning the l10n_be_wage_with_mobility_budget right away without checking which company we are in. This change made sure before proceeding that we are in the correct active company, Belgian one in our case. task-4987491 Forward-Port-Of: odoo/enterprise#96678 Forward-Port-Of: odoo/enterprise#94905
Posting vendor bills now correctly keeps and creates analytic items when analytic accounts are set, even when journal auto-checking is disabled or lock dates apply. This prevents missing analytic reporting data and helps businesses keep cost tracking accurate.
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
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 notifications directly from technical settings when needed.
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
Uruguayan electronic invoices now include invoice lines that have a zero total, such as free delivery or fully discounted items. This ensures these lines are properly reported to the tax authority as free delivery, avoiding missing information 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 French VAT report export now fills key company name and address fields using the exact length limits required by ASPOne. This helps prevent rejected electronic filings caused by values that are too long or incorrectly placed.
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
This fix stops certain document-related attachments from being automatically uploaded to cloud storage. It helps ensure attachments that are needed by business document processes remain handled locally as expected, reducing the risk of workflow disruptions.
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
When creating a vendor bill from an IRN in an Indian GST tax unit, the system now looks across all companies in the tax unit for a valid purchase journal. This prevents bill creation failures when the main company does not have its own purchase journal configured.
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
4 changes
Resolved issues and error corrections
The project sharing customer preview now follows the same timesheet visibility rules as the actual portal. This prevents non-validated timesheets from appearing in previews when invoicing is limited to validated timesheets, reducing confusion for customers and staff.
Original PR description
Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. To reproduce: Cause: Fix: opw-5155281
The project sharing customer preview now matches the real portal view when billing is based only on validated timesheets. This prevents customers and staff from seeing draft or unapproved time entries in the preview, reducing confusion around billable work.
Original PR description
Issue: Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only. To reproduce: Cause: Fix: opw-5155281 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
Vendor bills now correctly create and retain analytic items when posted, even if Auto-check on Post is turned off for the journal. This ensures accounting analytics remain complete and reliable for cost tracking and reporting.
Original PR description
**Issue** When unchecking the *Auto-check on Post* option on a vendor bill journal, analytic items are not created when posting the invoice, even if analytic accounts were set on the bill lines.…
**Issue**
When unchecking the *Auto-check on Post* option on a vendor bill journal, analytic items are not created when posting the invoice, even if analytic accounts were set on the bill lines.
**Steps to Reproduce**
1. Navigate to *Accounting > Configuration > Journals > Vendor Bills*
2. Uncheck *Auto-Check on Post*
3. Activate *Analytic Accounting* in settings
4. Create a vendor bill with one line and set analytic accounts
5. Post the entry
6. Navigate to *Accounting > Accounting > Analytic Items*
7. No analytic items are created
**Root Cause**
When `autocheck_on_post` is disabled, the `account.move` is still in draft during the `write({'state': 'posted'})` call. In `account.move.line.write`, the following logic runs:
```python
if not self.env.context.get('skip_analytic_sync'):
self.filtered(lambda l: l.parent_state == 'draft').analytic_line_ids.with_context(skip_analytic_sync=True).unlink()
```
At this point, analytic lines were already created, but since the parent move is still in draft, they get incorrectly unlinked. This leads to posted vendor bills without analytic items.
**Fix**
Introduce a posting_move context flag when posting moves. Skip the unlinking of analytic lines if the move is in the process of posting (context.get('posting_move')). This prevents the accidental removal of freshly created analytic lines.
Opw-5053179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Odoo from crashing when Documents references activities linked to records that have since been deleted, such as CRM leads. It improves reliability by handling missing records correctly instead of showing an error to users.
Original PR description
**Steps to reproduce:**
- Install `crm` and `documents`
- Go to CRM → Activity Types
- Set a 'folder' in the `Upload Document` activity
- Create a CRM lead and schedule an upload document activity
- Delete the created lead
- Open the Documents module
**Issue:**
- A `traceback` occurs because web_read tries to access all active records by `values_by_id[record.id]`, but some records are missing from values_list after `read_format` method filters out records with missing values.
- https://github.com/odoo/odoo/blob/3c62ca1eb96d571b2b686b5caee370324c589ab4/odoo/models.py#L3347-L3356
**Solution:**
- Use values_by_id.get(record.id, {}) to safely fetch values and avoid the KeyError.
opw-50801822 changes
Resolved issues and error corrections
PayPal payments can now proceed for invoices in Chinese yuan where PayPal supports this currency. This prevents blocked invoice payments and better aligns Odoo's PayPal currency handling with PayPal's current rules.
Original PR description
## Versions 17.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
17.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893This fix ensures Swiss payroll ELM transmission employee views behave correctly when payroll is used across multiple companies or countries. It helps prevent confusion or incorrect field visibility for businesses managing Swiss payroll in broader company setups.
Original PR description
task-5159023