Daily updates from Odoo
Monday, April 20, 2026
151 changes
15 changes
Resolved issues and error corrections
This update prevents an error when incoming Chilean electronic invoices are processed without a specific LATAM purchase journal configured. It ensures the system selects a valid default journal so invoices can be created and recorded normally.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041 Forward-Port-Of: odoo/enterprise#112168
This change corrects how landed costs are calculated when a bill is entered in a different currency than the company’s currency. It prevents the amount from being overstated, so the landed cost now matches the intended purchase price and avoids incorrect inventory costing.
Original PR description
Issue introduced by commit daf196e365f481ffcc8b56664fa361fa9c9bbda9
Steps to reproduce:
- Enable two currencies (e.g., USD and EUR)
- Set exchange rate: 2 EUR = 1 USD
- Set current company currency to USD
- Create a service product "Landed Cost":
- Purchase tab:
- Mark as "Is a Landed Cost"
- Cost: $10
- Create a bill:
- Vendor: any vendor
- Currency: EUR
- Add 1 unit of "Landed Cost" → correctly shows 20 EUR
- Click the "Create Landed Cost" button
Expected behavior:
Landed cost should be calculated as $10
Actual behavior:
Landed cost is incorrectly calculated as $40, because the AML (Account Move Line) price subtotal is multiplied by the currency exchange rate (2) instead of dividing.
opw-6121706
opw-6121407
Opw-6124771
Opw-6123193
Forward-Port-Of: odoo/odoo#259632When users save certain website snippets as custom snippets, they will now appear both in the block list and in the inner content list when appropriate. This restores the expected behavior and makes reusable snippets easier to find and use while editing a website.
Original PR description
Steps to reproduce: 1. Go to Website > Edit mode. 2. Drag and drop a `Map` from `Inner Content` snippets. 3. Save it as a custom snippet. Current behavior: - The custom snippet is saved only as inner content and does not appear as a block in custom snippets. Expected behavior: - The snippet should be available both as a block and as inner content, consistent with behavior in `saas-18.3`. Issue: - Custom inner content snippets were systematically extracted from `snippet_custom`. As a result, snippets that can serve both purposes were only kept as inner content, preventing their usage as blocks. Solution: - Update the logic to: 1. Keep dual-purpose snippets in `snippet_custom` (block usage). 2. Also add them to `snippet_custom_content` (inner content usage). 3. Remove only inner-only snippets from the block category to avoid display issues. task-6064917 Forward-Port-Of: odoo/odoo#259588 Forward-Port-Of: odoo/odoo#256777
This change prevents database synchronization from failing with an error when the user no longer has access, when a new document arrives from a remote database, or when the remote database cannot be reached. Instead, the sync now finishes cleanly and correctly reflects any loss of access from the remote side.
Original PR description
The aim of this commit is to allow a db_user to synchronize a database without facing a Traceback. Context: - A new document has been received by a remote db and we try to synchronize it. - The current user access has been removed from the remote db. - The database is unreachable. Before this commit: In all 3 previous cases, an access error would be raised because a db_user can't write on a database. After this commit: The synchronization finish gracefully and the db_user should have lost his access if it was removed from the remote db. task-id: 6046087 Forward-Port-Of: odoo/enterprise#114129 Forward-Port-Of: odoo/enterprise#113826
This change updates the rules for creating asset entries so they depend on how an account is configured, not on whether it was used in older records. This prevents customers with legacy asset data from being blocked from creating new assets, and also keeps certain configured accounts out of the depreciation selection list.
Original PR description
This commit fixes the `can_create_asset` flag on accounts to limit the creation of asset based on if account is used as an accumulated depreciation on another account, instead of used by an asset. This requirement came after users with old assets couldn't create assets using some accounts because they were used by the old assets with no possible way to change that. Better to limit on configuration data instead of business data. Also now, accounts that have models set do not show up in the accumulated depreciation dropdown. no-task
This update adds the unit of measure information to the data sent to ECPay, so invoice lines are easier to understand. As a result, the printed invoice now shows the item’s unit alongside the existing product details, reducing confusion for recipients.
Original PR description
Issue: -- The documents returned by the ECpay API can be confusing as it does not include the measurement (UOM). The make it clearer a description is provided to ECpay through the json with the Key "ItemRemark" Current behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 Expected behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 商品單位: Units opw-6070269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259536
This change prevents an employee holiday pay field from being read too early during payroll updates. As a result, the value is now calculated at the right time, which avoids incorrect payroll results and related test failures.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
The Dutch ICP report now uses the same rounding method as the export files, rounding amounts down to whole numbers. This removes confusing differences between the report and the submitted export, helping users verify figures more easily.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#114277 Forward-Port-Of: odoo/enterprise#112953
The Point of Sale session report now calculates discount amounts more accurately when fiscal positions change the taxes applied to an order. This ensures the report matches the real sales data and avoids incorrect discount figures in end-of-session summaries.
Original PR description
Steps: ---- - Create a fiscal position with 2 different taxes - Add a line in POS - Apply fiscal position and add line discount - Finish the order cycle - Download the session report Issue: ---- - The discount amount was calculated incorrectly in the session report Cause: ---- - The discount amount calculation used taxes before applying the fiscal position Fix: ---- - Used `tax_ids_after_fiscal_position` for tax calculation while computing the discount amount task-5421215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256704 Forward-Port-Of: odoo/odoo#244650
This change fixes a testing issue where repeated test attempts could accidentally reuse leftover state from a previous run and cause confusing failures. By recreating the test for each retry, the test process is more reliable and easier to trust.
Original PR description
The autoretry don't recreate the test instance meaning that some pollution can remain there breaking the next test with a strange error. This pr recreates the test instance for each retry to avoid this kind of issue, and move the retry mechanism to the suite level. The core part of the fix is `test = test.__class__(test._testMethodName) # re-create the test to reset its state` While on it, moving the retry mechanism in the test suite since it makes more sense and allow a better control on what is retried or not since we don't rely on inheritance, and avoid dirty code with super(test) call to recreate the instance and execute it again. The tests needs to be adapted since the retry attribute is now in the loop, but we can have a quite reliable way to know if we are in a retry or not using inspect. Forward-Port-Of: odoo/odoo#258833
If the connection drops while waiting for a Viva.com payment confirmation, the POS now keeps checking instead of stopping too early. This reduces the risk of a customer being charged on Viva.com without the payment being confirmed in the point of sale, while also showing a one-time warning that connectivity was lost.
Original PR description
When a payment was sent to Viva.com and the connection dropped before receiving confirmation, the polling loop in waitForPaymentConfirmation would stop because _handleOdooConnectionFailure set the payment status to "retry" and rejected the promise. This left the payment debited on Viva's side but unconfirmed in the POS. Now the polling uses a direct silent ORM call instead of _call_viva_com to avoid triggering _handleOdooConnectionFailure. On connection failure, the poll silently retries on the next interval until a definitive success/failure response is received. A one-time warning notification informs the user that connectivity was lost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259564
This change prevents discounts from being recalculated and cleared on optional sales lines when a portal customer updates the quantity. It helps preserve the expected pricing on quotes and avoids confusing changes for customers and sales teams.
Original PR description
Issue: --- Discount compute depends on `product_uom_qty`. On optional lines, this recompute will reset the discount on lines, when portal user updates the quanity. Cause: --- `discount` needs to depend on `product_uom_qty` because discount needs to be computed based on the quantity due to pricelist rules. Fix: --- We can prevent this compute if the quantity update comes from portal. opw-6078083 Forward-Port-Of: odoo/odoo#259696
This change fixes an issue where exporting account reports could fail when a fiscal year date was included. Users will now be able to export these reports without encountering a JSON processing error.
Original PR description
When calling export_file with a fiscal year set we pass a fiscal year into it. This function then calls json.dumps with the date object passed into it through a dictionary, which json.dumps cannot process and users experience an error. https://drive.google.com/file/d/1VBOIAxuzcXT5b5BBnLDqd6ibWqOPxe4P/view?usp=drive_link
The website editor now correctly treats buttons with size or shape classes as custom buttons. This prevents the wrong style from being shown in the button settings popover and keeps the editor behavior aligned with how those buttons are actually built.
Original PR description
Before this commit: Since the removal of button style options for the preset primary and secondary styling, the type of a primary/secondary button with size or shape defined in the class should be "custom". The fix is made to saas-18.4 cause the custom button option is removed in saas-18.3 and reintroduced only from saas-18.4. The button option removal commit: https://github.com/odoo/odoo/commit/a7b71d700e4997e4a2f646e2ae12f58f20058dc4 The button custom option reintroduction: https://github.com/odoo/odoo/commit/ea22b28bbae009c9eab4ff397affa9a3cb71037a After this commit: when the button has size or shape classes, we consider it as "custom" button. task-6061443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257410 Forward-Port-Of: odoo/odoo#256015
Users can now edit website profiles from mobile devices without encountering an error. This aligns the mobile experience with the desktop flow, so profile updates work consistently across devices.
Original PR description
# How to reproduce - Install the eLearning module - On the website, go to the Courses tab - View a user (Administrator for example) - In mobile view, click on Edit # The problem An traceback is shown and the user cannot edit their profile # Why This commit (https://github.com/odoo/odoo/commit/69785c1a64d61f2831804bcdcc4887ad43d27fbb) improved the profile edition. It is mentioned that they moved away from the simple bootstrap modal and used an OWL view instead. However, for the mobile view, they left a call to a modal that does not exist. This fix removes the call to the undefined modal and replaces it with the same OWL Dialog used in the desktop view (thanks to the .o_wprofile_editor class) opw-5960586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251503
19 changes
Resolved issues and error corrections
This update corrects a problem with the message right-click menu so it behaves as expected again. It helps users quickly access message options without interruptions or unexpected behavior.
The Dutch ICP report now uses the same downward integer rounding as the tax export. This keeps the reported amounts consistent and avoids confusing differences between the report and the exported figures.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
This fix allows Belgian companies to change their fiscal localization from Companies to Associations and Foundations without failing during the chart update. It removes hidden links to old accounting settings first, so the change completes successfully and existing cash rounding remains intact.
Original PR description
### Issue before this commit: Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The…
### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.
### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?
### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67
### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.
opw-6050537
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Mercado Pago webhook calls from failing when the linked invoice reference contains slashes, such as INV/2026/00001. As a result, payments and invoice updates can be processed correctly instead of being rejected with a 404 error.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259530 Forward-Port-Of: odoo/odoo#259378
This update corrects the appearance of contract-related buttons on the employee form so they display consistently with the rest of the interface. It also prevents the “New Contract” label from wrapping awkwardly on smaller screens, improving readability and usability.
Original PR description
- Add `text-nowrap` to the "New Contract" button to prevent text from splitting at narrow viewport widths - Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488 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
This change prevents a checkout failure that could happen when buying an event booth using a company account. If one of the company’s contacts already has an active user, Odoo now avoids archiving that partner incorrectly, so payment can complete normally.
Original PR description
Use case: - considering a database where `website_event_booth_sale` is installed - considering a company (ACME Corp., email: info@acme.example.net) and it's contact `Roger` (which have a valid user). then: - As an anonymous user, go to an event with some booth to register - register a booth and enter the company information (important: use the company email: info@acme.example.net, this way the cart is created the company as the `partner_id` !!!) - you are redirected to the cart - try to pay it, and upon payment you have the following error: ``` You cannot archive contacts linked to an active user. You first need to archive their associated user. ``` This commit ensure we also check if any contact of the commercial partner have any user before trying to archive them all. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents time off-related calendar events from being shown as suggestions in the Timesheet Assistant. It helps users avoid confusing or incorrect entries when reviewing timesheets for a day with approved time off.
Original PR description
Steps to Reproduce:
---
1. Book a time off for any day via the Time Off app.
2. Open the Timesheets app for that same day.
3. Open the Timesheet Assistant suggestions panel.
Current Behavior:
---
The assistant surfaces the calendar event generated by the Time Off app as a
timesheet suggestion, e.g."Calendar Event - Mitchell Admin on Time Off : 1 days"
Expected Behavior:
---
Calendar events created by time off requests should not appear as
timesheet suggestions.
Issue:
---
The get_calendar_events getter in timesheet_grid_calendar fetched all calendar event
for the user without filtering by res_model, so time off meetings were included.
Fix:
---
Add ("res_model", "!=", "hr.leave") to the calendar.event search
domain.
task-6117932The contract template button on employee forms now matches the surrounding interface better. This fixes an inconsistent appearance by removing incorrect styling classes and aligning the button’s text size and border with the rest of the page.
Original PR description
Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488
This fix prevents discounts on optional sales lines from being recalculated unexpectedly when portal users change quantities. It helps preserve the intended pricing shown to customers and avoids discount values being reset during updates.
Original PR description
Issue: --- Discount compute depends on `product_uom_qty`. On optional lines, this recompute will reset the discount on lines, when portal user updates the quanity. Cause: --- `discount` needs to depend on `product_uom_qty` because discount needs to be computed based on the quantity due to pricelist rules. Fix: --- We can prevent this compute if the quantity update comes from portal. opw-6078083 Forward-Port-Of: odoo/odoo#259696
This change prevents an employee payroll field from being calculated too early, before the necessary payslip data exists. As a result, Belgian holiday pay values are now computed at the right time, avoiding incorrect results and test failures.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
This change corrects a barcode value used in an automated Point of Sale test so it matches the barcode format expected by the scanner. It helps ensure the test accurately reflects real scanning behavior and prevents false failures in the POS test suite.
Original PR description
The test_GS1_pos_barcodes_scan was failing because the "GS1 Variant Product" barcode was defined as a 13-digit string, while the tour scans it using the GS1 AI 01 (GTIN), which expects a 14-digit GTIN-14. By adding a leading zero to the barcode in the test setup, we align it with the GTIN-14 format parsed by the POS barcode parser during the scan, ensuring the product is correctly added to the order. runbot-error: 242323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258089
The rental report now shows the correct date on each daily line for rental orders. This fixes a display issue where every line was using the same start date, making the report harder to read and less accurate.
Original PR description
The rental report is a daily report with x rows by rental order, with x the days between the start and return dates. With generate_series inside the select, the query was creating x rows with the same id, resulting in the date field not being correctly displayed (one unique date, the start date). This fix corrects the generation of the report to display the real date on each row. opw-5266525 Forward-Port-Of: odoo/enterprise#106088 Forward-Port-Of: odoo/enterprise#104764
This change adds the product unit of measure to the information sent to ECPay, so invoice lines are easier to understand. It helps customers and support teams see what the quantity refers to when reviewing the resulting document.
Original PR description
Issue: -- The documents returned by the ECpay API can be confusing as it does not include the measurement (UOM). The make it clearer a description is provided to ECpay through the json with the Key "ItemRemark" Current behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 Expected behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 商品單位: Units opw-6070269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259536
The color picker now stays open when users change the color of an inserted icon. This fixes a frustrating issue in the note editor where hovering a color would close the picker immediately instead of applying the selection.
Original PR description
Commit [1] did already fix this problem, but commit [2] broke it again. This commit restores the condition that was removed by [2] but adapts it slightly in order to only take into account the direct children of the node, instead of any sub-node when checking for the presence of icons. Steps to reproduce: - Go to a "To do" note - Insert an icon with /media - Select the icon - Open the color picker - Hover a color => Color picker closed right away [1]: https://github.com/odoo/odoo/commit/1adfd9b9daf09c26ad642faf411574123110b9be [2]: https://github.com/odoo/odoo/commit/85688ffd11a3a988bf32c8c923a4628a89b57f87 task-6128069 Forward-Port-Of: odoo/odoo#259644
The BoM Overview now handles companies that do not yet have a warehouse configured, instead of showing an error. In that case, product availability is shown as not available, which keeps the overview usable and avoids a blocked workflow.
Original PR description
**Steps to Reproduce:** - Install MRP module. - Create a new company and switch to it. - Create a new BoM. - Click on the "BoM Overview" smart button. **Error:** `IndexError - list index out of range` **Cause:** When a new company is created, no warehouse is automatically generated for it. If no warehouse is configured for the company, the list is empty, causing an error. **Fix:** This commit raises a redirection warning if no warehouse is linked with the company. sentry-7286332859 Forward-Port-Of: odoo/odoo#250602
This update prevents duplicate payment instruction IDs in SEPA files when one payslip is split across multiple bank accounts. It helps ensure payment files comply with bank requirements and avoids export issues, while leaving single-account salary payments unchanged.
Original PR description
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is…
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is based on the payslip ID When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers https://knowledge.xmldation.com/support/iso20022/general_rules/instrid This commit adds a unique suffix (e.g., -1, -2) to the `InstrId` for each transaction generated from the same payslip to ensure technical uniqueness Nothing change when you only have one account This is the part of the code that use the payment name: https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299 ### Steps to reproduce: - Install `hr_payroll_account_iso20022` with demo data - On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number` - Open the Employee page for Abigail Peterson - In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any) - Click on Salary Allocation and Save (You'll have a 50/50 ratio) - Create a new Pay Run (for Abigail Peterson) - Open the last PaySlip and Validate - Create Payment Report (Export Format: SEPA) - Download the Payment Report and check the <InstrId> tags opw-6069670 Forward-Port-Of: odoo/enterprise#113113
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
LinkedIn account imports now skip image records that do not include a download link instead of crashing. This prevents the connection process from stopping unexpectedly and helps more LinkedIn accounts connect successfully.
Original PR description
When importing a LinkedIn account, Odoo fetches the image metadata of the organization page and expects each returned image to contain `downloadUrl`. For some LinkedIn accounts this key is missing from the image response, which makes the callback crash with `KeyError: 'downloadUrl'` and prevents the account from being connected. LinkedIn's current Images API documentation describes `downloadUrl` as an optional field, so the import flow should not assume it is always present. This patch skips image entries without `downloadUrl` instead of crashing. opw-6099244 Forward-Port-Of: odoo/enterprise#113812
The CRM onboarding tour was adjusted so the extra lead-generation steps run at the end instead of in the middle. This prevents the tour from getting stuck repeating steps, making the guided experience more reliable for users.
Original PR description
The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and…
The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and loop on itself. Why? For the tour to wait for the next step, we specify the selectors it should look for. In this case, because the modal redirects to the same page (with an updated domain), we cannot specify a selector that would be unique to the new page -> the target is found before the redirect -> after the redirect happens, the tour backtracks to try and recover, causing the loop. Moving the steps to the end of the tour fixes the issue. The disadvantage of this is that no the last step of the tour is not deterministic - it can fail if the user selects a combination of countries and industries which have no valid leads (Antarctica...) or if the user doesn't have enough IAP credits. In this case, the 'Congrats' rainbowman is shown even if the generation failed. Task-5386684 Forward-Port-Of: odoo/odoo#249733
9 changes
Resolved issues and error corrections
The Dutch ICP report now uses the same rounding-down rule as the export files. This avoids confusing mismatches between the report and the submitted amounts, making the figures easier to trust and reconcile.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
The comparison view in tax reports now works correctly even when a report line contains text instead of only numbers. This prevents the report from crashing when users compare against one past period, so they can review results without interruption.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#113330 Forward-Port-Of: odoo/enterprise#112619
This update corrects ISO20022 payment files so currencies like JPY are exported with the proper number of decimal places. It prevents bank rejections caused by amounts being formatted with two decimals when the currency should not have them.
Original PR description
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3.…
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849 Forward-Port-Of: odoo/enterprise#113296
This change removes a tracking setting from a payroll field so it is no longer read too early in the employee update flow. As a result, holiday pay values are calculated at the right time and payroll tests and outputs stay accurate.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
The manufacturing report now converts unit quantities correctly when products are tracked in different units of measure. This fixes incorrect totals and averages in report groupings, so production figures and cost analysis are reliable again.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#113979When a delivery is scanned using a packaging barcode, the system now correctly keeps the due date from the barcode when creating the lot. This avoids lots being created with the wrong expiration date and helps ensure inventory tracking stays accurate.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#113136
Forward-Port-Of: odoo/enterprise#112490When a subscription payment is processed through certain bank settings, the related invoice could stay marked as unpaid even though the payment succeeded. This fix ensures the invoice is properly matched with the payment so customers and teams see the correct payment status.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303 Forward-Port-Of: odoo/enterprise#110656
This update prevents Documents files from being disrupted when a sign template is created or deleted. It also keeps signature requests correctly linked back to the original document even when multiple templates are created from the same file.
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#11316715 changes
Resolved issues and error corrections
This change ensures that when aggregate withholding is turned on, the aggregation period must also be filled in. It prevents invoice creation from failing with an error if that required field was left empty.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors. Forward-Port-Of: odoo/odoo#259737 Forward-Port-Of: odoo/odoo#259634
When a GS1 barcode includes a product packaging, lot number, and due date, the system now correctly keeps the due date when creating the lot. This avoids setting the expiration date to today by mistake and helps warehouse teams record product expiry information accurately.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#113136
Forward-Port-Of: odoo/enterprise#112490This update adds the product unit of measure to the information sent to ECPay, making invoice lines easier to understand. As a result, printed documents now show the unit description alongside each item, reducing confusion for customers and accounting teams.
Original PR description
Issue: -- The documents returned by the ECpay API can be confusing as it does not include the measurement (UOM). The make it clearer a description is provided to ECpay through the json with the Key "ItemRemark" Current behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 Expected behavior: -- displayed data in PDF 品名 數量 單價 金額 備註 test 1 5 5 商品單位: Units opw-6070269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259536
This change removes automatic tracking from a payroll field that was being read too early during employee updates. As a result, holiday pay values are now computed at the right time, preventing incorrect payroll calculations and related test failures.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
The Reference field in Inventory move history is now read-only, so users no longer see a field they can edit when changes would not actually be saved. This removes confusion and makes the screen behave consistently with the system's behavior.
Original PR description
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted.…
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted. After saving and reloading the Move History view, the original value was restored. ### Steps to reproduce the issue: 1. Go to Move history in Inventory app 2. Try to change the name of a line and save 3. If you go back to the Move history you can see that the name is not changed ### Cause of the issue: The issue was caused by a mismatch between the stock.move.line.reference field and its target field stock.move.reference. The field on stock.move.line is a related field that appears editable (readonly=False), but the underlying stock.move.reference field was not writable. As a result, user could edit the field but the modifications were ignored, preventing changes from being effectively saved. ### Reason to introduce the fix: The fix ensures that the reference field in stock.move and in stock.move.line are readonly. opw-6055708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256434
This change corrects a test barcode format used by the point of sale barcode scanning checks. It ensures the scanned product is recognized properly during the test, preventing false failures in the POS test suite.
Original PR description
The test_GS1_pos_barcodes_scan was failing because the "GS1 Variant Product" barcode was defined as a 13-digit string, while the tour scans it using the GS1 AI 01 (GTIN), which expects a 14-digit GTIN-14. By adding a leading zero to the barcode in the test setup, we align it with the GTIN-14 format parsed by the POS barcode parser during the scan, ensuring the product is correctly added to the order. runbot-error: 242323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258089
The self-ordering system now sends only the fields the frontend actually needs. This reduces unnecessary data transfer and helps keep the client-side payload simpler and more efficient.
Original PR description
Fix _generate_return_values to remove some fields that are not needed on the frontend Forward-Port-Of: odoo/odoo#259915
This update fixes an automated POS loyalty test that was failing because a customer list in a popup could scroll indefinitely. It helps keep the loyalty feature’s checks reliable so future updates can be validated more safely.
Original PR description
fw-port fails because of infinite scroll in pop modal .modal .partner-list 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#218604
The Bill of Materials overview now handles companies that do not have a warehouse configured. Instead of showing an error, it displays product availability as “Not available” and warns the user about the missing setup.
Original PR description
**Steps to Reproduce:** - Install MRP module. - Create a new company and switch to it. - Create a new BoM. - Click on the "BoM Overview" smart button. **Error:** `IndexError - list index out of range` **Cause:** When a new company is created, no warehouse is automatically generated for it. If no warehouse is configured for the company, the list is empty, causing an error. **Fix:** This commit raises a redirection warning if no warehouse is linked with the company. sentry-7286332859 Forward-Port-Of: odoo/odoo#250602
When invoice lines are grouped during UBL/CII import, the tax total is now adjusted so it stays accurate after grouping. This prevents small but important discrepancies in reported tax amounts and improves the reliability of imported invoices.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#257581 Forward-Port-Of: odoo/odoo#252719
When an invoice is sent through Indian E-Invoicing, the IRN number is now saved directly on the invoice record as soon as the response is received. This means users can see the same information in both the PDF and the invoice form, improving consistency and making invoice tracking easier.
Original PR description
**Steps to reproduce:** * Install module *Indian E-Invoicing (l10n_in_edi)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * No specific condition existed in the invoice flow to store the *IRN number* in the corresponding field, even though the value was available in the EDI response. **Fix:** * Update *_get_l10n_in_edi_response_json* to store the IRN number directly on the invoice when the response is received. * This ensures the value is saved without impacting the existing EDI flow. opw-6097923
This update fixes where the 12% I tax amount appears in the Philippine SLSP report. It now shows under "Purchase of Other than Capital Goods" instead of "Purchase of Capital Goods," helping ensure the report matches the correct category.
Original PR description
Before this commit: - The amount of tax '12% I' is shown under 'Purchase of Capital Goods'. After this commit: - The amount of tax '12% I' is shown under 'Purchase of Other than Capital Goods'. task-6092566 Forward-Port-Of: odoo/enterprise#113810
This change updates the classification of the 12% tax entry used in the Philippine localization from “Capital 12%” to “VAT 12%”. It helps ensure the sales report uses the correct tax grouping, reducing confusion and improving reporting accuracy.
Original PR description
In this commit: - We change the group of tax '12% I', from 'Capital 12%' to 'VAT 12%' task-6092566 Forward-Port-Of: odoo/odoo#259145
This fix ensures that preparation printers display the correct attribute value for instant variants selected within a combo. As a result, kitchen or prep staff can see the exact variant ordered instead of only the base product name, reducing confusion and order mistakes.
Original PR description
Before this commit, the preparation printer did not display the attribute value for an instant variant added inside a combo choice. This occurred because the attribute value was not properly set on the variant order line. Steps to reproduce: * Create a PoS product with multiple variants. * Create a combo product with a choice containing the variants. * Configure a preparation printer. * Open a PoS session and order the combo. * The printer displays only the base product name. opw-5949132
3 changes
Resolved issues and error corrections
This fix prevents Point of Sale from crashing when a payment is cancelled directly on the payment terminal instead of in the POS screen. It improves reliability for cashiers by handling this cancellation case cleanly and avoiding an error message.
Original PR description
Currently if you cancel a transaction on the terminal (not in pos) this lead to a traceback TypeError: this.cancel_resolve is not a function at Proxy._waitingPayment (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16764:298) at Proxy._onValueChange (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16758:184) at Proxy._onSuccess (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16674:190) at Proxy._onSuccess (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16778:1228) at https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16672:417 This PR fixes the issue to ensure the scenario when the pos didnt ask for cancellation is managed Forward-Port-Of: odoo/enterprise#114215
This update moves the tax amount for “12% I” to the correct section of the Philippine SLSP report. It now appears under “Purchase of Other than Capital Goods” instead of “Purchase of Capital Goods,” ensuring the report is more accurate for business reporting and compliance.
Original PR description
Before this commit: - The amount of tax '12% I' is shown under 'Purchase of Capital Goods'. After this commit: - The amount of tax '12% I' is shown under 'Purchase of Other than Capital Goods'. task-6092566 Forward-Port-Of: odoo/enterprise#113810
This update corrects an automated test in the salary package module so it no longer depends on sample data being installed. As a result, the test is more reliable and can run successfully in standard environments.
Original PR description
### Issue: - We were referring an existing XML ID in our test case, but that record is only created in demo data. ### Fix: - No need to use the demo record Id, instead, create a new record. Task: 6115762 Forward-Port-Of: odoo/enterprise#113622
17 changes
Resolved issues and error corrections
The Dutch ICP report now rounds amounts down to whole numbers, matching the rounding already used in exports. This reduces confusion and helps businesses compare report and export values consistently for Dutch tax reporting.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#114277 Forward-Port-Of: odoo/enterprise#112953
Payment reminder emails for subscriptions now avoid showing the exact automatic cancellation date until the final 24-hour reminder. This helps encourage earlier payment while also fixing cases where a zero-day grace period was incorrectly treated as the default delay.
Original PR description
- Hide close date until final 24h payment reminder: This commit updates the payment reminder logic to only expose the contract closing date precisely 24 hours before the subscription is automatically cancelled. By hiding the date during the earlier standard reminders, we create urgency without encouraging procrastination. It also fixes a native Python evaluation bug where an auto-close limit explicitly set to zero days would be treated as "falsy" and incorrectly default to a 15-day grace period. Both manual payments and tokenized payment failures have been updated to follow these new rules. task: 5902221
Payments dated in the future are now excluded from Mexico CFDI payment signing, preventing users from accidentally submitting documents that government rules do not allow. The invoice action to update payments will not appear when only future payments exist, and future payments are ignored when eligible payments are processed.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#114074 Forward-Port-Of: odoo/enterprise#112320
A payroll employee field in Belgian localization was being checked too early, before the needed payslip data existed. This change prevents that premature check so holiday pay recovery values are calculated at the right time, improving reliability of payroll tests and results.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
Subscription payments using a bank default account are now automatically matched with the related invoice. This prevents paid subscription invoices from incorrectly remaining marked as not paid, reducing manual follow-up for finance teams.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303 Forward-Port-Of: odoo/enterprise#110656
Asset creation eligibility for accounts is now based on whether an account is configured as accumulated depreciation on another account, rather than whether it was used by existing assets. This prevents legacy asset records from blocking valid new asset creation and keeps depreciation account choices clearer.
Original PR description
This commit fixes the `can_create_asset` flag on accounts to limit the creation of asset based on if account is used as an accumulated depreciation on another account, instead of used by an asset. This requirement came after users with old assets couldn't create assets using some accounts because they were used by the old assets with no possible way to change that. Better to limit on configuration data instead of business data. Also now, accounts that have models set do not show up in the accumulated depreciation dropdown. no-task Forward-Port-Of: odoo/enterprise#114096
This update fixes an error that could block upgrades of the Accounting Reports module. It ensures required report grouping data is correctly set, helping upgrades complete smoothly without manual intervention.
Original PR description
Bug introduced by odoo/enterprise#113124, when trying to upgrade the module `account_reports`, traceback error: > psycopg2.errors.NotNullViolation: null value in column "horizontal_group_id" > of relation "account_report_horizontal_group_rule" violates not-null constraint.
The Documents mobile search panel now opens folder sections correctly again, including company and other grouped values. This also restores missing section icons and improves styling and keyboard navigation for a smoother mobile experience.
Original PR description
Follows the changes made in community and fixup some styling introduced in commit[1] - remove unneccessary styling - rescope styling in right files - fixup the searchpanel inside the bottom sheet task-6090140 [1]: odoo/enterprise@c573cd168e2e01bb9390ef7aae714688100fb2ae Community PR: https://github.com/odoo/odoo/pull/257378
Database synchronization no longer fails with an error when a user loses access, receives a new remote document, or the remote database cannot be reached. This helps users complete synchronization cleanly and ensures removed access is reflected without a disruptive traceback.
Original PR description
The aim of this commit is to allow a db_user to synchronize a database without facing a Traceback. Context: - A new document has been received by a remote db and we try to synchronize it. - The current user access has been removed from the remote db. - The database is unreachable. Before this commit: In all 3 previous cases, an access error would be raised because a db_user can't write on a database. After this commit: The synchronization finish gracefully and the db_user should have lost his access if it was removed from the remote db. task-id: 6046087 Forward-Port-Of: odoo/enterprise#114204 Forward-Port-Of: odoo/enterprise#113826
Unpaid work entry types are now properly linked to the Belgium monthly employee pay structure. This prevents unpaid absences from being incorrectly included in payslip payments, improving payroll accuracy for Belgian employees.
Original PR description
Work entry types with "unpaid" in their name were not linked to the "Belgium: Employees Monthly Pay" structure, causing them to still be paid during payslip computation. task-6123817
The Time Off overview no longer crashes when a new company or localization has no time off records yet. This ensures users can open the dashboard normally even before any time off data has been created.
Original PR description
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot…
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot destructure property 'type' of 'fields[fieldName]' as it is undefined. Cause: Following the recent work entries refactoring, the JS function `_fetchUserFavoritesWorkEntries` was added to the base `HrHolidaysGanttModel` to fetch data from the `hr.leave` model. When the Dashboard (`hr.leave.report.calendar`) has 0 records, the frontend `SampleServer` is activated to generate fake background data. It builds its schema based on the Dashboard view. When the JS unconditionally fires the cross-model RPC call to `hr.leave` (grouping by `work_entry_type_id`), the `SampleServer` intercepts it. Because it doesn't have `work_entry_type_id` in its Dashboard schema, it fails to evaluate the field type and crashes the Owl lifecycle. Solution: Restrict the `_fetchUserFavoritesWorkEntries` call in `_fetchData` so it only runs when not using sample data (`!this.useSampleModel`). This prevents the `SampleServer` from intercepting unsupported cross-model queries to `hr.leave` when loading empty views on fresh databases. task-5969290 Forward-Port-Of: odoo/enterprise#108618
The rental duration test has been adjusted to avoid occasional failures caused by timezone differences around midnight. This helps keep automated validation stable without changing the customer-facing rental experience.
Original PR description
The rental test intermittently fails on Runbot due to timezone offsets. Near midnight, the start time can appear after the end time, causing the datepicker to auto-shift the end date by 24h. This commit uses `getFutureDate` to set full future datetimes, bypassing browser timezone and midnight crossover issues. Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/242000
Customers booking appointments can use quick checkout by default, avoiding repeated requests for full billing address details. This improves the booking and payment experience where taxes are typically based on the event or appointment location rather than the customer address.
Original PR description
Forward-Port-Of: odoo/enterprise#114205 Forward-Port-Of: odoo/enterprise#113575
Odoo now handles LinkedIn organization image data more safely when connecting an account. If LinkedIn omits an optional image link, the setup process skips that image instead of failing, helping users complete the connection reliably.
Original PR description
When importing a LinkedIn account, Odoo fetches the image metadata of the organization page and expects each returned image to contain `downloadUrl`. For some LinkedIn accounts this key is missing from the image response, which makes the callback crash with `KeyError: 'downloadUrl'` and prevents the account from being connected. LinkedIn's current Images API documentation describes `downloadUrl` as an optional field, so the import flow should not assume it is always present. This patch skips image entries without `downloadUrl` instead of crashing. opw-6099244 Forward-Port-Of: odoo/enterprise#113812
Australian payroll no longer crashes when an employee contract has a wage but no schedule pay selected. This keeps employee payroll records usable even when pay schedule information is temporarily missing or removed.
Original PR description
This error occurs when the schedule pay is removed from an employee contract with a defined wage. Steps to reproduce: - Install `l10n_au_hr_payroll` module with demo data - Switch to `My Australian…
This error occurs when the schedule pay is removed from an employee contract with a defined wage.
Steps to reproduce:
- Install `l10n_au_hr_payroll` module with demo data
- Switch to `My Australian Company`
- Open any Employee > Payroll > `Wage` remove `schedule pay`
Traceback:
```py
File "/home/odoo/src/enterprise/saas-19.2/l10n_au_hr_payroll/models/hr_version.py", line 549, in _compute_wage
version.wage = Payslip._l10n_au_convert_amount(daily_wage, "daily", version.schedule_pay)
File "/home/odoo/src/enterprise/saas-19.2/l10n_au_hr_payroll/models/hr_payslip.py", line 511, in _l10n_au_convert_amount
coefficient = PERIODS_PER_YEAR[period_from] / PERIODS_PER_YEAR[period_to]
KeyError: False
```
We are encountering this error because the `schedule pay` is removed, causing the field to become `False`. This False value is then passed to the `_l10n_au_convert_amount` [method], resulting in a `KeyError`.
[method]: https://github.com/odoo/enterprise/blob/92c584cc1426ac70f6f77aa8216c17004fa42d35/l10n_au_hr_payroll/models/hr_payslip.py#L500-L509
sentry-7401189447
Forward-Port-Of: odoo/enterprise#113623Studio-created models with Chatter enabled now get the activity filters needed for the activity menu. This means users clicking Late, Today, or Future activities see the correct records instead of all records.
Original PR description
Steps to reproduce
==================
- Install studio
- Create a new app
- Create a new model
- Keep the Chatter toggled (use_mail)
- Exit studio
- Create three records, one with an activity in the past, one today and one in the future
- Click on the clock status icon in the top right
- There should be a section with the new model
- Click on 1 Late => every records is displayed
- Same for Today and Future
Cause of the issue
==================
https://github.com/odoo/odoo/blob/b6434b91a7f94075e1372ec827787504ef7aa4f0/addons/mail/static/src/core/web/activity_menu.js#L39-L77
For this feature to work, the activities_{overdue,today,upcoming_all} filter should be present
Solution
========
We add them to the search view. They are all pretty much implemented the same way in every model.
opw-6069150
Forward-Port-Of: odoo/enterprise#114217
Forward-Port-Of: odoo/enterprise#113011Users can now clear the scope on an ESG emission source without triggering an error. The change keeps related activity flow fields safely empty when no scope is selected, improving reliability while editing ESG records.
Original PR description
Currently, an error occurs when the user removes the scope of the emission source. **Steps to Reproduce:** - Install the `esg` module. - Create an `emission source` record or open an `existing one`.…
Currently, an error occurs when the user removes the scope of the emission source. **Steps to Reproduce:** - Install the `esg` module. - Create an `emission source` record or open an `existing one`. - Remove the `scope` value and click anywhere. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=1>,).activity_flow_direct_indirect` **Cause:** Error started occurring in 19.0 due to a change in selection field behavior. Since from [commit](https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef), selection fields no longer display an “empty” value. To remove a value from a selection field, the user must clear the field, similar to a many2one field. when the user removes the scope value, The system attempts to compute the activity flow, but since the scope is False, it does not match any case [1]. As a result, the method fails to assign a value to activity_flow_direct_indirect, raising an error. This commit ensures that the activity flow and activity flow direct indirect are initialized to False. If no condition matches, the field remains False, preventing the assignment failure. [1]: https://github.com/odoo/enterprise/blob/eaf4b7559b8eb6c538820d6e54f583a41077ac3d/esg/models/esg_emission_source.py#L79-L89 Forward-Port-Of: odoo/enterprise#114079
9 changes
Resolved issues and error corrections
This update prevents an error when saving an appointment that has no organizer assigned but includes a Google Meet link. It also stops template previews from failing in the same situation, improving reliability for users who manage appointments without a linked user.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update ensures that salary payments split across multiple bank accounts receive unique identifiers in the SEPA export. It prevents invalid payment files and helps payroll exports process correctly without affecting employees who use only one bank account.
Original PR description
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is…
### Issue: If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags ### Cause: The `_get_payments_vals` method, `InstrId` is based on the payslip ID When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers https://knowledge.xmldation.com/support/iso20022/general_rules/instrid This commit adds a unique suffix (e.g., -1, -2) to the `InstrId` for each transaction generated from the same payslip to ensure technical uniqueness Nothing change when you only have one account This is the part of the code that use the payment name: https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299 ### Steps to reproduce: - Install `hr_payroll_account_iso20022` with demo data - On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number` - Open the Employee page for Abigail Peterson - In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any) - Click on Salary Allocation and Save (You'll have a 50/50 ratio) - Create a new Pay Run (for Abigail Peterson) - Open the last PaySlip and Validate - Create Payment Report (Export Format: SEPA) - Download the Payment Report and check the <InstrId> tags opw-6069670
This update prevents a crash when users compare a tax report against one past period, including cases where the report contains text values. It makes the comparison view more reliable and avoids an error when Odoo calculates percentage columns.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#113330 Forward-Port-Of: odoo/enterprise#112619
This change prevents an error that could appear when a user removes the scope from an emission source. It keeps the ESG form working smoothly and avoids interruption while editing records.
Original PR description
Currently, an error occurs when the user removes the scope of the emission source. **Steps to Reproduce:** - Install the `esg` module. - Create an `emission source` record or open an `existing one`.…
Currently, an error occurs when the user removes the scope of the emission source. **Steps to Reproduce:** - Install the `esg` module. - Create an `emission source` record or open an `existing one`. - Remove the `scope` value and click anywhere. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=1>,).activity_flow_direct_indirect` **Cause:** Error started occurring in 19.0 due to a change in selection field behavior. Since from [commit](https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef), selection fields no longer display an “empty” value. To remove a value from a selection field, the user must clear the field, similar to a many2one field. when the user removes the scope value, The system attempts to compute the activity flow, but since the scope is False, it does not match any case [1]. As a result, the method fails to assign a value to activity_flow_direct_indirect, raising an error. This commit ensures that the activity flow and activity flow direct indirect are initialized to False. If no condition matches, the field remains False, preventing the assignment failure. [1]: https://github.com/odoo/enterprise/blob/eaf4b7559b8eb6c538820d6e54f583a41077ac3d/esg/models/esg_emission_source.py#L79-L89
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
This change removes automatic tracking from a payroll field that should only be calculated when needed. It prevents the value from being read too early, which was causing incorrect holiday pay results and failed payroll tests.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
Printing accounting reports like customer statements could split a negative amount across two lines, with the minus sign separated from the number. This fix keeps negative values on one line so printed PDFs remain clear and readable.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
Copying helpdesk tickets no longer fails for users who do not have stock permissions. This makes it easier for support teams to duplicate tickets without needing broader access rights, while keeping stock-related information out of the copy when appropriate.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#113564 Forward-Port-Of: odoo/enterprise#101338
This fix ensures that when a subscription payment is completed through a payment setup that skips bank reconciliation, the related invoice is automatically matched with the payment. As a result, invoices no longer stay marked as unpaid after the transaction is done, which avoids confusion and manual follow-up.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303 Forward-Port-Of: odoo/enterprise#110656
10 changes
Resolved issues and error corrections
Mobile users can no longer select combo products directly on the sales order line form. This avoids creating incomplete zero-price lines without the required child items, which could cause errors or incorrect orders.
Original PR description
Combo products bypasses the configurator in mobile view, resulting in a 0-price line with no child lines. Exclude them via domain on the field. opw-5999935
This update fixes an error that could prevent users from generating a W2 CSV file when the End Date field was left blank. If no end date is provided, the system now uses the current year in the file name so the export completes successfully.
Original PR description
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click…
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.
Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.
Error:
```
File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```
Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.
Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.
[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248
No IDThis update prevents the Attendance kiosk from failing when users search for an employee after selecting a department. It improves reliability by skipping invalid search conditions that could previously cause the kiosk to crash.
Original PR description
**Steps to Reproduce:**
1. Install `hr_attendance` module with demo data.
2. Go to Attendances > Kiosk Mode > Identify Manually.
3. Select any department.
4. Try searching for an employee.
**Error:**
`ValueError - not enough values to unpack (expected 3, got 1)`
**Cause:**
The `employees_infos()` controller assumes that every item in the domain is a valid triplet (field, operator, value). However, the domain may also contain logical operators ('&'), which are not triplets. And then trying to unpack such entries leads to a ValueError.
**Fix:**
Add a validation to ensure the condition is a proper triplet before unpacking. Non-conforming entries (logical operators) are skipped.
sentry-7401444075
opw-6113268This update makes an unstable HR leave test run consistently by fixing the date it uses during execution. It prevents random failures caused by weekends or existing demo data, so automated checks are more reliable.
Original PR description
### Issue before this commit: The test test_manager_can_approve_from_leave_report_calendar is unstable and fails depending on the execution date or existing demo data. ### Cause of the issue: The test lacks temporal isolation. Odoo's constraint logic triggers a ValidationError when a leave is requested on a non-working day or overlaps with existing records: odoo.exceptions.ValidationError: The following employees are not supposed to work during that period: David Employee. Commit that caused the error: https://github.com/odoo/odoo/commit/83d5c84fa0ead1557fbb6eff6855f77ee4771dc4 ### Reason to introduce the fix: To ensure test determinism by using @freeze_time. Freezing the date to a known working weekday prevents intermittent failures caused by the real-time calendar and ensures the focus remains on validating the manager's approval flow. runbot-242574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
We fixed an automated test in the salary package module so it no longer depends on demo-only sample data. This makes the test more reliable and helps avoid failures in environments where demo data is not available.
Original PR description
### Issue: - We were referring an existing XML ID in our test case, but that record is only created in demo data. ### Fix: - No need to use the demo record Id, instead, create a new record. Task: 6115762
This update preserves the green link styling in frozen shared spreadsheets while still preventing those links from being clicked. It matters because dashboard layouts keep their intended look without exposing internal navigation from public views.
Original PR description
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 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#256357
This update fixes the Documents app so the browser back button returns users to the previous folder or list instead of reopening the same page. It improves navigation flow and helps users move around Documents more reliably without losing their place.
Original PR description
Bug === When going back in the kanban / list view of the documents module, it reload the same page. Technical ========= They are 2 bugs in reality, not one: - The web client pushes the state in the router when the controller is mounted. This is fine for most Odoo views, but for documents it mean that the kanban view will be restored without the access token in the URL. - When going back, the search model "toggle the category" of the current folder. But, that current folder is not the previous one, and so it re-open the same folder just after redirecting to the previous URL. Task-6050772
This update corrects an issue in the Mexico localization where invoices could end up off by one cent when certain included-tax rates were combined. It restores the expected rounding behavior so totals match the entered price, reducing billing discrepancies for users in Mexico.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_mx. 2. Change the included in price settings to 'Tax included' for a 16% tax and a 53% tax. 3. Create a invoice with a product with a unit price of 360, add the 53% tax and then the 16% tax. 4. Notice the total of the invoice is 360.01 instead of 360. The issue was discussed with (las), l10n_mx_edi should no longer require to override the rounding mode for taxes. opw-5963855
This change updates the Mexican e-invoicing test so it matches the restored rounding behavior. It helps prevent false test failures and keeps the validation aligned with how invoices are now calculated.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855
This change restores the previous way child contact names are shown in invoices and related customer records. It helps ensure contact names appear as expected for users who work with company contact hierarchies.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260065
3 changes
Resolved issues and error corrections
This change rolls back a previous update that altered how child contact names were shown in invoices and partner records. It helps restore the prior display behavior for customers and prevents unexpected name formatting changes in business documents.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567
The system now decides whether to add the co-contractant tax exemption note based on the invoice’s fiscal position instead of the customer’s. This avoids inconsistencies in exported invoice data and helps ensure the legal note matches the actual invoice setup.
Original PR description
The decision to add a tax exemption reason for co-contractant fiscal position was being decided by the FP of the customer which could cause inconsistencies, instead, it is now tied to the FP of the invoice related-task-id-5905176
The Sign app now keeps template tags from overlapping the Template Properties button in the header. This improves readability and prevents layout issues for users in languages with longer labels, such as German.
Original PR description
## Issue In the Sign app, the list of tags of a template can overlap with the *Template Properties* button when using a language that makes those components slightly wider than expected (e.g.…
## Issue
In the Sign app, the list of tags of a template can overlap with the *Template Properties* button when using a language that makes those components slightly wider than expected (e.g. German).
## Steps to reproduce
1. Install Sign (`sign`)
2. Set the language to German
3. Open a template
4. **In the header, the list of tags overlap the _Template Properties_ button**
## Cause
The list of tags uses `col-lg-12`, which is design for Bootstrap's grid system and prevents the div from shrinking properly.
```css
.col-lg-12 {
flex: 0 0 auto; /* flex-shrink set to 0 */
width: 100%;
}
```
## Before
<img width="726" height="67" alt="6023834-1" src="https://github.com/user-attachments/assets/fd49c8d5-4ca0-4de4-8f0c-f03f78f4b7ab" />
<img width="432" height="75" alt="6023834-2" src="https://github.com/user-attachments/assets/d595e8a3-c3ab-4ae2-89dd-652371de9604" />
## After
https://github.com/user-attachments/assets/3a00fc5f-260d-465d-8e12-96d8e6e1aa4c
opw-6023834