Daily updates from Odoo
Wednesday, November 26, 2025
183 changes
21 changes
Resolved issues and error corrections
This update resolves a visual glitch in the Gantt view when flexible working hours are enabled. Previously, the system incorrectly estimated unavailable days, leading to random grayed-out dates. The fix ensures all days are treated as working days, providing a more accurate and reliable Gantt view.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update corrects an error preventing the l10n_vn_edi_viettel module from successfully retrieving invoice documents from the Sinvoice system. The previous issue stemmed from incorrect parameter requirements in the API documentation, which caused a 400 error. This fix ensures accurate document retrieval, improving the functionality of Vietnamese VAT invoice processing.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves a bug that caused errors when using the FedEx delivery method with addresses in Hong Kong, specifically those with a 'Hong Kong Island' state. The fix ensures that the system correctly handles state code splitting, preventing a traceback and ensuring accurate delivery processing for this common address type. This improves the reliability of the FedEx delivery option.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes an issue where channel names weren't displaying correctly in the invite dialogs accessed from the sidebar. The change ensures that channel names are accurately shown, improving the user experience when inviting members to channels. This resolves a visual inconsistency.
Original PR description
Before this commit, certain channels whose names were computed on the client side did not appear correctly as the title of the invite dialog when opened via the sidebar actions. This commit resolves the issue by using the channel’s displayName instead of the thread.name to ensure the correct title is shown in the invite dialog. task-5357104 Forward-Port-Of: odoo/odoo#237278
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The button label has been updated to 'Generate and Copy Payment Link' to match the intended functionality, ensuring users clearly understand how to create and copy a payment link. This improves the user experience and reduces potential confusion.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update corrects a bug where opening a folder within 'My Drive' would automatically unfold the entire 'My Drive' folder. Now, 'My Drive' only expands when its root folders are opened, improving the user experience and preventing unintended folder expansions.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#100213 Forward-Port-Of: odoo/enterprise#93718
This update resolves a minor UI issue within the Documents app, specifically fixing overlapping elements and addressing a broken feature in the activity view. The change ensures the Documents app displays correctly and reliably for users.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112 Forward-Port-Of: odoo/enterprise#86436
This update fixes an error in the Peru tax return reports (RVIE Sales 14.4) that incorrectly included credit note amounts in the VAT columns. The fix ensures the report accurately reflects SUNAT regulations for credit note reporting, improving data accuracy for tax compliance.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466 Forward-Port-Of: odoo/enterprise#96146
This update resolves an issue where invoices using specific document types (201-213) within the l10n_ar module couldn't be printed correctly. The fix ensures the report template correctly handles different Spanish language settings, allowing users to print invoices regardless of the installed language.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228125
This update fixes an issue where vendor bill payment statuses remained incorrect after deleting or resetting payments. The change ensures that the vendor bill's status accurately reflects the payment's state, resolving a discrepancy between vendor and customer invoice updates. This improves data accuracy and reporting.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772 Forward-Port-Of: odoo/odoo#234725
This update resolves an issue with the account follow-up hook installation and uninstallation process. The fix ensures the hooks function correctly regardless of whether the module is installed or not, improving stability and reliability. This change addresses a minor technical problem that could have impacted account management workflows.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term Forward-Port-Of: odoo/enterprise#100350
This update fixes an issue where group chats weren't displaying the correct welcome message and subtitle. The change ensures all channel types receive the appropriate start message, enhancing the user experience for group communication. A new test has been added to verify this fix across all channel types.
Original PR description
Before this commit, The start message subtitle condition was incorrect for group chats, this commit corrects that condition and also add a test to cover all the channel types to show correct start message and subtitle. Before: <img width="625" height="109" alt="image" src="https://github.com/user-attachments/assets/830f9574-573f-4448-b54f-b70c8a4685ef" /> After: <img width="640" height="133" alt="image" src="https://github.com/user-attachments/assets/bcba270a-88fc-446d-9015-1125872c5748" /> Forward-Port-Of: odoo/odoo#237292
This update resolves an issue where importing journal entries targeting inactive accounts previously caused errors. The change now allows these imports to proceed without regard to the account's active status, streamlining the import process. This ensures that all journal data can be imported, regardless of account status.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237271
This update resolves a display issue within the journal items tab of Odoo, preventing sections and notes from being hidden. The change was necessary due to an outdated database field name ('journal_line_ids') still being used, which caused errors when updated to the new standard ('line_ids'). This ensures consistent and accurate reporting of financial data.
Original PR description
Steps to reproduce: --- - Revert the commits - Install `account` module - Undo revert commits and install `l10n_pe_edi` module This error occurs because the field name was changed in stable from `journal_line_ids` to `line_ids`. We cannot do this in a stable version, as older databases still reference the old field name, and renaming it in stable will cause errors. Followup of: https://github.com/odoo/enterprise/pull/99875, https://github.com/odoo/odoo/pull/236457 sentry-7059309576, 7059890988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a display issue where sections and notes were hidden in the journal items tab. The root cause was a change in database field names that created compatibility problems with older versions. This fix ensures correct display of journal items across all versions.
Original PR description
Steps to reproduce: --- - Revert the commits - Install `account` module - Undo revert commits and install `l10n_pe_edi` module This error occurs because the field name was changed in stable from `journal_line_ids` to `line_ids`. We cannot do this in a stable version, as older databases still reference the old field name, and renaming it in stable will cause errors. Followup of: https://github.com/odoo/enterprise/pull/99875, https://github.com/odoo/odoo/pull/236457 sentry-7059309576, 7059890988
This update resolves an issue where rapidly opening the file viewer (like double-clicking attachments) caused the system to crash. The fix ensures the file viewer component is properly cleaned up between uses, preventing registration errors and maintaining stability.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update resolves a problem where the exchange rate was missing on invoices for certain currencies in Odoo versions 17.0 and 18.0. The fix addresses a design conflict within a shared invoice template used across multiple countries, ensuring accurate exchange rate display. This improvement impacts invoicing accuracy for users in Saudi Arabia.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237193 Forward-Port-Of: odoo/odoo#236844
This update resolves a bug that prevented payments using the "Own Checks" method in foreign currencies from posting correctly. The issue stemmed from a minor typo in the code, which caused an imbalance in the accounting entries. This fix ensures accurate payment processing for users utilizing the l10n_latam_check module.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228 Forward-Port-Of: odoo/odoo#236768
This update fixes a problem where vendor bills in the South Africa (SA) localization displayed negative amounts in the currency conversion section when using different currencies. The fix ensures accurate currency calculations and proper bill formatting, resolving an issue that could have impacted financial reporting. This change was made as part of a standard bug fix process.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update streamlines Odoo's logging by reducing the volume of data captured from websocket messages. Previously, full messages were logged, leading to overly detailed and difficult-to-manage logs. Now, only the message type and device are logged at the 'info' level, providing more focused and actionable information.
Original PR description
Before this commit, we logged the full websocket messages received at 'debug' level, and the action device at 'info' level. Logging the whole message causes the logs to be flooded with large base64 print data. After this commit, log the message type and device both at 'info' level. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237337 Forward-Port-Of: odoo/odoo#236651
This update fixes an issue where invoice lines were incorrectly reconciled across different customers during POS sessions. Previously, settling payments mixed invoices from various customers, leading to inaccurate reporting. Now, reconciliation is limited to the specific partner within the POS session, ensuring accurate financial records.
Original PR description
Invoice lines to be reconciled are not tailored to the single partner while the session lines do. That causes reconciliation to happen between different partners. To reproduce: Create an invoice of 100 to Customer 1 and an invoice of 200 to Customer 2. In a pos session, go to Customer 1, settle 50 on that invoice. Go to Customer 2, settle 100 on their invoice. Close register. => Lines from different customer are reconciled together. task-5346644 Forward-Port-Of: odoo/enterprise#100131
22 changes
Resolved issues and error corrections
This update resolves a visual glitch in the Gantt view when flexible working hours are enabled. Previously, the system incorrectly estimated working days, leading to inaccurate grayed-out dates. The fix ensures all days are treated as working days, providing a correct and consistent Gantt view experience.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update fixes an issue where vendor bill payment statuses remained incorrect after deleting or resetting payments. The change ensures that the vendor bill's status accurately reflects the payment's state, resolving a discrepancy compared to customer invoices. This improves data consistency and reporting accuracy.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772 Forward-Port-Of: odoo/odoo#234725
This update corrects a problem preventing Odoo from successfully retrieving invoice documents from the Viettel system. The original issue stemmed from incorrect parameter requirements in the API documentation, leading to errors. This fix ensures accurate document retrieval, improving the functionality of the l10n_vn_edi_viettel module.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves an issue where the Fedex delivery method would fail when used with addresses in Hong Kong, specifically those with a 'Hong Kong Island' state. The fix ensures that the system correctly handles state code splitting, preventing a traceback and ensuring reliable delivery processing for this common address type. This improves the overall reliability of the delivery process.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The button label has been updated to 'Generate and Copy Payment Link' to provide a clearer instruction for users. This ensures a better user experience when generating payment links.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update resolves a bug where automation rules using time-based domains were failing silently due to missing JavaScript functions. The fix ensures that the evaluation context is properly prepared, preventing a 'NameError' and allowing automation rules to trigger correctly. This improves the reliability of scheduled automation tasks.
Original PR description
Steps to reproduce: ------------------- 1. Install `base_automation` and `project` 2. Create a new task with a deadline set to today 3. Create a new automation rule using the operator "today" 4. Set…
Steps to reproduce: ------------------- 1. Install `base_automation` and `project` 2. Create a new task with a deadline set to today 3. Create a new automation rule using the operator "today" 4. Set the trigger to "Based on datetime field" using the `deadline` field 5. Add a filter domain based on the same operator 6. Run the related scheduled action (cron) for automation rules Issue: ------- During cron execution, the automation silently fails with the error: ```python NameError: name 'context_today' is not defined ``` Cause ----- Most of the Time-based domain operators are [introduced from SaaS-18.3 ](1c7c31a)onwards and include values such as [context_today()](https://github.com/odoo/odoo/blob/0a6155ac25aae138bdaa5e2e8a6d39c42acd2fe3/addons/web/static/src/core/tree_editor/condition_tree.js#L84) and `.to_utc()`, which are not present in the Python evaluation context. As a result, safe_eval raises NameError, and the automation rule is never triggered. Solution -------- Prepare the evaluation context with time-based operators and remove unsupported JS-only `.to_utc()` before evaluating the domain in Python's safe_eval, to prevent traceback. opw-5237215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Shift + Click within table cells didn't correctly select text, leading to inconsistent behavior. The fix ensures Shift + Click now functions as expected with standard browsers, providing a more reliable and intuitive text selection experience. Additionally, the fix addresses a related issue where text selections would temporarily disappear when resizing the table.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237168 Forward-Port-Of: odoo/odoo#230716
This update resolves an issue where attachments weren't consistently displayed on leave request forms after saving. The fix addresses a technical limitation in how Odoo handles attachments and ensures that saved leave requests correctly show associated files. This improves the user experience for creating and managing leave requests.
Original PR description
to reproduce: ============= - from form view, create a leave request with an attachment - save the leave request - the attachment is not displayed on the form (reloading the page shows it correctly)…
to reproduce:
=============
- from form view, create a leave request with an attachment
- save the leave request
- the attachment is not displayed on the form (reloading the page shows it correctly)
Problem:
========
- When sving the leave request, we call `web_save` which will handle the creation, then calls `web_read` to read the updated data back from the server.
- Even though `web_read` and `web_save` are called in the same transaction, but `web_read` doesn't see `attachment_ids` because of the limited implementation of Many2oneReference (ir.attachment.res_id):
- Its `_update_inverses` won't be called when the value is changed when `field.write`
- when `record.attachment_ids = attachment`, the ORM won't automatically set `attachment.res_model = record._name`
Solution:
=========
as work arround, we can call `invalidate_recordset` for leave requests after setting `attachment_ids` in `_inverse_supported_attachment_ids` so that `web_read` will read the correct value from database.
opw-5157790
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an error in the Peru tax return reports (RVIE Sales 14.4) that incorrectly included credit note amounts in the VAT columns. The fix ensures the report accurately reflects SUNAT regulations for credit note reporting, improving data accuracy for tax compliance.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466 Forward-Port-Of: odoo/enterprise#96146
This update resolves an issue preventing invoices with specific document types (201-213) in the l10n_ar module from printing correctly. Previously, the system was hardcoded to use Spanish (es_AR), causing errors if that language wasn't installed. Now, invoices with these document types will print correctly regardless of the installed language.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228125
This update resolves an issue with the installation and removal of hooks related to the Account No Followup module. The fix ensures smoother operation of these hooks, improving the overall stability and reliability of the system. This change primarily addresses a technical bug and does not directly impact business users.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term Forward-Port-Of: odoo/enterprise#100350
This update ensures the kiosk ordering system only utilizes payment methods explicitly set up for it. Previously, the kiosk would incorrectly prompt for unavailable payment options. This change prevents errors and improves the kiosk's usability by limiting it to configured payment methods.
Original PR description
pos_self_order*: pos_online_paymnet_self_order, pos_self_order_razorpay, pos_self_order_stripe Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Restrict the kiosk to use only the payment methods explicitly configured in its settings. - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/enterprise/pull/89490 Forward-Port-Of: odoo/odoo#217467
This update prevents kiosks from attempting to use payment methods that haven't been specifically configured for them. Previously, kiosks would incorrectly prompt for online payments even when none were set up. This change ensures a smoother and more reliable kiosk ordering experience for customers.
Original PR description
Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/odoo/pull/217467 Forward-Port-Of: odoo/enterprise#89490
This update fixes an issue where time logs were incorrectly assigned to the current user instead of the assigned employee when marking work orders as complete. This change ensures accurate tracking of labor hours on work orders, resolving user confusion and improving data integrity. It corrects a previous bug introduced during a recent development cycle.
Original PR description
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the…
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the current user’s employee instead of the assigned one. This behavior caused confusion for the user as the wrong person was shown as working on the order. ## **Steps to Reproduce:** - Create an MO with work orders and confirm it. - Assign another employee to a work order. - Mark the work order as done with the current user from the work order line. - Open the workorder and notice that the time log is created for the current user’s employee. ## **Cause of the Issue:** The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790), where the logic for assigning the main employee was overridden, ignoring the case of an already assigned employee. ## **With This Commit:** The time log is now created for the assigned employee, This resolves the confusion by ensuring the right person is tracked on the work order. TaskID: 4983514 Forward-Port-Of: odoo/enterprise#93378
This update fixes an issue where changing quantities in Point of Sale wouldn't automatically update related items, particularly in combo products. It now ensures that quantity changes are correctly reflected across all related lines, and also improves price calculations to avoid unintended price adjustments when quantities are modified. This ensures accurate order totals and a smoother user experience.
Original PR description
Before this commit, when changing the quantities of a line, we would not automatically change the quantities of the children lines if any. This is now the case. We also handle the prices in a better way such that changing the quantities of a combo product does not affect the price unit of the lines computed previously. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users quickly opened the file viewer multiple times, such as by double-clicking attachments. The fix ensures the file viewer registry is properly cleared before each opening, preventing errors and improving overall stability. This enhances the user experience when accessing attachments.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update resolves a problem where the exchange rate was missing from invoices for certain currencies in Odoo versions 17.0 and 18.0. The underlying issue stemmed from a template conflict across multiple countries, and this fix specifically addresses the most immediate problem with the Saudi Arabia invoice template. This ensures accurate exchange rate display for invoices.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237193 Forward-Port-Of: odoo/odoo#236844
This update resolves a bug that prevented payments using the 'Own Checks' method in foreign currencies from posting correctly. The issue stemmed from a minor coding error that caused an imbalance in the accounting entries. This fix ensures accurate payment processing for international transactions.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228 Forward-Port-Of: odoo/odoo#236768
This update resolves issues with Viva Wallet integration caused by duplicate notifications and data processing delays. By sending payment information directly via websocket and filtering webhook events, the system now handles concurrent requests more reliably, preventing errors and ensuring smoother transactions. Additionally, the system now avoids unnecessary polling and handles webhook events more precisely.
Original PR description
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the…
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the `viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late. This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message. In addition, there are two other minor fixes: - In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error). - The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva. opw-5226966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237333 Forward-Port-Of: odoo/odoo#236454
A bug was causing negative amounts to appear in South Africa's EDI bill printouts when using different currencies. This update fixes the underlying code to ensure accurate currency conversion and display of bill totals and subtotals. This ensures correct financial reporting for South African businesses using the Odoo system.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update fixes an issue where the 'Late,' 'Today,' and 'Future' filters in the Activity Menu didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these filters align with other modules and provide accurate, deadline-based filtering for approvals.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#100113 Forward-Port-Of: odoo/enterprise#99632
This update corrects a visual glitch in the Odoo HTML editor where hint and power buttons remained visible when a block contained a tab. The fix ensures these buttons disappear when a tab is inserted, improving the editor's appearance and usability. This change was made to enhance the user experience and maintain a clean interface.
Original PR description
Description of the issue this PR addresses: - Hint and power buttons are incorrectly shown or hidden in empty blocks when the block contains a Tab or only empty formatting tags (`<strong>, <em>, <u>, <s>`). Current behavior before PR: - Pressing Tab in an empty block leaves the hint and buttons visible. - Empty paragraphs containing only formatting tags do not show the hint and buttons. Desired behavior after PR is merged: - Hint and power buttons are not shown when a block contains a Tab. - Hint and power buttons are correctly visible when a block contains only empty formatting tags. task-5062294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237125 Forward-Port-Of: odoo/odoo#230979
5 changes
Resolved issues and error corrections
This update resolves a visual glitch in the Gantt view when flexible working hours are enabled. Previously, the system incorrectly estimated working days, leading to random grayed-out days. The fix ensures all days are treated as working days, providing an accurate Gantt view representation.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update resolves an issue where the Fedex delivery method would fail when used with addresses in Hong Kong, specifically those with a 'Hong Kong Island' state. The fix ensures that the system correctly handles state code splitting, preventing a traceback and ensuring reliable delivery processing for this common address type. This improves the overall reliability of the shipping process.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes an error in the Peru tax return (RVIE Sales 14.4) report that incorrectly included credit note amounts in the VAT columns. The fix ensures accurate reporting according to SUNAT regulations, aligning with how credit notes are handled in tax filings.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466 Forward-Port-Of: odoo/enterprise#96146
This update resolves an issue with how the 'account_no_followup' module interacts with Odoo's core systems. Specifically, it corrects a problem with installing and uninstalling hooks, ensuring smoother operation and preventing potential disruptions. This change enhances the stability and reliability of this module.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term Forward-Port-Of: odoo/enterprise#100350
This update fixes a bug where the Activity Menu's filtering options (Late, Today, Future) didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these options work consistently and align with other Odoo modules. This improves the user experience for managing approvals.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#100113 Forward-Port-Of: odoo/enterprise#99632
12 changes
Resolved issues and error corrections
The Gantt view was incorrectly calculating unavailable time when flexible working hours were enabled. This update resolves a bug where the view randomly grayed out days, now ensuring accurate representation of employee availability. This improves the usability of the project scheduling feature.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update resolves an issue where the Fedex delivery method would unexpectedly crash when used with addresses in Hong Kong, specifically those with a 'Hong Kong Island' state. The fix adds a check to ensure the state code splitting process produces at least two elements, preventing a common error. This ensures reliable shipping for customers in this region.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update prevents the 'My Drive' folder from automatically unfolding when you open a folder within it, like 'Company'. Previously, this behavior caused unnecessary expansion and improved the user experience by aligning folder behavior with other root folders.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#100213 Forward-Port-Of: odoo/enterprise#93718
This update resolves an issue where the 'Click to Start' navigator wasn't appearing for documents without sign items. The fix ensures the navigator displays when a document has sign items, improving the user experience and making it easier for users to begin the signing process.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Add multiple documents in sign app. - Add sign item for user in first document and keep second document without any sign item. - Try sign document. Issue: - The "Click to Start" navigator is not visible when signing. - `postRender` runs for all documents and calls `checkSignItemsCompletion`, which then calls `updateDocumentsWithUnsignedItems(false)` for documents without sign items. - This passes false to `controlNavigatorVisibility`, hiding the navigator even though the first document has unsigned items. Solution: - In `controlNavigatorVisibility`, instead of relying only on the `hasUnsignedItems` flag, check if the current document is unsigned and has sign items for the current signer before toggling the navigator. Impact: - The "Click to Start" navigator now appears correctly, helping users start the signing process smoothly. task-5148722 Forward-Port-Of: odoo/enterprise#97205
This update resolves a minor visual issue in the Documents app where UI elements were overlapping. The team adjusted the layout to ensure proper display and functionality of key features, specifically the translate button and activity actions. This improves the overall user experience within the Documents module.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112 Forward-Port-Of: odoo/enterprise#86436
This update fixes an issue where deposited amounts were incorrectly shown as 'Total Due' in customer records. A recent system update caused a miscalculation, leading to inaccurate deposit displays. The fix ensures deposited amounts are now correctly shown as deposits, improving clarity for users.
Original PR description
Steps to reproduce: =================== 1. Open the customer list. 2. Select a customer and choose `Deposit money`. 3. Deposit an amount (e.g. 50) and confirm. 4. Open the customer list again. Issue: ====== The deposited amount is shown as `Total Due` instead of `Deposited`. Also the confirmation dialog for deposit showing negative amount. Cause: ====== A major refactor in order change calculation, passes the negative change value to the `depositOrder`, so the deposit was recorded as a due amount. Fix: ==== Negate the change value when adding the deposit order line so it becomes positive and is correctly shown as a deposit. Task: 5227004 Forward-Port-Of: odoo/enterprise#98847
This update significantly speeds up the process of generating work entries and attendance data within the payroll system. Previously, generating data for 100 employees took 20 seconds and created 55,000 queries. Now, the same process completes in just 2 seconds with only 750 queries, resulting in a substantial performance boost.
Original PR description
speedscope before the fix: <img width="1918" height="888" alt="image" src="https://github.com/user-attachments/assets/86b3f923-6d0d-4b11-8578-749425d2ad8d" /> speedscope after the fix: <img width="1919" height="860" alt="image" src="https://github.com/user-attachments/assets/61202f6e-b96f-42b7-a7a7-3297a990aa6d" />
This update resolves an issue preventing users in the 'invoicing and banks' security group from accessing key account reports. The changes add necessary security rules, specifically for the 'group account basic' and 'tax unit' reports, ensuring these reports are available to the intended user group. This improves usability and data access for users relying on these reports.
Original PR description
Some report must be accessible by user with the invoicing and banks security group. The menu items are there but when clicking on it, an access error is thrown. This commit will add the security rules for the group account basic for horizontal group (for the partner ledger and aged receivable/payable) and the tax unit (for the tax report) opw-5218948 Forward-Port-Of: odoo/enterprise#100020
This update improves the visibility of payslip status by displaying the number of errors and warnings directly on the status bubble icon. Previously, users couldn't easily identify potential issues with their payslips. This enhancement helps HR and payroll teams quickly address and resolve problems with payslip calculations.
Original PR description
Before this pr, users couldn’t see how many errors or warnings a payslip header status_bubble. With this change, hovering over the fa-exclamation-circle icon will show the number of warnings and errors. task-5257820
This update fixes a misleading warning displayed in Odoo related to minimum wage calculations. The warning is now correctly triggered only when a contract exists and at least one wage field is below the legal minimum. This change also ensures the warning appears in the salary calculator dialog for a more consistent user experience.
Original PR description
Problem ---------- The warning is displayed depending on if the contract_date_start <= today But it should be visible only if a contract exists and one wage field is below the minimal value. This warning should also be visible in the salary calculator dialog Solution ---------- Update the compute in hr_version. Do similar compute in hr_contract_salary_offer task-5030682
This update resolves a technical error related to employee cost calculations within the Odoo Enterprise payroll module. The issue stemmed from a dependency conflict when modules were loaded in a specific order, causing a data lookup failure. The fix establishes a clear dependency between payroll and the employee contract modules to ensure correct data processing.
Original PR description
Reproduce Issue : loading hr_contract_salary after l10n_sa_hr_payroll causes this error : Element '<xpath expr="//separator[@name='employer_costs']">' cannot be located in parent view Issue : in the hr_employee_view of the l10n_sa_hr_payroll , we inject three fields in the seperator "employer_costs" which is defined in hr_contract_salary , because there is no dependecy between the two modules , this causes the error to happen if the l10n_sa_hr_payroll is loaded first. Fix : Create another view to add these fields in the l10n_sa_hr_contract_salary module which depends on both l10n_sa_hr_payroll and hr_contract_salary task - 5258832 related PR : enterprise#98239
This update fixes an issue where attendance durations were incorrectly calculated when employees clocked in before their scheduled start times. Now, attendance durations are automatically and accurately generated upon approval, eliminating the need for manual intervention and ensuring accurate work entry tracking.
Original PR description
Before this commit: - For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an…
Before this commit: - For an employee with a Working Schedule as the work entry source and a default overtime ruleset (which creates a specific work entry type for overtime hours), creating an attendance with a check-in earlier than the employee’s normal working schedule start was not handled correctly. The early portion was ignored, resulting in a wrong attendance work entry duration (e.g., 06:15 instead of 08:00). - Work entries were not created automatically when approving the attendance. The user had to click Reset to force the generation, which is not the intended workflow. After this commit: - Attendance boundaries are now correctly normalized against the employee’s Working Schedule, ensuring the full expected duration is taken into account, even when the check-in occurs before the official start time. - The overtime ruleset is applied correctly, and the generated intervals properly reflect both standard working hours and overtime hours. - Work entries are now automatically created upon approval of the attendance, removing the need for any manual Reset action. task-5082562
28 changes
Resolved issues and error corrections
The Gantt view in the Project app was incorrectly calculating unavailable time when flexible working hours were enabled. This update resolves a bug where the view randomly grayed out days, now ensuring accurate representation of employee availability. This improves the usability of the project scheduling feature.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update corrects an error preventing the system from successfully retrieving invoice documents from the Viettel e-invoice API. The issue stemmed from incorrect parameter requirements in the API documentation, which were causing a 'not found' error. This fix ensures seamless document retrieval for Vietnamese e-invoicing.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves an issue where the Fedex delivery method would trigger errors when used with addresses in Hong Kong, specifically those with a state code of "Hong Kong Island". The fix ensures that the system properly handles state code splitting, preventing a traceback and ensuring reliable shipping functionality for this common address type. This improves the overall reliability of the shipping process.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update prevents the 'My Drive' folder from automatically unfolding when you open a folder within it, like 'Company'. Previously, this behavior was inconsistent. Now, folders will only unfold when their parent folders are opened.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#100213 Forward-Port-Of: odoo/enterprise#93718
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard displayed incorrectly. The button label has been updated to 'Generate and Copy Payment Link' to provide a clearer instruction for users. This ensures a better user experience when generating payment links.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update resolves an issue where the 'Click to Start' navigator wasn't appearing for documents without sign items. The fix ensures the navigator is displayed correctly, streamlining the signing process for users and improving usability.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Add multiple documents in sign app. - Add sign item for user in first document and keep second document without any sign item. - Try sign document. Issue: - The "Click to Start" navigator is not visible when signing. - `postRender` runs for all documents and calls `checkSignItemsCompletion`, which then calls `updateDocumentsWithUnsignedItems(false)` for documents without sign items. - This passes false to `controlNavigatorVisibility`, hiding the navigator even though the first document has unsigned items. Solution: - In `controlNavigatorVisibility`, instead of relying only on the `hasUnsignedItems` flag, check if the current document is unsigned and has sign items for the current signer before toggling the navigator. Impact: - The "Click to Start" navigator now appears correctly, helping users start the signing process smoothly. task-5148722 Forward-Port-Of: odoo/enterprise#97205
This update resolves a problem where the exchange rate was missing from invoices generated for currencies other than AED in older Odoo versions (17.0 and 18.0). The fix addresses a conflict within a shared invoice template used across multiple countries, ensuring accurate exchange rate display. This improvement impacts invoice accuracy and consistency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237193 Forward-Port-Of: odoo/odoo#236844
This update resolves a minor visual issue in the Documents app where UI elements were overlapping. The fix ensures that buttons and file size information are displayed correctly, enhancing the user experience. This change improves the overall usability of the Documents module.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112 Forward-Port-Of: odoo/enterprise#86436
This change truncates product descriptions in invoice lines to comply with character limits for e-invoicing (300 chars) and e-waybill (100 chars). This ensures generated JSON files are valid and prevents errors during e-invoice and e-waybill generation.
This update fixes an issue where subscription invoices weren't correctly incrementing, leading to unnecessary daily notifications. The change ensures that invoice dates are updated accurately when products are invoiced based on delivered quantities, preventing redundant 'Automatic renewal succeeded' messages. This improves invoice accuracy and reduces unnecessary chatter notifications.
Original PR description
Before this commit, when a product invoiced based on delviered quantity was not delivered, the subscription cron would detect the free period but the next invoice date would not be incremented. As a result, the cron would run every day and post a 'Automatic renewal succeeded. Free subscription.' message in the chatter. task-5345944
This update resolves a technical issue that could cause a traceback error when setting up OSS tax mapping in Odoo. The fix addresses a situation where tax groups lack associated accounts, preventing the system from displaying a helpful error message. Instead, the system now guides the user to configure the necessary tax accounts.
Original PR description
Repro steps: 1. Create a company with tax groups all missing the tax_payable_account_id and tax_receivable_account_id 2. Click on settings > OSS Tax mapping 3. A traceback shows about a missing XmlId Solution: The issue mainly happens because the company has no accounts set on any of its tax groups. So in such cases, the code raises a RedirectWarning to the list of tax groups to configure them instead of the traceback. task-5346712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in the Peru tax return (RVIE Sales 14.4) report that incorrectly included credit note amounts in the VAT columns. The change ensures the report accurately reflects SUNAT regulations for credit note reporting, improving compliance and data accuracy for Peruvian businesses.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466 Forward-Port-Of: odoo/enterprise#96146
This update fixes an issue where invoices using specific document types (201-213) within the l10n_ar localization couldn't be printed correctly. The fix ensures the template adapts to the installed language, allowing printing regardless of whether es_AR is present.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228125
This update prevents users from resetting invoices to draft while a Point of Sale (POS) session is active. Previously, the action would still be performed despite a warning notification. Now, an error notification is displayed, ensuring data integrity and preventing potential issues during POS transactions.
Original PR description
Before this commit, when trying to reset to draft an invoice linked to a POS order with an ongoing session, a warning notification was sent but the action was still performed. Now, the user is prevented from doing so and an error notification is sent instead. task: 5265836 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from marking fields as both readonly and mandatory within sign requests. The fix adjusts how the Sign app handles strikethrough and multiline fields, now allowing users to correctly configure these fields without causing validation errors. This ensures a smoother sign process for all users.
Original PR description
**Version:** - saas-18.4 **Steps to reproduce:** - Install the Sign app - Upload a PDF and add a strikethrough or multiline field - Mark the field as readonly and mandatory - Try to sign the document **Issue:** - The sign request cannot be validated if the strikethrough or multiline field is both readonly and mandatory. **Solution:** - For strikethrough fields: use "striked" instead of the item name "strikethrough" to set the correct value when the strikethorugh field is constant. - For multiline fields: when the field is constant, the value doesn’t come through element.value; instead, it’s in element.textContent, so we need to set the value there. **Impact:** - Users can now mark these fields as readonly and mandatory without blocking the validation of the sign request. task-5098750 Forward-Port-Of: odoo/enterprise#95769
This update resolves an issue where importing journal entries targeting inactive accounts previously caused errors. The change now allows these imports to proceed without regard to the account's active status, streamlining the import process and preventing disruptions.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237271
This update resolves an issue where notifications for inbox messages (like signature requests) weren't consistently displayed in the top messaging menu. Previously, users only saw these messages within the 'Discuss' app > Inbox. This change ensures that inbox messages are now correctly reflected in the main messaging menu, improving notification visibility and user experience.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235234 Forward-Port-Of: odoo/odoo#228740
This update fixes a bug where only the first CFE was processed from Uruguayan vendor bills. It now handles multiple CFEs and adds unique suffixes for manual and automated document creation, improving tracking and debugging. This ensures accurate bill processing and simplifies identification of document origins.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355 Forward-Port-Of: odoo/enterprise#99556 Forward-Port-Of: odoo/enterprise#86829
This update resolves a crash that occurred when users quickly opened the file viewer multiple times, such as by double-clicking attachments. The fix ensures the system properly manages file viewer instances, preventing errors and improving overall stability. This enhances the user experience when accessing attachments.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update resolves a bug that prevented payments using the 'Own Checks' method in the Bank journal with foreign currencies, causing invalid operation errors. The fix corrects a typo in the code, ensuring accurate accounting entries and proper payment balancing. This improves the reliability of payments for Latin American businesses.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228 Forward-Port-Of: odoo/odoo#236768
This update resolves an issue where adding attachments to log notes triggered an error when the restrictive audit trail was enabled. The fix allows users to attach PDFs to log notes while maintaining audit trail integrity, ensuring accurate record-keeping. It also standardizes audit trail tests across the account module.
Original PR description
To replicate: 1. In Settings, enable Restrictive Audit Trail 2. Create and post an invoice 3. Click on "Log note" and add a PDF attachment to the note 4. Click "Log" 5. Error ("You cannot remove…
To replicate:
1. In Settings, enable Restrictive Audit Trail
2. Create and post an invoice
3. Click on "Log note" and add a PDF attachment to the note
4. Click "Log"
5. Error ("You cannot remove parts of a restricted audit trail.") is raised.
With restrictive audit trail enabled, attachments cannot be deleted and writing to the attachment is restricted. However, when adding an attachment via the log notes, this writes to the attachment, setting the res_model to account.move and raising the error when _except_audit_trail() performs the check for a second time. This second write is triggered in `fix_attachments_on_record()`, introduced in odoo#189979.
This commit fixes that by also comparing the old values of the attachment and the new values to be written. If any of them are different, we proceed as before. Attachments cannot be deleted or changed. But if all values are the same, we do not perform the check, so an attachment can still be added.
In this commit we also move the attachment audit trail tests from l10n_de to account. In odoo#203229, the attachment audit trail checks were moved from to account, but the tests remained in the localization. An additional case covering the attachments in log notes was also added to the tests.
opw-5107912
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236736This update resolves an issue where changes to many2one fields within the website builder weren't consistently reflected across related displays and saved correctly. The fix ensures that the `data-oe-many2one-id` attribute is properly copied during replication, guaranteeing accurate data synchronization and preventing display or saving errors.
Original PR description
When replicating changes from one field to other occurences of the same field in the document, the `data-oe-many2one-id` was not copied (for many2one fields). Thus it could lead to showing incorrect values in the sidebar, or saving them. This commit fixes that by adding a dispatch to handlers after the replication, and implementing a handler that copies the `data-oe-many2one-id` when needed. Steps to reproduce: - Open website builder on a blog post - Enable the "Sidebar" - Enable the "Author" in the sidebar - Click on the second occurence of the name of the author in the page - Change the "Contact" associated with the author of the post - Click on the first occurence of the name of the author in the page - Bug: the name of "Contact" is the old one - Change the "Contact" to yet another one - Save - Bug: the author is not the last one selected task-5252648 Forward-Port-Of: odoo/odoo#235080
This update fixes an issue where demo restaurant orders incorrectly displayed 'false' for the ticket code on receipts. Now, demo orders will accurately show the ticket code, ensuring consistent and correct order information for testing and demonstration purposes. This improves the reliability of demo data for restaurant workflows.
Original PR description
Before this commit: - When validating draft orders created in the restaurant configuration with demo data, the receipt shows the ticket code as `false`. - For all demo paid orders also ticket code shows false. After this commit: - Instead of false, the ticket code will be shown task-5103925
This update optimizes how Odoo calculates lead stages, addressing a performance issue that increased query counts. The change ensures the correct stage is associated with a lead's team, resulting in faster lead stage updates and improved system responsiveness. This enhances the overall user experience for sales teams.
Original PR description
**Issue:**
Query count increases as `lead.stage_id.team_ids` needs to be used to ensure the current `stage_id` is related to the current lead `team_id`.
```py
@api.depends('team_id', 'type')
def _compute_stage_id(self):
for lead in self:
if not lead.stage_id or (lead.team_id and lead.stage_id.team_ids and lead.team_id not in lead.stage_id.team_ids):
lead.stage_id = lead._stage_find(domain=[('fold', '=', False)]).id
```
related: https://github.com/odoo/odoo/commit/ce8fdbb1989703715663d334662a87d1900a28feThis update fixes an issue where table numbers were difficult to see in Odoo's dark mode. The change ensures the table numbers are displayed in black, significantly improving readability and the user experience. This enhancement ensures consistent and clear presentation of information for all users.
Original PR description
Before this commit: - In dark mode, the table number was not clearly visible because the background color and table color were too similar. After this commit: - The table number is now displayed in black for better visibility. task-5103925
This update corrects a bug where vendor bill payment statuses remained incorrect after deleting or resetting payments. Previously, the bill status didn't update properly, even after the payment was removed. This fix ensures that the Vendor Bill status accurately reflects the payment's state, resolving a discrepancy with customer invoices.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772 Forward-Port-Of: odoo/odoo#237479 Forward-Port-Of: odoo/odoo#234725
This update fixes an issue where invoice lines were incorrectly reconciled across different customers during POS sessions. Previously, settling payments mixed invoices from various partners, leading to inaccurate reporting. Now, reconciliation is limited to the specific partner within the POS session, ensuring accurate financial records.
Original PR description
Invoice lines to be reconciled are not tailored to the single partner while the session lines do. That causes reconciliation to happen between different partners. To reproduce: Create an invoice of 100 to Customer 1 and an invoice of 200 to Customer 2. In a pos session, go to Customer 1, settle 50 on that invoice. Go to Customer 2, settle 100 on their invoice. Close register. => Lines from different customer are reconciled together. task-5346644 Forward-Port-Of: odoo/enterprise#100131
This update resolves an issue that occurred when translating content within the website editor. Specifically, adding a 'BR' tag after a translated string caused a save error. The fix removes translation branding elements during website editing to prevent this conflict and ensure proper saving of changes.
Original PR description
Scenario: - run Odoo with source code between [1] (29th october 2025) and [2] (19th november 2025) - translate a string in an embedded field with a BR added outside the translation contenteditable…
Scenario:
- run Odoo with source code between [1] (29th october 2025) and [2]
(19th november 2025)
- translate a string in an embedded field with a BR added outside the
translation contenteditable (eg. select completely a LI element and
replace the content by something else)
- save
- edit the content in source language, save (with or without any change)
Result: traceback error containing:
> File "addons/html_editor/models/ir_ui_view.py", line 66, in save_embedded_field
> model = 'ir.qweb.field.' + el.get('data-oe-type')
> ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
> TypeError: can only concatenate str (not "NoneType") to str
Cause:
Commit [1] removed o_editable on nodes that should not be editable, but
that caused those nodes to no longer have data-oe-readonly attribute.
When replacing the whole content translation node, the original content
is first removed, after which DeletePlugin.fillShrunkBlocks adds a BR
after the translation node.
This caused the ancestor [data-oe-model] to be set as o_dirty, event if
it was not editable or [contenteditable].
On save, the ancestor with .o_dirty[data-oe-model] was saved while
containing translation branding SPAN, which when editing the page in
source language, would cause an error on save.
Fix:
Up to 19.0, when the website editor is started in non-translation mode:
remove the translation branding SPAN.
[1] d4d428ff1d5be46135973aa806f206a1076bfcf7
[2] f09dc4d9d35e1e3707c9483fc6004cf162a3f4ca
opw-5234578
Forward-Port-Of: odoo/odoo#2366749 changes
Resolved issues and error corrections
This update corrects an issue preventing Odoo from properly retrieving invoice documents from the Viettel e-invoice system. The original problem stemmed from incorrect parameter requirements in the API documentation. By removing unnecessary parameters, the system now successfully retrieves the required invoice files, ensuring accurate data exchange.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves an issue where the Fedex delivery method would fail when shipping to addresses with state codes like 'Hong Kong Island' in Hong Kong. The fix adds a check to ensure the state code splitting process returns at least two elements, preventing a common error. This ensures reliable shipping functionality for customers in Hong Kong.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Fedex as a Delivery Method 2. On the Website, select a shippable product. Confirm the cart. 3. Ship to a "Hong Kong" address, with "Hong Kong Island" as State. 4. Traceback is raised. Issue ----- Traceback is raised whenever the Fedex Delivery Method is applied to a HK address (be it shipper or receiver) Cause ----- When splitting a state code, there is no check in the `_parse_state_code` function that the result contains at least two elements. Example ----- For a "Hong Kong" address, with "Hong Kong Island" as State: ``` country_code = "HK" state_code = "HK" ``` The method tries to split `state_code` by its hyphen, which returns a single item list. Solution -------- 1. Check for the size of the post-split list before accessing the second item. opw-5257852 Forward-Port-Of: odoo/enterprise#99635
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The button label has been updated to accurately reflect its function: 'Generate and Copy Payment Link'. This ensures users see the correct instruction when creating payment links.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112 Forward-Port-Of: odoo/odoo#236219
This update resolves an issue preventing the 'Payment Reminder' email template from functioning correctly. The fix corrects a technical error related to how the template processes numerical data, ensuring accurate payment reminders are sent to customers. This improves the reliability of our billing communications.
Original PR description
### Steps to reproduce: - Install account_no_followup - Enable debug mode - Settings > Technical > Email > Email Templates - Search for the "Payment Reminder" template > Preview ### > traceback: Can…
### Steps to reproduce: - Install account_no_followup - Enable debug mode - Settings > Technical > Email > Email Templates - Search for the "Payment Reminder" template > Preview ### > traceback: Can not compile expression: "format_amount(object.total_overdue_followup, ### Cause of the issue: The issue is caused by 7e55a28e73cc99184ed9737e672f451d03a3efb3 These lines: https://github.com/odoo/enterprise/blob/079795fe28f55854f9f785e360580a02e6f89d4e/account_no_followup/__init__.py#L7-L15 simply break every concerned template. the reason being that the template.html_body is a Markup and replacing the string: `t-out="*object.total_overdue` in a `Markup` will simply escape the `"` charracter as a `"` replacing this string by: `"t-out="*object.total_overdue"` for instance in `Payment Reminder` template it will alter this line: https://github.com/odoo/enterprise/blob/079795fe28f55854f9f785e360580a02e6f89d4e/account_followup/data/account_followup_data.xml#L18 and replace `<t t-out="format_amount(object.total_overdue, object.currency_id) or ''"/>` by `<t t-out=""format_amount(object.total_overdue", object.currency_id) or ''"/>` This makes the template crash as `""format_amount(object.total_overdue"` is not a valid attribute value. opw-5138378
This update addresses a security vulnerability where public website visitors could create unwanted UTM tracking records when registering for events. The fix restricts record creation to non-public users, preventing potential misuse and ensuring data integrity. This improves the stability and accuracy of our event registration tracking.
Original PR description
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event…
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event website - Open a register event link on the website (e.g. `/event/live-music-festival-4/register`) - Add UTM to the URL to simulate a marketing flow (e.g. `?utm_source=test&utm_medium=test&utm_campaign=test`) - Register to the event - Open the event on backend side - Check attendees and find the new one - Check the marketing section in debug mode - New records were created and added for the UTM values **Issue:** No access rights are checked when making the registration and updating the utm values. When not found they are added to existing ones during the `default_get` with `_find_or_create_record`. `return request.env['event.registration'].sudo().create(registrations_to_create)` This means that public users (visitors of the website) can create unwanted utm records when registering via expired/malformed/altered links. **Fix:** Restrict the issue to non public users for now. Might need to apply access rules and avoid the sudo. opw-4948208
This update resolves an issue where deleting a combo product within a sales order caused errors when modifying other items. The fix ensures all nested combo items are properly fetched and processed, preventing data inconsistencies and ensuring accurate order management. This improves the reliability of sales order modifications.
Original PR description
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps…
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps to reproduce: - Create a sales order and add a combo product to it. - Modify one of the combo items by replacing it with another combo product. - Delete the original parent combo product from the order lines and save. (Note: Make sure to not save the sale order while doing steps 1 & 2) Error: `ValueError: Expected singleton: sale.order.line()` The error occurs because the parent combo item is deleted, which causes `line.virtual_id` to become False. As a result, the filter [1] returns no matching records, and `ensure_one()` fails by raising a singleton error due to receiving zero records. This happens because the function [2] called from onchange in `sales_order` [3] that performs all the changes only checks the first level of combo items and doesn’t handle cases where those items are also combo products with their own linked items. Solution: - This commit fixes the error by properly fetching all nested combo items in the sales order, ensuring no leftover items from nested combos remain that could cause errors. [1] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order_line.py#L1567-L1569 [2] - https://github.com/odoo/odoo/blob/57b4056798b9a380027fd3da1c4f3965249a4509/addons/sale/models/sale_order_line.py#L1572-L1591 [3] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order.py#L922 sentry-6979144433,6653847384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users quickly opened the file viewer multiple times, such as by double-clicking attachments. The fix ensures the system properly manages file viewer instances, preventing errors and improving overall stability. This enhances the user experience by eliminating unexpected application interruptions.
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556 Forward-Port-Of: odoo/odoo#237267
This update fixes an issue where vendor bills for Saudi Arabia companies were displaying negative amounts in the currency conversion section. The fix ensures accurate currency calculations and proper bill formatting when dealing with different currency settings. This improves the reliability of financial reporting for SA clients.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update ensures the Sign app meets legal requirements for U.S. companies by notifying users when the sender is based in the U.S. and offering the option to request a paper copy of signed documents. This change enhances compliance and provides a safeguard for our business operations.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918 Forward-Port-Of: odoo/enterprise#97163
3 changes
Resolved issues and error corrections
This update corrects a bug in how deferred accounting moves are created, ensuring accurate move generation when invoices are processed. The fix ensures that the correct number of accounting moves (6 instead of 4) are created for invoices with specific date ranges, preventing discrepancies in financial reporting. This resolves an issue impacting invoice processing accuracy.
Original PR description
Since https://github.com/odoo/enterprise/commit/a71c38fa6325cd18c686352d8f68d350461d37d0 we generate deferred entries in batch for performance reasons. Since then, we lost the link between fully…
Since https://github.com/odoo/enterprise/commit/a71c38fa6325cd18c686352d8f68d350461d37d0 we generate deferred entries in batch for performance reasons. Since then, we lost the link between fully deferred entries and their deferral moves. Steps: - Have an invoice at invoice date == last day of current month - Two invoice lines, one for 1000, the other for 500 - On both lines, set start date to the first day of last month, end date to the last day of currnt month - Confirm the invoice -> 4 moves are created, instead of 6 (fully deferred move related to the 500$ line) and deferral move for 500$ related to the 1000$ line Cause: - When trying to cancel moves, we check each fully deferred move with all deferral moves and, if possible, cancel the two that have the same amount and the same month With this commit, we keep trace of the link between each fully deferred move and their related deferral moves, that way we can do the same check as before, but with each fully deferred move and only related deferral moves. Deferred moves lines before: | date | debit | credit | |------------|-------|--------| | 11/30/2025 | 1000 | 0 | | 11/30/2025 | 0 | 1000 | | 11/30/2025 | 0 | 250 | | 11/30/2025 | 250 | 0 | | 10/31/2025 | 0 | 500 | | 10/31/2025 | 500 | 0 | | 10/31/2025 | 0 | 250 | | 10/31/2025 | 250 | 0 | Deferred moves lines after: | date | debit | credit | |------------|-------|--------| | 11/30/2025 | 1000 | 0 | | 11/30/2025 | 0 | 1000 | | 11/30/2025 | 0 | 500 | | 11/30/2025 | 500 | 0 | | 11/30/2025 | 500 | 0 | | 11/30/2025 | 0 | 500 | | 11/30/2025 | 0 | 250 | | 11/30/2025 | 250 | 0 | | 10/31/2025 | 0 | 500 | | 10/31/2025 | 500 | 0 | | 10/31/2025 | 0 | 250 | | 10/31/2025 | 250 | 0 | opw-5000337
This update fixes a bug where failed Outlook event synchronization caused duplicate calendar events to be created in both Odoo and Outlook. The fix uses a unique identifier from Microsoft to ensure accurate synchronization and prevent these recurring duplicates. This improves data consistency and reduces manual intervention.
Original PR description
When inserting an event into Outlook after a commit, if the insertion fails due to a timeout, the microsoft_id is never stored in the Odoo record. As a result, synchronization does not occur…
When inserting an event into Outlook after a commit, if the insertion fails due to a timeout, the microsoft_id is never stored in the Odoo record. As a result, synchronization does not occur correctly. On the next sync, a new event is created in Outlook. Since the original event is not linked to the Odoo entry, it is also re-synchronized back into Odoo, resulting in duplicate events in both systems. Steps to reproduce: - This is difficult to reproduce consistently, as it depends on Outlook’s response time. - Locally, it can be reproduced by forcing an error right after the Outlook insertion but before updating the Odoo record (between these lines: https://github.com/odoo/odoo/blob/34d0ae0ccb965e340d31bdbd7a7436af98e6dd48/addons/microsoft_calendar/models/microsoft_sync.py#L474-L475). Fix approach: This solution leverages the transactionId property provided by Microsoft (see: https://learn.microsoft.com/en-us/graph/api/resources/event?view=graph-rest-1.0#properties). This ensures that even if a timeout occurs, a retry will trigger a sync from Microsoft to Odoo, and thanks to the transaction ID, the Microsoft event can be correctly matched with the Odoo event — preventing duplicates. opw-5031073 opw-5105449
This update fixes issues preventing video options from being correctly saved and applied when editing video snippets. Specifically, it resolves problems with resetting options, incorrect URL parameter handling, and Dailymotion preview failures, ensuring users can consistently configure and embed videos as intended.
Original PR description
Issues: 1. Resetting options when dialog is closed without modification: When the media dialog is closed without changing any options and "Add" is clicked, the videoSelector component is reset,…
Issues:
1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and toggle a few options (e.g., "Loop").
- Save the video configuration.
- Double-click the snippet again to open the video configurator.
- Save without making any changes.
- The options will be reset.
2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.
- Steps to reproduce:
- Add any Text snippet.
- Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
- Choose to embed the YouTube video from the Powerbox popup.
- The Video snippet is added without options enabled for the pasted URL.
3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and append query parameters to the URL.
- The option buttons should toggle according to the parameters, but they do not.
4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....
- Fixes implemented:
- Preserve selected options when saving the Video snippet without any changes.
- Retrieve all query parameters from the URL and include them in the RPC request.
- Synchronize option toggles with the URL input when the user manually edits it.
- Fixed the Dailymotion regular expression to support protocol-independent
URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).
task-4529118
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr