Daily updates from Odoo
Navigate
Branch
Saturday, April 4, 2026
86 changes
19 changes
New functionality added to Odoo
This update adds a visual icon for the Lazada module within the Odoo Enterprise platform. This improves the user experience by clearly identifying the Lazada integration and making it easier to find within the application's navigation.
Original PR description
Add Lazada icon to the module Forward-Port-Of: odoo/enterprise#105010
This update adds missing modules to the Weblate translation configuration file (.weblate.json). Weblate is the platform used to manage translations across Odoo's interface. By adding these modules to the configuration, they become available for community translators to contribute translations in multiple languages, improving the software's accessibility worldwide.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#257653 Forward-Port-Of: odoo/odoo#254667
Resolved issues and error corrections
This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly interpreted, leading to potential errors in reconciliation reports. The change introduces a new function to intelligently parse these amounts, ensuring accurate calculations and reporting. This improves the reliability of financial data.
Original PR description
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
Examples:
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.
Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)
task-6026748
Forward-Port-Of: odoo/enterprise#110410This update corrects a technical issue in the l10n_be_intervat module, ensuring it aligns with a recent change in Odoo's configuration system. Specifically, the module now uses the correct method (get_str) for retrieving configuration parameters, improving stability and compatibility with the latest Odoo version (19.2).
Original PR description
Since 19.1, ir.config_parameter.get_param is replaced by get_str. This commit fix a mistake I made in the forward port of https://github.com/odoo/enterprise/pull/112719 no-task Forward-Port-Of: odoo/enterprise#112979
This update clarifies how the system handles electronic invoices from Uruguay. Specifically, it prevents ‘e-Cobranza’ documents (which are more like receipts) from being incorrectly synchronized as vendor bills. This ensures data consistency and aligns with how other related documents are processed.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This change updates URLs used for testing Wise direct deposit integrations to reflect Wise's upcoming domain change from sandbox.transferwise.tech to wise-sandbox.com. This ensures continued functionality of the sandbox environment and avoids disruptions to payment testing. Users may need to create a new sandbox account, but the impact is expected to be minimal.
Original PR description
Wise is deprecating their legacy sandbox (sandbox.transferwise.tech) in June 2026. Replace all sandbox URLs with the new wise-sandbox.com domain to avoid breaking test/sandbox payment flows. - API: api.sandbox.transferwise.tech → api.wise-sandbox.com - Portal: sandbox.transferwise.tech → wise-sandbox.com Note: API keys from the legacy sandbox are not transferable to the new environment. Affected users will need to create a new sandbox account, though the impact should be minimal as most customers do not actively use the sandbox. task-6074132 Forward-Port-Of: odoo/enterprise#112921
This update resolves an issue where the 'Edit Properties' button was unresponsive in the project dashboard. The fix ensures that this button only appears when relevant, streamlining the user experience for managing project database settings. This improves usability for users configuring their project KPIs.
Original PR description
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit…
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit Properties` does nothing. Root cause: --- - The `Edit Properties` action appears whenever a properties field is present in the view. - Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]). - Here at [2], the field is added in `edit_project` view. - However, the field is only visible when `database_hosting` is set, and its value is different from `other`. Solution: --- - Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`. [1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36 [2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158 Note: --- - Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing. We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only. opw-5933007 --- Forward-Port-Of: odoo/enterprise#108056
This update fixes an issue where incorrect DTE (Digital Tax Document) XML files received by the system were automatically generating invoices. The fix reintroduces a check to discard these invalid DTEs, preventing the creation of unnecessary invoices and ensuring data accuracy. This improves the reliability of the purchase journal.
Original PR description
A supplier DTE xml should be discard when being fetched by a DTE incoming server if it has the wrong document type, meaning no account move should be created from it. Steps: - Have purchase journal using documents - Setup an incoming mail server, with DTE option enable, with email address X - Send an email to X with a supplier DTE xml of type 52 (TipoDTE element) - Fetch mails from the incoming server -> a bill has been generated and filled, it shouldn't Cause: The check on document type has been removed with the refactor 42744fcecdbd36ea0101070c68299227a9f204a6 Fix: Reintroduce the check in `_process_incoming_supplier_document` before creating any record opw-5978959 Forward-Port-Of: odoo/enterprise#112877
This pull request addresses inconsistencies in our language files by adding missing module references to the .weblate.json files. This ensures accurate translations are available for all Odoo Enterprise modules, improving the user experience for international customers. It's a routine maintenance task to maintain consistent localization.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#113022 Forward-Port-Of: odoo/enterprise#111141
This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change ensures correct equity reporting for Swiss GAAP compliance. The change improves the accuracy of financial reporting.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108
Forward-Port-Of: odoo/enterprise#111302This update improves how the "My Team" filter works in Live Chat agent reports. Instead of grouping by department, the system now uses a manager-based hierarchy to show each agent their own records plus records of employees they directly manage. This provides a more accurate and intuitive view of team performance data.
Original PR description
Replace the department-based domain with a hierarchy-based domain. The new filter includes the current user's records and the records of employees whose manager is the current user. follow-up of https://github.com/odoo/odoo/pull/253567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257548
A thin line was appearing on the Bold 10 shape when used in website banners, depending on padding, size, and screen resolution. This fix adds an overlap adjustment to the shape to eliminate the unwanted visual glitch and ensure a clean appearance across different configurations.
Original PR description
Steps to reproduce: - Enter website edit mode - Insert `s_banner_connected` snippet - Add "Bold 10" shape (`19.svg`) - Depending on padding, size, resolution etc. a thin line appears This commit adds an overlap to fix the apparition of the line. | Before | After | |--------|--------| | <img width="1919" height="861" alt="image" src="https://github.com/user-attachments/assets/06ecf9c4-f9d8-44bd-b48f-a3d8f559d973" /> | <img width="1918" height="847" alt="image" src="https://github.com/user-attachments/assets/1bda5da4-53f4-4105-9af2-06a57da67d0a" /> | Forward-Port-Of: odoo/odoo#257616
This fix prevents files from becoming orphaned when an error occurs during file upload. Previously, if a file write operation failed (due to disk space or permission issues), the system wouldn't clean up the incomplete file, causing it to take up disk space and block future uploads of the same file. Now the system properly marks files for cleanup before attempting to write them, ensuring failed uploads don't leave behind problematic files.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This fix resolves a problem where copying and pasting text in the website builder was incorrectly creating paragraph elements in areas that shouldn't contain them, such as buttons and footer text. The fix allows inline elements to remain inline in these special areas instead of being wrapped in paragraph tags, improving the editing experience and preventing unwanted formatting changes.
Original PR description
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p`…
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements). This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource. This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements. Steps to reproduce: - Open website builder on a product page - Select text in "Add to cart" button - Copy - Paste - Bug: a `p` element is created (on master) - Open website builder - Select "Company" below footer - Copy - Paste - Bug: a `p` element is created [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5868460 Forward-Port-Of: odoo/odoo#257512 Forward-Port-Of: odoo/odoo#247231
This fix resolves a problem where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates the required order identifier when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix ensures that when users send multiple Request for Quotations (RFQs) using the bulk "Send by mail" action, the RFQ status is automatically updated to "Sent" - just like it does when sending individually from the form view. Previously, RFQs would remain marked as "Draft" even after being emailed, causing confusion and requiring users to resend them to update the status.
Original PR description
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them…
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users. Steps to Reproduce: ======================= - Install the `Purchase` app. - Go to Purchase and select multiple RFQs in the list view. - Click `Send by mail` from the actions menu. - Select the RFQ email template and send the email. - Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view. Cause of the issue: ======================= The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated After This Commit: ======================= When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state. TaskID-5443248 Forward-Port-Of: odoo/odoo#243050
This fix resolves a crash that occurred in Point of Sale when scanning GS1-formatted barcodes for products with variants (configurable products). The system was incorrectly trying to process lot numbers as product barcodes, causing the application to fail. The fix ensures the correct product information is passed through the system so scanning works smoothly for inventory-tracked items with variants.
Original PR description
**Steps to reproduce:** * Install `point_of_sale` module. * Go to Settings: * Enable Lots & Serial Numbers. * Enable Variants. * Set Barcode Nomenclature to Default GS1 Nomenclature. * Create a…
**Steps to reproduce:**
* Install `point_of_sale` module.
* Go to Settings:
* Enable Lots & Serial Numbers.
* Enable Variants.
* Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
* Enable Track Inventory set to By Lots.
* Under Attributes & Variants:
* Add an attribute with two values and save.
* Generate product variants:
* Open one variant and set barcode to 5123648695416.
* Update inventory:
* Go to the main product (template).
* Update On Hand Quantity:
* Update On Hand Quantity with a lot/serial number:
010512364869541610784512.
* Select the variant with the defined barcode.
* Under Point of Sale tab:
* Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.
**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
*TypeError: Cannot read properties of undefined (reading
'product_template_attribute_value_ids')*.
**Cause:**
[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│ • product = await _getProductByBarcode(productBarcode) ✅ found
│ • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│ ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│ • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│ • calls openConfigurator(productTemplate, { ...opts })
│ opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
• opts.code = lotBarcode → truthy → enters if(opts.code) branch
• getBy("barcode", opts.code.base_code)
• getBy("barcode", "784512") ← "784512" is a LOT number, not a product barcode!
→ returns undefined ❌
• product packaging lookup also fails → undefined ❌
• product = undefined
│
└─ attributeLinesValues.map(values =>
values.filter(value =>
product.product_template_attribute_value_ids.includes(value)
^^^^^^^ undefined → 💥 TypeError
**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
instead.
---
opw-6031909
Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572This update fixes three critical errors in Polish e-invoice (FA3) file generation: corrects a tax code from 'zw' to '5' for 5% tax rates, ensures invoice amounts are calculated in the correct currency rather than always in PLN, and fixes currency exchange rate calculations to use the correct direction. These fixes ensure e-invoices submitted through KSeF are generated with accurate tax codes, amounts, and exchange rates.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
This update improves how the system reports errors when email templates fail to render. Instead of showing entire template code in error messages and logs, it now displays only relevant snippets while identifying which template caused the problem. This reduces unnecessary log clutter and makes it easier for support teams to diagnose and fix template issues.
Original PR description
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a…
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257359 Forward-Port-Of: odoo/odoo#257104
15 changes
New functionality added to Odoo
This update adds a visual icon for the Lazada module within Odoo. This improves the user experience by clearly identifying the Lazada integration and making it easier to find within the application's module list. It's a simple cosmetic enhancement.
Original PR description
Add Lazada icon to the module Forward-Port-Of: odoo/enterprise#105010
Enhancements to existing features
This update improves how the system handles errors when email templates fail to render. Instead of logging massive amounts of template code, the system now shows just the essential information (template name and a small snippet of the problematic code), making it much easier for support teams and administrators to identify and fix issues without cluttering server logs.
Original PR description
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a…
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257359 Forward-Port-Of: odoo/odoo#257104
Resolved issues and error corrections
This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly interpreted, leading to inaccurate reconciliation reports. A new function has been added to correctly parse these amounts, ensuring data integrity in financial reporting. This improves the reliability of our reconciliation processes.
Original PR description
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
Examples:
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.
Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)
task-6026748
Forward-Port-Of: odoo/enterprise#110410This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how other related documents like ‘e-Remito’ and ‘e-Resguardos’ are handled, ensuring data consistency and accuracy.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This change updates URLs used for testing Wise direct deposit integrations to reflect Wise's upcoming domain change. Replacing the old sandbox URLs prevents disruptions to testing and sandbox payment flows. Users may need to create a new sandbox account, but the impact is expected to be minimal.
Original PR description
Wise is deprecating their legacy sandbox (sandbox.transferwise.tech) in June 2026. Replace all sandbox URLs with the new wise-sandbox.com domain to avoid breaking test/sandbox payment flows. - API: api.sandbox.transferwise.tech → api.wise-sandbox.com - Portal: sandbox.transferwise.tech → wise-sandbox.com Note: API keys from the legacy sandbox are not transferable to the new environment. Affected users will need to create a new sandbox account, though the impact should be minimal as most customers do not actively use the sandbox. task-6074132 Forward-Port-Of: odoo/enterprise#112921
This update resolves an issue where the 'Edit Properties' button was unresponsive in the project settings. The fix ensures that this button is only displayed when relevant data is present, streamlining the user experience for managing database properties. This improves usability for users configuring their projects.
Original PR description
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit…
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit Properties` does nothing. Root cause: --- - The `Edit Properties` action appears whenever a properties field is present in the view. - Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]). - Here at [2], the field is added in `edit_project` view. - However, the field is only visible when `database_hosting` is set, and its value is different from `other`. Solution: --- - Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`. [1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36 [2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158 Note: --- - Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing. We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only. opw-5933007 --- Forward-Port-Of: odoo/enterprise#108056
This update fixes an issue where incorrect DTE (Digital Tax Document) XML files received by the system were causing the creation of unnecessary invoices. The system now automatically discards these invalid DTEs, preventing incorrect data from being processed and ensuring accurate accounting. This improves data integrity and reduces potential errors.
Original PR description
A supplier DTE xml should be discard when being fetched by a DTE incoming server if it has the wrong document type, meaning no account move should be created from it. Steps: - Have purchase journal using documents - Setup an incoming mail server, with DTE option enable, with email address X - Send an email to X with a supplier DTE xml of type 52 (TipoDTE element) - Fetch mails from the incoming server -> a bill has been generated and filled, it shouldn't Cause: The check on document type has been removed with the refactor 42744fcecdbd36ea0101070c68299227a9f204a6 Fix: Reintroduce the check in `_process_incoming_supplier_document` before creating any record opw-5978959 Forward-Port-Of: odoo/enterprise#112877
This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change ensures correct reporting of equity balances for Swiss companies. It's a necessary correction to improve financial reporting accuracy.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108
Forward-Port-Of: odoo/enterprise#111302A thin line was appearing on the Bold 10 shape when used in website banners, depending on padding, size, and screen resolution. This fix adds an overlap adjustment to the shape to eliminate the unwanted line and improve the visual appearance of websites using this design element.
Original PR description
Steps to reproduce: - Enter website edit mode - Insert `s_banner_connected` snippet - Add "Bold 10" shape (`19.svg`) - Depending on padding, size, resolution etc. a thin line appears This commit adds an overlap to fix the apparition of the line. | Before | After | |--------|--------| | <img width="1919" height="861" alt="image" src="https://github.com/user-attachments/assets/06ecf9c4-f9d8-44bd-b48f-a3d8f559d973" /> | <img width="1918" height="847" alt="image" src="https://github.com/user-attachments/assets/1bda5da4-53f4-4105-9af2-06a57da67d0a" /> | Forward-Port-Of: odoo/odoo#257616
This fix prevents files from becoming orphaned when an error occurs during file upload. Previously, if a file write operation failed (such as due to disk space issues), the system wouldn't clean up the incomplete file, causing storage waste and blocking future uploads of the same file. Now files are properly marked for cleanup before the write operation begins, ensuring they're removed if something goes wrong.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This fix resolves a problem where copying and pasting text in certain website builder elements (like buttons and footer text) was incorrectly adding paragraph formatting. The editor now properly handles inline elements without wrapping them in unwanted paragraph tags, making the editing experience more intuitive and preventing unintended formatting changes.
Original PR description
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p`…
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements). This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource. This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements. Steps to reproduce: - Open website builder on a product page - Select text in "Add to cart" button - Copy - Paste - Bug: a `p` element is created (on master) - Open website builder - Select "Company" below footer - Copy - Paste - Bug: a `p` element is created [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5868460 Forward-Port-Of: odoo/odoo#257512 Forward-Port-Of: odoo/odoo#247231
This update improves how the "My Team" filter works in Live Chat agent reports. Instead of grouping by department, the system now uses a manager-based hierarchy, showing each agent their own records plus records of employees they directly manage. This provides a more accurate and intuitive view of team performance data.
Original PR description
Replace the department-based domain with a hierarchy-based domain. The new filter includes the current user's records and the records of employees whose manager is the current user. follow-up of https://github.com/odoo/odoo/pull/253567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257548
This fix resolves an issue where POS orders created in Jordan before installing the electronic invoicing module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates these identifiers when needed, ensuring all orders can be successfully submitted to the tax authority.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix resolves a crash that occurred in the Point of Sale system when scanning GS1-formatted barcodes for products with variants. The issue happened because the system was incorrectly trying to look up lot numbers as product barcodes, causing the application to fail. The fix ensures the correct product information is passed through the system so variant selection works properly.
Original PR description
**Steps to reproduce:** * Install `point_of_sale` module. * Go to Settings: * Enable Lots & Serial Numbers. * Enable Variants. * Set Barcode Nomenclature to Default GS1 Nomenclature. * Create a…
**Steps to reproduce:**
* Install `point_of_sale` module.
* Go to Settings:
* Enable Lots & Serial Numbers.
* Enable Variants.
* Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
* Enable Track Inventory set to By Lots.
* Under Attributes & Variants:
* Add an attribute with two values and save.
* Generate product variants:
* Open one variant and set barcode to 5123648695416.
* Update inventory:
* Go to the main product (template).
* Update On Hand Quantity:
* Update On Hand Quantity with a lot/serial number:
010512364869541610784512.
* Select the variant with the defined barcode.
* Under Point of Sale tab:
* Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.
**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
*TypeError: Cannot read properties of undefined (reading
'product_template_attribute_value_ids')*.
**Cause:**
[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│ • product = await _getProductByBarcode(productBarcode) ✅ found
│ • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│ ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│ • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│ • calls openConfigurator(productTemplate, { ...opts })
│ opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
• opts.code = lotBarcode → truthy → enters if(opts.code) branch
• getBy("barcode", opts.code.base_code)
• getBy("barcode", "784512") ← "784512" is a LOT number, not a product barcode!
→ returns undefined ❌
• product packaging lookup also fails → undefined ❌
• product = undefined
│
└─ attributeLinesValues.map(values =>
values.filter(value =>
product.product_template_attribute_value_ids.includes(value)
^^^^^^^ undefined → 💥 TypeError
**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
instead.
---
opw-6031909
Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572This update fixes three critical errors in Polish e-invoice (FA3) generation that were causing incorrect tax codes, currency misstatements, and exchange rate calculations. These corrections ensure that invoices with 5% taxes, foreign currencies, and custom exchange rates are now generated correctly for KSeF submission.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
7 changes
Resolved issues and error corrections
This update fixes an issue on mobile devices where the buttons within the transfer chatter view were too small, causing text to overflow and making the interface difficult to use. The change ensures that buttons are properly sized and display all text clearly, improving the user experience on mobile.
Original PR description
Partial backport of d16480179ed73f25e0465e42c6fdef64e4fdc502 Steps to reproduce ================== - Navigate to Barcode, click on any transfer - Click on the name of the transfer in the header to open the form view - Scroll down to the chatter, the buttons are too small to contain the text, and much of the text flows over to other UI elements Cause of the issue ================== The barcode style override every buttons including the ones inside the chatter opw-6082959 Forward-Port-Of: odoo/enterprise#112581
Fixed an issue where the account balance in IAP (In-App Purchase) accounts would incorrectly reset to zero after saving, requiring users to refresh the page to see the actual balance. The balance now remains accurate immediately after saving the record.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#256589
This fix prevents files from becoming orphaned when attachment uploads encounter errors. Previously, if a file write operation failed (such as due to disk space issues), the system wouldn't properly mark the file for cleanup, causing it to remain on disk and block future uploads of the same file. The fix ensures files are marked for cleanup before the write operation, preventing disk space waste and upload failures.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This fix resolves an issue where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates these identifiers when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix resolves a crash that occurred in Point of Sale when scanning GS1-encoded barcodes for products with variants and lot tracking enabled. The system was incorrectly trying to interpret lot numbers as product barcodes, causing the application to fail. The fix ensures the correct product information is passed through the barcode scanning process so variants can be properly configured.
Original PR description
**Steps to reproduce:** * Install `point_of_sale` module. * Go to Settings: * Enable Lots & Serial Numbers. * Enable Variants. * Set Barcode Nomenclature to Default GS1 Nomenclature. * Create a…
**Steps to reproduce:**
* Install `point_of_sale` module.
* Go to Settings:
* Enable Lots & Serial Numbers.
* Enable Variants.
* Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
* Enable Track Inventory set to By Lots.
* Under Attributes & Variants:
* Add an attribute with two values and save.
* Generate product variants:
* Open one variant and set barcode to 5123648695416.
* Update inventory:
* Go to the main product (template).
* Update On Hand Quantity:
* Update On Hand Quantity with a lot/serial number:
010512364869541610784512.
* Select the variant with the defined barcode.
* Under Point of Sale tab:
* Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.
**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
*TypeError: Cannot read properties of undefined (reading
'product_template_attribute_value_ids')*.
**Cause:**
[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│ • product = await _getProductByBarcode(productBarcode) ✅ found
│ • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│ ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│ • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│ • calls openConfigurator(productTemplate, { ...opts })
│ opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
• opts.code = lotBarcode → truthy → enters if(opts.code) branch
• getBy("barcode", opts.code.base_code)
• getBy("barcode", "784512") ← "784512" is a LOT number, not a product barcode!
→ returns undefined ❌
• product packaging lookup also fails → undefined ❌
• product = undefined
│
└─ attributeLinesValues.map(values =>
values.filter(value =>
product.product_template_attribute_value_ids.includes(value)
^^^^^^^ undefined → 💥 TypeError
**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
instead.
---
opw-6031909
Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572This update fixes three critical errors in Polish e-invoice (FA3) generation that were causing incorrect tax codes, currency mismatches, and exchange rate calculations. The fixes ensure that 5% tax rates are properly coded, invoice amounts are correctly stated in the invoice's currency rather than always in Polish Zloty, and currency conversion rates are calculated in the right direction. These corrections are essential for proper e-invoice submission through the KSeF system.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
Code cleanup and technical improvements
A test was moved from the base module to the test_testing_utilities module where the test model it uses is actually defined. This is a housekeeping change that improves code organization and ensures tests are located with their corresponding test models, making the codebase easier to maintain.
Original PR description
Move the test to test_testing_utilities where the model res.config.test is defined. Move test introduced in odoo/odoo#257033. runbot-242309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257514
6 changes
Enhancements to existing features
This update optimizes the installation process for the l10n_jo_edi module by preventing unnecessary calculations during initial setup. Specifically, a new column was added to the database to store a unique identifier, reducing installation time, especially for systems with many existing records. This improves overall Odoo performance.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204 Forward-Port-Of: odoo/odoo#257658
Resolved issues and error corrections
This update fixes an issue on mobile devices where the buttons within the transfer chatter view were too small, causing text to overflow and making the interface difficult to use. The change ensures that buttons are properly sized and displayed, improving the user experience when viewing transfers on smartphones and tablets.
Original PR description
Partial backport of d16480179ed73f25e0465e42c6fdef64e4fdc502 Steps to reproduce ================== - Navigate to Barcode, click on any transfer - Click on the name of the transfer in the header to open the form view - Scroll down to the chatter, the buttons are too small to contain the text, and much of the text flows over to other UI elements Cause of the issue ================== The barcode style override every buttons including the ones inside the chatter opw-6082959 Forward-Port-Of: odoo/enterprise#112581
Fixed an issue where the account balance in IAP (In-App Purchase) accounts would incorrectly reset to zero after saving a record. Users previously had to refresh the page to see the actual balance. Now the balance remains accurate immediately after saving, improving the user experience and reducing confusion.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#256589
This fix prevents files from becoming orphaned when an error occurs during file upload. Previously, if a file write operation failed (such as due to disk space issues), the system wouldn't clean up the incomplete file, causing storage waste and blocking future uploads of the same file. Now the system properly marks files for cleanup before attempting to write them, ensuring disk space is freed even when uploads fail.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This fix resolves a problem where POS orders created in Jordan before installing the electronic invoicing module were failing to submit to JoFotara due to missing unique identifiers. The update ensures that order identifiers are automatically generated when needed, preventing submission errors and allowing these orders to be processed successfully.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This update fixes three critical errors in Polish e-invoice (FA3) generation: corrects a tax code from 'zw' to '5' for 5% taxes, ensures invoice amounts are shown in the correct currency rather than always in PLN, and fixes the currency exchange rate calculation to properly convert foreign currencies to PLN. These corrections ensure e-invoices submitted through KSeF comply with Polish tax authority requirements.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
9 changes
Resolved issues and error corrections
This update fixes an issue where users were incorrectly prompted for passwords when downloading encrypted documents that didn't actually require them. The change now correctly checks if a password is needed before attempting a download, ensuring a smoother and more reliable experience for users. This resolves a previous blocking issue.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5400441 Previously, if a user went to download a document, we would check if it was encrypted. If so, we would redirect to ask for a password. But the problem with that is, not all encrypted documents require passwords. In that case, we would ask for a password when none existed, thus blocking the user from downloading the document. Now we check if a password is required to access the document instead of whether the document is encrypted. That way, we won't redirect to ask for a password when there is no password. Docs about PdfFileReader's `decrypt` method, before and after a major change: https://pypdf2.readthedocs.io/en/2.3.0/modules/PdfReader.html https://pypdf2.readthedocs.io/en/2.12.0/modules/PdfReader.html Forward-Port-Of: odoo/enterprise#102602
This update fixes a display issue in the Danish balance sheet and profit & loss reports, ensuring accurate reporting for Danish accounting practices. The changes simplify the report format and improve translation accuracy, aligning with Danish chart of accounts standards.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113001 Forward-Port-Of: odoo/enterprise#112430
This update fixes an issue on mobile devices where the buttons within the transfer chatter view were too small, causing text to overflow and making the interface difficult to use. The change ensures that buttons are appropriately sized for mobile screens, improving the user experience when managing transfers.
Original PR description
Partial backport of d16480179ed73f25e0465e42c6fdef64e4fdc502 Steps to reproduce ================== - Navigate to Barcode, click on any transfer - Click on the name of the transfer in the header to open the form view - Scroll down to the chatter, the buttons are too small to contain the text, and much of the text flows over to other UI elements Cause of the issue ================== The barcode style override every buttons including the ones inside the chatter opw-6082959 Forward-Port-Of: odoo/enterprise#112581
The Danish localization module has been updated to align with the latest requirements from Danish tax authorities. All accounting accounts, translations, and account groupings have been refreshed to use official Danish terminology and current standards. Existing users will have outdated accounts automatically archived through a migration process, ensuring their data remains intact while using the updated chart of accounts.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257623 Forward-Port-Of: odoo/odoo#256541
This update resolves an issue where attempting to apply inactive TDS/TCS taxes in the Indian localization module would cause the system to crash. The fix allows the system to properly recognize and handle inactive taxes, preventing errors and improving system stability for users managing tax configurations.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534 Forward-Port-Of: odoo/odoo#256809
Fixed an issue where the account balance for IAP (In-App Purchase) services would incorrectly reset to zero after saving a record, requiring users to manually refresh the page to see the actual balance. The balance now remains accurate immediately after saving.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#256589
This update fixes three critical errors in Polish e-invoice (FA3) file generation: corrects a tax code for 5% tax rates, ensures invoice amounts are calculated in the correct currency rather than always in Polish Zloty, and fixes currency exchange rate calculations. These corrections ensure that e-invoices sent through the KSeF system are generated with accurate tax codes, amounts, and exchange rates.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
This fix resolves a problem where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing order identifiers. The system now automatically generates the required identifier when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
Code cleanup and technical improvements
A test was moved from the base module to the test_testing_utilities module where the test model it uses is actually defined. This improves code organization and ensures tests are located with the components they test, making the codebase easier to maintain.
Original PR description
Move the test to test_testing_utilities where the model res.config.test is defined. Move test introduced in odoo/odoo#257033. runbot-242309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257514
17 changes
New functionality added to Odoo
This update adds a visual icon for the Lazada module within Odoo. This improves the user experience by clearly identifying the Lazada integration and making it easier to find within the application's navigation.
Original PR description
Add Lazada icon to the module Forward-Port-Of: odoo/enterprise#105010
Resolved issues and error corrections
This update resolves a bug in the account reports testing environment. The fix addresses inconsistencies in data handling and ensures report lines correctly display invoice references. This improves the reliability of test results and the accuracy of account reporting.
Original PR description
Now that context is not hacked, some flush and write are done a bit differently. Fix tests. account_reports: probably due to a missing flush or data computation tests were a bit hacked to account for invalid data. This is now fixed, report line correctly contains the invoice reference.
This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how we handle other related documents like ‘e-Remito’ and ‘e-Resguardos’, ensuring data consistency and accuracy for vendor billing.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This update resolves an issue where the 'Edit Properties' button was unexpectedly appearing in the project dashboard. The fix prevents the button from showing up when it's not relevant, streamlining the user experience for project management. This ensures users only see options that apply to their current project setup.
Original PR description
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit…
Steps to produce: --- - Install `Databases` modules. - Go to project > Switch to list view and open project. - Click on the gear icon > Click `Edit Properties.` Observation: --- - Clicking `Edit Properties` does nothing. Root cause: --- - The `Edit Properties` action appears whenever a properties field is present in the view. - Currently, in `project.project` the field `database_kpi_properties` is added from database module (See [1]). - Here at [2], the field is added in `edit_project` view. - However, the field is only visible when `database_hosting` is set, and its value is different from `other`. Solution: --- - Patched `FormController.getStaticActionMenuItems()` and added a condition to make the `addPropertyFieldValue` menu item unavailable when the current model is `project.project`. [1]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/models/project_project.py#L36 [2]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/databases/views/databases_project_views.xml#L158 Note: --- - Also found that, clicking `Edit Properties` from a page other than the KPI page does nothing. We could either show a guiding `dialog box` or limit the visibility of `Edit Properties` to the KPI page only. opw-5933007 --- Forward-Port-Of: odoo/enterprise#108056
This update fixes an error preventing Intervat from properly verifying our connections. The issue stemmed from outdated JWK keys being archived on IAP, which caused authentication failures. The fix involves ensuring Intervat can access the most current JWK keys, restoring seamless communication with Intervat.
Original PR description
When we open a connection in intervat, we initialize a JWK on IAP side,
then we use the private key linked with this JWK to sign our requests.
The problem is on IAP, we have a cron who archive JWK older than a week.
As the archived JWK are hidden in our JWKS endpoint, Intervat is no
longer capable of verifying our signatures, leading to this error:
`{"error_description":"JWT is not valid" "error":"invalid_client"}`.
To fix this, we might need to call IAP first to unarchive the JWK first.
no-task
Forward-Port-Of: odoo/enterprise#112719This update addresses an issue where incorrect DTE (Digital Tax Document) XML files were causing the system to generate invoices even when they were invalid. The fix reintroduces a check to discard these files, preventing the creation of unnecessary invoices and ensuring data accuracy. This improves the reliability of the purchase order process.
Original PR description
A supplier DTE xml should be discard when being fetched by a DTE incoming server if it has the wrong document type, meaning no account move should be created from it. Steps: - Have purchase journal using documents - Setup an incoming mail server, with DTE option enable, with email address X - Send an email to X with a supplier DTE xml of type 52 (TipoDTE element) - Fetch mails from the incoming server -> a bill has been generated and filled, it shouldn't Cause: The check on document type has been removed with the refactor 42744fcecdbd36ea0101070c68299227a9f204a6 Fix: Reintroduce the check in `_process_incoming_supplier_document` before creating any record opw-5978959 Forward-Port-Of: odoo/enterprise#112877
This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly interpreted, leading to potential errors in reconciliation reports. The change introduces a new function to intelligently parse these amounts, ensuring accurate calculations and reporting. This improves the reliability of financial data.
Original PR description
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
Examples:
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.
Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)
task-6026748
Forward-Port-Of: odoo/enterprise#110410This fix resolves a crash that occurred in the Point of Sale system when scanning GS1-formatted barcodes for products with multiple variants. The system was incorrectly trying to look up lot numbers as product barcodes, causing the application to fail. The fix ensures the correct product information is passed through the barcode scanning process, allowing customers to successfully scan and add configurable products to their orders.
Original PR description
**Steps to reproduce:** * Install `point_of_sale` module. * Go to Settings: * Enable Lots & Serial Numbers. * Enable Variants. * Set Barcode Nomenclature to Default GS1 Nomenclature. * Create a…
**Steps to reproduce:**
* Install `point_of_sale` module.
* Go to Settings:
* Enable Lots & Serial Numbers.
* Enable Variants.
* Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
* Enable Track Inventory set to By Lots.
* Under Attributes & Variants:
* Add an attribute with two values and save.
* Generate product variants:
* Open one variant and set barcode to 5123648695416.
* Update inventory:
* Go to the main product (template).
* Update On Hand Quantity:
* Update On Hand Quantity with a lot/serial number:
010512364869541610784512.
* Select the variant with the defined barcode.
* Under Point of Sale tab:
* Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.
**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
*TypeError: Cannot read properties of undefined (reading
'product_template_attribute_value_ids')*.
**Cause:**
[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│ • product = await _getProductByBarcode(productBarcode) ✅ found
│ • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│ ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│ • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│ • calls openConfigurator(productTemplate, { ...opts })
│ opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
• opts.code = lotBarcode → truthy → enters if(opts.code) branch
• getBy("barcode", opts.code.base_code)
• getBy("barcode", "784512") ← "784512" is a LOT number, not a product barcode!
→ returns undefined ❌
• product packaging lookup also fails → undefined ❌
• product = undefined
│
└─ attributeLinesValues.map(values =>
values.filter(value =>
product.product_template_attribute_value_ids.includes(value)
^^^^^^^ undefined → 💥 TypeError
**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
instead.
---
opw-6031909
Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572This fix resolves a problem where copying and pasting text in the website builder was incorrectly creating paragraph elements inside buttons and other inline-only containers. The fix allows the editor to properly handle inline elements at the root level when the container shouldn't contain block-level elements like paragraphs or divs.
Original PR description
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p`…
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements). This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource. This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements. Steps to reproduce: - Open website builder on a product page - Select text in "Add to cart" button - Copy - Paste - Bug: a `p` element is created (on master) - Open website builder - Select "Company" below footer - Copy - Paste - Bug: a `p` element is created [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5868460 Forward-Port-Of: odoo/odoo#257512 Forward-Port-Of: odoo/odoo#247231
This fix resolves a problem where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates these identifiers when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix resolves an issue where projects created from CRM leads using templates were assigned to the wrong company. Previously, the system would incorrectly use the template's company instead of the lead's company, causing data mismatches. Now the company is properly preserved when creating projects from leads.
Original PR description
When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default…
When creating a project from a CRM lead using a template, the `default_company_id` set by `_get_project_create_from_lead_context` is ignored because `company_id` is not in the template default context whitelist. This causes the new project to inherit the template's company instead of the lead's company, resulting in a company mismatch with the partner and a UserError. https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/crm_sale_project/models/crm_lead.py#L37-L45 https://github.com/odoo/odoo/blob/2b89db4af2265e5cec8feb11853364e293de203e/addons/project/models/project_project.py#L1413-L1419 Steps To Reproduce: 1. Go to CRM, create or open a lead. 2. Clear the contact field and save. 3. Click the gear icon → Create Project. 4. Select any project template (not empty) and submit. Ticket [link](https://www.odoo.com/odoo/project.task/5933253) opw-5933253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250087
This fix ensures that when users send multiple Request for Quotations (RFQs) using the bulk "Send by mail" action, the RFQ status is automatically updated to "Sent" - just like it does when sending from the individual form view. Previously, RFQs would remain marked as draft even after being emailed, causing confusion and requiring users to manually resend them to update the status.
Original PR description
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them…
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users. Steps to Reproduce: ======================= - Install the `Purchase` app. - Go to Purchase and select multiple RFQs in the list view. - Click `Send by mail` from the actions menu. - Select the RFQ email template and send the email. - Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view. Cause of the issue: ======================= The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated After This Commit: ======================= When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state. TaskID-5443248 Forward-Port-Of: odoo/odoo#243050
This update fixes three critical errors in Polish e-invoice (FA3) generation that were causing incorrect tax codes, currency misstatements, and exchange rate calculations. The fixes ensure that 5% taxes are properly coded, invoice amounts are shown in the correct currency, and currency conversion rates are calculated correctly for multi-currency invoices sent through the KSeF system.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
This fix resolves an error that occurred when users submitted the Create a Task form with an email address that doesn't correspond to an existing contact. The system was trying to add an outdated email field that no longer exists in the task system, causing the submission to fail. The fix prevents this invalid field from being added, allowing the form to submit successfully.
Original PR description
Currently, an error occurs when a user submits the Create a Task form. **Steps to Reproduce:** - Install the `website_project` module. - Go to `website` > `Click on Edit` > `Drag and drop` form. -…
Currently, an error occurs when a user submits the Create a Task form. **Steps to Reproduce:** - Install the `website_project` module. - Go to `website` > `Click on Edit` > `Drag and drop` form. - Click on the form and, set the action to `Create a Task`, then save. - Fill in the required data in the form. - In the `Email Address` field, enter an email that does not correspond to any existing partner. - `Submit` the form, and the `error appears in the logs`. `ValueError: Invalid field 'email_cc' in 'project.task'` With this [recent commit], the email_cc field has been removed from project.task, along with the mail.thread.cc inheritance, because threads are now able to find CC recipients. so, when user submits the form with an email address that does not correspond to any existing partner, the system adds email_cc to the record [1], and when it attempts to create the record [2], it raises an error. This commit ensures that email_cc is no longer added to the record. [recent commit]: https://github.com/odoo/odoo/commit/3c26c0553754a75d9440097ad473be3cc8bcb320#diff-93ba226020add6481cfeab916e69980a59163e2925a5c2c9a3bc0aaceb484cdf [1]- https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/website_project/controllers/main.py#L61 [2]: https://github.com/odoo/odoo/blob/21aa7e7eca0bf78978e0667cee43129985833166/addons/project/models/project_task.py#L1167 sentry-7374084515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256964
This update improves the reliability of automated tests across multiple Odoo modules by restoring email tracking features that were previously disabled. The changes help catch real-world issues with access controls and data tracking that were being masked by overly simplified test conditions. Additionally, a bug in the sales module tests was fixed where a record object was incorrectly used instead of its ID.
This fix resolves an issue where multi-line product descriptions were appearing in reverse order when displayed in the shopping cart. The problem was caused by a previous change that attempted to prioritize rental dates and variant information, but inadvertently reversed all description text. The fix removes the reversal logic to ensure product descriptions display correctly, though variant details and rental dates may no longer always appear first.
Original PR description
Issue: --- Due to this issue, the description following lines are inversed. Steps to reproduce: --- 1- In product page in backend, add a multiline "Short Description" to a product. 2- Navigate to website and add the product to the cart. 3- Open the cart. Outcome: The description after lines are shown inversed. Cause: --- This is introduced by https://github.com/odoo/odoo/pull/223433. It was done to ensure some information such as rental date and variant description are shown at the beginning. However, it didn't consider that the product description itself might have multilines. Fix: --- There is no clean way to reliably extract structured information from the computed name. To avoid reversing the product description lines, we no longer reverse the description. As a limitation, variant descriptions and rental dates may no longer always appear first. opw-5976614 Forward-Port-Of: odoo/odoo#252259
This fix corrects how Odoo calculates taxes on invoices that use price-included tax mode but have zero price-excluded taxes. Previously, the system would incorrectly switch to excluded tax mode in this scenario. Now it properly handles mixed tax configurations without unnecessary mode switching, ensuring accurate tax calculations on invoices.
Original PR description
…xes_data Suppose an invoice with price-included taxes but with a zero price excluded one. We don't want to fallback on the excluded mode just for that. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257495
11 changes
Resolved issues and error corrections
This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how other documents like ‘e-Remito’ and ‘e-Resguardos’ are handled, ensuring data consistency and accuracy for vendor billing.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This update fixes an issue on mobile devices where the buttons within the transfer chatter view were too small, causing text to overflow and making the interface difficult to use. The change ensures that buttons are properly sized and display all text clearly, improving the user experience on mobile. This resolves a reported usability problem.
Original PR description
Partial backport of d16480179ed73f25e0465e42c6fdef64e4fdc502 Steps to reproduce ================== - Navigate to Barcode, click on any transfer - Click on the name of the transfer in the header to open the form view - Scroll down to the chatter, the buttons are too small to contain the text, and much of the text flows over to other UI elements Cause of the issue ================== The barcode style override every buttons including the ones inside the chatter opw-6082959 Forward-Port-Of: odoo/enterprise#112581
This update fixes an issue where incorrect DTE (Digital Tax Document) XML files received by the system were automatically generating invoices. The fix reintroduces a check to discard these invalid DTEs, preventing the creation of unnecessary invoices and ensuring data accuracy. This improves the reliability of the purchase journal.
Original PR description
A supplier DTE xml should be discard when being fetched by a DTE incoming server if it has the wrong document type, meaning no account move should be created from it. Steps: - Have purchase journal using documents - Setup an incoming mail server, with DTE option enable, with email address X - Send an email to X with a supplier DTE xml of type 52 (TipoDTE element) - Fetch mails from the incoming server -> a bill has been generated and filled, it shouldn't Cause: The check on document type has been removed with the refactor 42744fcecdbd36ea0101070c68299227a9f204a6 Fix: Reintroduce the check in `_process_incoming_supplier_document` before creating any record opw-5978959 Forward-Port-Of: odoo/enterprise#112877
Fixed an issue where the account balance for IAP (In-App Purchase) services would incorrectly reset to 0 after saving a record, requiring users to refresh the page to see the actual balance. The balance now remains accurate immediately after saving, improving the user experience when managing service accounts.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#256589
This update reorganizes test code to ensure tests are located in the same module where the test models they use are defined. A test was moved from the base module to the test_testing_utilities module where the res.config.test model is actually defined. This improves code organization and maintainability without affecting any user-facing functionality.
Original PR description
Move the test to test_testing_utilities where the model res.config.test is defined. Move test introduced in odoo/odoo#257033. runbot-242309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257514
This fix prevents orphaned files from accumulating on disk when file uploads encounter errors. Previously, if a file write operation failed (such as due to disk space issues), the system wouldn't clean up the incomplete file, causing storage waste and blocking future uploads of the same file. Now the system properly marks files for cleanup before attempting to write them, ensuring disk space is freed even when uploads fail.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This update improves how the "My Team" filter works in Live Chat agent reports. Instead of filtering by department, the system now uses a manager-based hierarchy, showing each agent their own records plus records of employees they directly manage. This provides a more accurate and intuitive view of team performance data.
Original PR description
Replace the department-based domain with a hierarchy-based domain. The new filter includes the current user's records and the records of employees whose manager is the current user. follow-up of https://github.com/odoo/odoo/pull/253567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257548
This fix resolves a problem where POS orders created in Jordan before installing the electronic invoicing module could not be submitted to JoFotara due to missing unique identifiers. The update automatically generates these required identifiers when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This update fixes three critical errors in Polish e-invoice (FA3) generation: corrects a tax code for 5% tax rates, ensures invoice amounts are calculated in the correct currency rather than always in PLN, and fixes currency exchange rate calculations. These fixes ensure that e-invoices sent through the KSeF system are generated with accurate tax codes, amounts, and exchange rates.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221 Forward-Port-Of: odoo/odoo#256906
This fix resolves a crash that occurred in the Point of Sale system when scanning GS1-formatted barcodes for products with variants. The system was incorrectly trying to look up lot numbers as product barcodes, causing the application to fail. The fix ensures the correct product information is passed through the system so variant selection works properly.
Original PR description
**Steps to reproduce:** * Install `point_of_sale` module. * Go to Settings: * Enable Lots & Serial Numbers. * Enable Variants. * Set Barcode Nomenclature to Default GS1 Nomenclature. * Create a…
**Steps to reproduce:**
* Install `point_of_sale` module.
* Go to Settings:
* Enable Lots & Serial Numbers.
* Enable Variants.
* Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
* Enable Track Inventory set to By Lots.
* Under Attributes & Variants:
* Add an attribute with two values and save.
* Generate product variants:
* Open one variant and set barcode to 5123648695416.
* Update inventory:
* Go to the main product (template).
* Update On Hand Quantity:
* Update On Hand Quantity with a lot/serial number:
010512364869541610784512.
* Select the variant with the defined barcode.
* Under Point of Sale tab:
* Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.
**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
*TypeError: Cannot read properties of undefined (reading
'product_template_attribute_value_ids')*.
**Cause:**
[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│ • product = await _getProductByBarcode(productBarcode) ✅ found
│ • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│ ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│ • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│ • calls openConfigurator(productTemplate, { ...opts })
│ opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
• opts.code = lotBarcode → truthy → enters if(opts.code) branch
• getBy("barcode", opts.code.base_code)
• getBy("barcode", "784512") ← "784512" is a LOT number, not a product barcode!
→ returns undefined ❌
• product packaging lookup also fails → undefined ❌
• product = undefined
│
└─ attributeLinesValues.map(values =>
values.filter(value =>
product.product_template_attribute_value_ids.includes(value)
^^^^^^^ undefined → 💥 TypeError
**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
instead.
---
opw-6031909
Forward-Port-Of: odoo/odoo#257227
Forward-Port-Of: odoo/odoo#254572Miscellaneous changes
This pull request contains internal testing updates for the account_online_payment module within Odoo Enterprise. These tests ensure the payment processing functionality continues to operate correctly and reliably. The changes are focused on improving the testing framework, not a customer-facing feature.
Original PR description
No task ID
1 change
Enhancements to existing features
This update optimizes the installation process for the l10n_jo_edi module by preventing unnecessary calculations during initial setup. Specifically, a new column has been added to the database to store a unique identifier, speeding up the module's installation time, especially in systems with many existing records.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204 Forward-Port-Of: odoo/odoo#257658
1 change
Enhancements to existing features
This update improves the installation speed of the Jordan EDI module by pre-creating a database column during setup instead of computing it afterward. This prevents slow installation times when the system has many invoices, making the module deployment faster and more efficient.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204