Daily updates from Odoo
Tuesday, April 28, 2026
42 changes · saas-19.1
New functionality added to Odoo
This pull request updates the localization files for Odoo, specifically adding support for Vietnamese accounting and point-of-sale (POS) features. The changes include the addition of new terms related to Viettel POS and a new 'pos_cashdro' module, ensuring accurate translations for Vietnamese users.
Original PR description
- Added `l10n_vn_edi_viettel_pos` - Removed `project_mrp_sale` (no terms left) Forward-Port-Of: odoo/odoo#261555
This pull request updates the .weblate.json files to include support for two new languages: ‘documents_project_sign’ and ‘l10n_eg_iot’. These additions expand Odoo Enterprise's localization capabilities, allowing us to serve a wider range of international customers and support new markets.
Original PR description
- Added `documents_project_sign` - Added `l10n_eg_iot` Forward-Port-Of: odoo/enterprise#115424
Enhancements to existing features
This update prioritizes incomplete tax returns in the tax returns kanban view when no filters are selected. This change ensures users see the most critical returns first, streamlining the reporting process and improving data visibility. The change was implemented to enhance user experience and operational efficiency.
Original PR description
When no filters are applied on the tax returns kanban view, incomplete returns should always be displayed before complete ones. This commit ensure that by ordering tax returns by `is_completed` field. task-6059414 Forward-Port-Of: odoo/enterprise#114043
This update implements the latest withholding tax regulations for Ecuador, as mandated by "Resolución N.º NAC-DGERCGC26-00000009". It ensures Odoo accurately calculates and reports these taxes, maintaining historical data and aligning with internal TRESCLOUD guidelines. This change is crucial for compliance with Ecuadorian tax laws.
Original PR description
Implement the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. SPECIFICATION: - Created the new withholding percentages as new tax records. - Set the previous withholding percentages as inactive to preserve historical data. - Ensured compatibility with existing tax configurations and fiscal mappings. Table with the changes established in "Resolución N.º NAC-DGERCGC26-00000009". <img width="1676" height="303" alt="image" src="https://github.com/user-attachments/assets/79ae91b2-6d31-442f-af3c-74304742c8b6" /> BP: #252917 Forward-Port-Of: odoo/odoo#257513 Forward-Port-Of: odoo/odoo#254018
Resolved issues and error corrections
This update fixes a technical issue that caused errors when repeatedly deleting images within the Image Wall feature in Website Edit Mode. The fix ensures the system handles rapid deletions more reliably, preventing tracebacks and improving the overall editing experience. This enhances stability and reduces potential disruptions for users.
Original PR description
Error: Cannot read properties of null (reading 'children') Steps to reproduce: 1.Go to Website -> Edit mode. 2.Add an Image Wall snippet. 3.Click on an image, then repeatedly click the Delete button. 4.Traceback occurs. Before this commit: The first delete click correctly removes the target element from the DOM, including its parent. On subsequent rapid clicks, the handler runs again on the same already-removed element. At that point, parentElement is null, so accessing children throws a traceback. After this commit: Added a safety check using `isConnected` in the delete handler to ensure the element is still part of the DOM. If not, the handler returns early. Repeated delete clicks no longer cause a traceback. task-6033622 Forward-Port-Of: odoo/odoo#261341 Forward-Port-Of: odoo/odoo#255733
This update ensures consistent test tagging across Odoo versions 18 and 19, preventing potential disruptions to automated testing. Previously, an error during nightly testing could disable the entire 'hoot suite'. This change backports a fix from a larger project to maintain stability and reliability of our testing processes.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests. Forward-Port-Of: odoo/odoo#261618 Forward-Port-Of: odoo/odoo#261526
This update fixes an issue where the ‘Ordered Quantity’ on delivery slips was incorrectly calculated when a receipt didn’t fully meet the demand. Now, the ‘Ordered Quantity’ accurately reflects the actual demand, ensuring accurate inventory tracking. This improves the reliability of delivery reports.
Original PR description
**Steps to reproduce:** * Install the *Inventory* (`stock`) module. * Create a *Storable Product* and set some *On Hand* quantity. * Go to *Inventory → Operations → Receipts*. * Create a new receipt.…
**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
* Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
* Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.
**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
* Case 1 (Demand=10, Done=8):
* Ordered = 8, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 12, Delivered = 12.
**Expected behavior:**
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
**Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157
CASE- 1
* When validating with *less quantity* and *no backorder*:
* In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
* If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
* where it take quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
* As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.
CASE-2
* When validating with *more quantity* than demanded:
* `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
* The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
* The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
* In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
→ `qty_ordered += 2` → `qty_ordered = 12` ✗ (surplus added to demand)
→ `quantity += 2` → `quantity = 12` ✓
* The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.
* After the fix:
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
* NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully
Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
<img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
</div>
<p><strong>After:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
<img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
</div>
</details>
---
opw-5874759
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250587This update corrects a typographical error within the marketing automation test suite. The fix ensures the tests run smoothly and reliably. This is a routine maintenance update with no impact on core business functionality.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This change updates the email address used to send automated support notifications from iap@odoo.com to noreply@odoo.com. This improves email deliverability and reduces the risk of incorrect responses to support inquiries.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/odoo#260794 Forward-Port-Of: odoo/odoo#259691
This change updates the email address used to respond to automated Odoo emails from iap@odoo.com to noreply@odoo.com. This improves email management and reduces the likelihood of incorrect responses to support inquiries.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update resolves an issue where duplicating an employee would incorrectly copy their bank account information, leading to salary payments being routed to the same account for both employees. The fix ensures that the bank account is cleared during duplication, preventing this duplication and maintaining accurate payroll processing.
Original PR description
Steps: - Duplicate an employee. - Check that the bank account is copied. - Modify the bank account on the duplicated employee. - Verify the original employee’s bank account. Issue: - When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account. Fix: - Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee. task-6093406 Forward-Port-Of: odoo/odoo#261505 Forward-Port-Of: odoo/odoo#259405
This update ensures that the 'Source' (origin) field is correctly populated on replacement invoices generated after a cancellation request. Previously, this information was missing, hindering traceability and compliance. The fix explicitly copies the original invoice's data to the replacement, maintaining accurate links and required labeling for reporting.
Original PR description
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice…
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099
This update addresses an issue where Coda bank statement files with incomplete data could result in an empty payment reference field in Odoo. This would automatically default to 'No description' on the statement line, leading to inaccurate reporting. This fix ensures correct payment reference data is captured.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update corrects a problem where the Account ID in Odoo's FAIA export files didn't always match the corresponding account details within the accounting system. This ensures accurate financial reporting and data consistency, particularly for Luxembourg-specific reports. The fix aligns the AccountID field with the account code used in the general ledger.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#114254 Forward-Port-Of: odoo/enterprise#113455
This update resolves an issue where the Planning app would crash when adding a new employee with no calendar. The fix addresses a problem caused by an empty time zone value, ensuring the app handles diverse employee types correctly. This improves stability and usability for all users.
Original PR description
Issue: ---------------------------------------- When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback. Steps to reproduce:…
Issue: ---------------------------------------- When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback. Steps to reproduce: ---------------------------------------- - Have Planning and Time Off installed - Create a public holiday for another company - Create an employee with no calendar - Open Planning and try to add the new employee - Traceback Cause: ---------------------------------------- This commit 55ce1e3411d0693807d883ac159039b8141ff6b6 added the new method called `_get_flexible_resource_valid_work_intervals()` which will call `_leave_intervals_batch()` on `self.env['resource.calendar']`. In `_leave_intervals_batch()`, the resource list will contain the fully flexible employee and `self.env['resource.resource']`. During the handling of the public holiday we created, we loop through the resource list. The first one is the flexible employee, but it gets skipped by the `continue` as it has a different company. Because of this the variable `tz` still equals `None`. The second resource is `self.env['resource.resource']` which doesn't validate the condition to be skipped. So it reaches the line ```py tz = tz if tz else timezone((resource or self).tz) ``` But `tz` is still `None` and both `resource` and `self` are empty, so it gives `False` to the timezone constructor, which crashes. Solution: ---------------------------------------- Add a default value to 'UTC' to handle this specific case. opw-6107269 Forward-Port-Of: odoo/odoo#259404
This update improves the Odoo accounting system for Sri Lanka by incorporating updated Chart of Accounts (CoA) and tax settings. These changes align with standard Sri Lankan accounting practices, ensuring accurate financial reporting and compliance.
Original PR description
Updates the CoA with new accounts, updated taxes, and adjusted default account mapping to better reflect standard Sri Lankan accounting practice. Enterprise PR: https://github.com/odoo/enterprise/pull/114768 task-6141758 Forward-Port-Of: odoo/odoo#260920
This update simplifies the setup of financial accounts for Sri Lankan businesses by reducing the complexity of account code formulas. It adds new lines for equity and liabilities to the Balance Sheet, providing a more complete financial picture. This change enhances flexibility and accuracy in reporting.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#114768
This update corrects a mismatch in how transaction IDs are represented when exporting financial data (FAIA). Previously, the system used different methods for identifying transactions, leading to potential errors in reporting. This change ensures all transaction IDs align, improving the accuracy and reliability of financial reports.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
A recent test in the Odoo point-of-sale restaurant module experienced timing issues, leading to incorrect order data synchronization. This update slowed down the test execution to prevent the test from changing the order before the server synced it, thus resolving the data loss problem. This ensures accurate test results and reliable order processing.
Original PR description
In the tour test_customer_alone_saved, the test was creating an order, then go on the ticket screen and then come back on the product screen to change the customer to go again on the ticket screen and come back on product screen to check that the customer did not changed. The problem was that when going to the ticket screen the first time, the order was synced with the server but the answer might come after the test changed the customer. When going the second time on the ticket screen, the order was changed with the information of the backend and the user was lost. This is all due to the test that are too fast. runbot-error: 238467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253587
This update resolves an unexpected crash in the website's knowledge section caused by a recent update to the dropdown component. The fix ensures the component handles situations where elements are no longer available, preventing errors when the sidebar is closed.
Original PR description
The goal of this commit is to fix the `test_10_website_conditional_visibility` test in the website, which has been crashing unpredictably since the dropdown patch in knowledge. This patch does not handle the case where `dropdownActiveEl` and `this.activeEl` are `undefined` because the component has already been destroyed. In our case, we have a popover that closes when the sidebar closes, triggered by clicking the “save” button. error-243073
This update fixes an error in the Profit and Loss report for French associations in version 19.1. The report was displaying incorrect financial figures due to inverted formulas, which has now been corrected to ensure accurate reporting of income and expenses.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967
This update resolves an issue where users could unintentionally bypass tax group checks during chart template updates in the l10n_ar module for Argentina. The change ensures that users must now explicitly handle uninstall processes, restoring previous behavior and maintaining data integrity. This prevents potential errors related to tax reporting compliance.
Original PR description
Commit 947e4dc9de3a replaced MODULE_UNINSTALL_FLAG with an explicit 'force_delete' context flag, and as the commit message warns, callees that relied on the previous flag must now detect 'force_delete' on their own. There is no automatic bypass anymore. **STEP TO REPRODUCE** 1.- Install l10n_ar 2-. Select one argentinian regime (fiscal package) & save 3-. Try to change package **FIX** Detect 'force_delete' in check_uninstall_required and return early, restoring 19.0 behavior. Manual deletions of the tax group are still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the Italian VAT (EDI) module that incorrectly determined whether a partner was a company based on their Codice Fiscale. Specifically, it now handles country-prefixed CFs correctly, ensuring the partner's company status is accurately reflected. This prevents incorrect categorization of businesses.
Original PR description
Since 5d3c73ffd0ad ("derive company status from Codice Fiscale format") is_company is True only when the CF (Codice Fiscale) is exactly 11 chars.
Two issues:
- No @api.depends on l10n_it_codice_fiscale, so editing the CF alone leaves is_company inchanged.
- A country-prefixed CF like "IT14475210960" is 13 chars and silently downgrades the partner to a natural person.
Steps to reproduce:
- On an Italian company partner, set:
VAT = IT14475210960
Codice Fiscale = MRTMTT91D08F205J
- Change the CF to IT11122244544, it will be saved but is_company will
remain False, which is wrong.
opw-6129645This update fixes a potential issue where multiple actions within a transaction could silently override role permissions when creating Sign automation rules. The change adds a check during the action creation process to ensure no conflicting role assignments are made, preventing incorrect permissions. This ensures consistent and reliable role management within the Sign app.
Original PR description
Before this commit, creating multiple server actions for the Sign app in a single transaction (e.g., when saving an Automation Rule with multiple nested actions) bypassed the `_check_sign_template_conflicts` constraint. Because the constraint only queried the database for existing links, it failed to detect conflicts within the in-memory batch, allowing the save to succeed and causing silent role overrides. This commit introduces an intra-batch check to the constraint. By tracking requested roles in memory during the loop, the constraint now correctly raises a ValidationError if multiple actions in the same transaction attempt to automate the exact same template roles. A test has been added to ensure batch creations are properly validated. Task: 6128909
This update corrects a problem preventing Worldline and Axepta payment terminal options from working correctly in Odoo's Point of Sale. The issue stemmed from an incorrect setting within the system, now resolved by aligning the payment provider selection and streamlining related images. This ensures seamless setup and operation of payment terminals for these providers.
Original PR description
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal…
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working. The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image. This commit changes the following: - The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider. - The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected. - The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update to the Viva payment process in the POS system was causing cancellations to fail. This fix ensures that payment and cancellation transactions use the same cash register ID, resolving the "Only cash register that created the transaction can abort it" error. This ensures Viva payments can be correctly cancelled from the POS.
Original PR description
Steps to reproduce: 1. Start a Viva payment from the POS 2. Cancel the payment from the POS (not on the terminal) **Expected behaviour:** Payment cancels successfully **Actual behaviour:** Error message "Only cash register that created the transaction can abort it". The fix is to use the same cash register ID in both the payment and the cancellation transactions. The payment cash register ID was originally changed to ensure payments would work in the kiosk, but the cancellation cash register ID was never updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues where deleting sign templates caused data corruption and broken document lineage tracking. The fix ensures documents remain intact and accurately link back to their original templates, regardless of the number of templates created from the same document. This enhances data integrity and reliability for signature workflows.
Original PR description
Steps to reproduce: Bug 1 (The Crash): 1. Open Documents app, select a PDF, and click Action > Sign. 2. In the Sign app, delete the newly created Sign Template. 3. Return to the Documents app. 4. A…
Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.
Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.
Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI.
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.
Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.
Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.
Task: 5432116
Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167A recent issue prevented activity states from correctly updating across different tabs within Odoo. This fix corrects a technical error that was disrupting this shared activity state functionality. Users should now see consistent and accurate activity updates regardless of which tab they are using.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259507 Forward-Port-Of: odoo/odoo#255785
This update allows administrators to override the automatic resetting of subscription users, providing greater control over user management within the Odoo Enterprise SaaS platform. Previously, this process was inflexible, and this change enhances operational efficiency and adaptability to specific business needs. This fix addresses a previous issue and improves system resilience.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update ensures Odoo correctly calculates and reports Ecuadorian withholding taxes for 2026, aligning with new government regulations (Resolución N.º NAC-DGERCGC26-00000009). Updated tests reflect the new withholding percentage requirements, ensuring accurate financial reporting for Ecuadorian businesses.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112957 Forward-Port-Of: odoo/enterprise#110712
This update resolves a bug that prevented invoices from being created correctly when discounts were applied to sales orders using foreign currencies. The fix ensures accurate discount allocation and invoice balancing, improving the reliability of financial reporting. This impacts all users utilizing multi-currency sales transactions.
Original PR description
**STEP TO REPRODUCE** 1. Install the sale and accounting module. 2. Create 2 products, and setup each one with a different income account. 3. From the accounting settings, setup an account for Invoice Line discount -> Customer Invoice account. 4. Enable a currency, and create a pricelist for this currency. 5. Create the following SO: pricelist -> the pricelist you created previously. currency rate : 0.000717398539 line a: product_a, price 10, discount 57.85% line b: product_b, price 70, discount 57.85% From this SO, try to create an invoice. It will fail, saying the invoice it tried to create is unbalanced. opw-5974048 Forward-Port-Of: odoo/odoo#257897
This update resolves an issue where the quick create feature for product variants within Bills of Materials was incorrectly creating new, unrelated product templates instead of variants. To ensure correct variant creation, the quick create option has been disabled, requiring users to create variants directly on the product template.
Original PR description
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create".…
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create". Issue: --- Using quick create on the Product Variant field does not create a variant of the selected product template. Instead, it creates a completely new, unrelated `product.template`. This is because the `create()` method on `product.product` is overridden to call super() with context `create_product_product=False`, which suppresses direct variant creation and forces creation through `product.template` instead, see [1]. **Why passing `default_product_tmpl_id` does not help:** One might expect that passing `default_product_tmpl_id` in the field context would cause the newly quick-created `product.product` to be linked to the already-selected `product.template`. However, because of the `create()` override above (introduced in [commit]), the variant creation is always redirected to `product.template`, ignoring any `default_product_tmpl_id` passed in context. It is therefore not possible in any case to quick-create a `product.product` that is correctly and directly linked to the currently selected `product.template`. Fix: --- Disable the "Create" and "Create and Edit" options. Since there is no way to quick-create a `product.product` that is correctly linked to the currently selected `product.template`, the user must create the variant directly on the product template first. [1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368 [commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8 opw-6127738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261316 Forward-Port-Of: odoo/odoo#259776
This update resolves a technical issue preventing invoices sent to Poland's KSeF system from being processed correctly. Previously, the system incorrectly included empty 'Email' and 'Telefon' tags in the invoice XML, leading to rejection. This change ensures these tags are only added when actual contact information is available, improving invoice acceptance rates.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Create and send an invoice to KSeF where the buyer has no email or no phone number 3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags. After this commit: Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present. opw-6124187 Forward-Port-Of: odoo/odoo#259646
This update resolves an issue where expense cards were rejecting payments for certain merchant categories (airlines, car rentals, and hotels) due to missing MCC codes. The team added the necessary MCC ranges to the system, ensuring these expenses can now be processed correctly. This improves the usability of the expense card for a wider range of business travel expenses.
Original PR description
In the expense card, when a payment is made. The card can be filtered to only allow certains category of merchant. However, the 3 ranges of MCC we not added: - Airlines, air carriers: MCC's from 3000 to 3350 - Car Rental Agencies: MCC's from 3351 to 3500 - Lodging, hotels, motels and resorts: MCC's from 3501 to 3999 And since the MCC are not present in the list, they are rejected by default even the card is set to accept all MCCs. task-5486945 Forward-Port-Of: odoo/enterprise#114154
This update fixes a technical issue in the l10n_co_dian module that caused incorrect string comparisons. The change ensures accurate data processing within the Dian tax reporting system, preventing potential errors and ensuring compliance. This resolves a previously identified bug impacting the functionality of the module.
Original PR description
Issue: commit 780b12ca7e2525bfa86f00d232fa9f186c914a85 introduced incorrect string comparison opw-6077050 Forward-Port-Of: odoo/enterprise#115354
This update reverts changes made by Weblate to several Odoo modules, which were incorrectly applied. This ensures the correct functionality of these modules is restored. The reversion addresses an internal issue with Weblate's automated changes.
Original PR description
This reverts part of commit 685f39aa747097b3a2352ebe2935da77b340b52f. For some reason Weblate reverted changes to unrelated files. We revert them back here.
This update corrects a bug in the demo data for flexible calendars. Previously, the demo calendar lacked a specified 'hours_per_week', leading to incorrect day calculations and preventing time off requests from being approved. This fix ensures accurate time off calculations for flexible schedules, resolving a common user issue.
Original PR description
Currently the demo 'Flexible 40 hours/week' calendar has no `hours_per_week` specified. This field is not computed for flexible calendars since https://github.com/odoo/odoo/pull/219608. This results in any number of days taken off being set to 0, and thus unable to be approved. This is computed in the method `_attendance_intervals_batch()` https://github.com/odoo/odoo/blob/2008c391691e8cbeaaee07dadbe66cc9cb63092f/addons/resource/models/resource_calendar.py#L424 **Steps to reproduce:** - Go to any employee and change the Working Hours to Flexible 40 h/week in Payroll>Schedule - Go to Time Off>Managment>Time off and create a new record - Set the employee for which you changed the schedule and set the interval to at least two days. - You will see that the total will be shown to be 0 days, and if you try to approve you will get an error. opw-6034782 Forward-Port-Of: odoo/odoo#256680
This update fixes an issue where power buttons in the Knowledge editor were being hidden due to incorrect boundary calculations. The change ensures that buttons remain visible even with margins applied to the editable area, improving the user experience.
Original PR description
**Current behavior before PR:** - Power buttons in Knowledge were hidden incorrectly because `editableRect.width` was used as the boundary. Since the editable area has margins applied, this width no longer reflects the actual boundary, causing buttons to be hidden. **Desired behavior after PR is merged:** - Use `editableRect.right + referenceRect.left` instead of `editableRect.width` to determine the correct boundary, ensuring power buttons remain visible in when editable area has margin applied to it. task-6102944 Forward-Port-Of: odoo/odoo#259532
This update resolves two critical bugs impacting the Barcode app's functionality within Manufacturing Orders. Previously, changes to the UoM after confirmation were not reflected, and typed quantity values in the production stage would reset. The fix ensures UoM changes are correctly applied and that user-entered quantities are preserved, improving data accuracy and workflow efficiency.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during sales, preventing duplicate entries and maintaining accurate fixed asset and depreciation calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115115
This update corrects a potential error in the account reporting module that could occur when clients use custom fields with the same name as standard Odoo fields. The fix ensures that column references are clearly defined, preventing conflicts and ensuring accurate report generation. This improves data reliability for our clients.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
This update fixes an issue where payment methods weren't correctly displayed for branch companies within Odoo. Now, when working with a branch company, the 'Payment Method' field in the partner and account move forms will consistently show available methods from the parent company, ensuring accurate financial processing.
Original PR description
**Steps to reproduce:** - Install Contacts and Accounting - Create a branch company - Switch to the branch company **Issue:** In the partner form, "Payment Method" field doesn't propose the methods coming from the parent company. Same issue on the account move form. However, in the payment wizard opened from an invoice, the payment methods from the parent company are available. The behavior should be consistent. The payment methods from the parent company should be available from a branch company opw-6001573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260168