Daily updates from Odoo
Friday, January 16, 2026
168 changes
30 changes
New functionality added to Odoo
This update incorporates Uzbek translations for various Odoo modules. This expansion improves Odoo's usability and accessibility for users who speak Uzbek, aligning with our commitment to global localization. The changes cover a wide range of modules, enhancing the overall user experience.
Original PR description
Related: https://github.com/odoo/enterprise/pull/104176 Forward-Port-Of: odoo/odoo#243574
This pull request adds Uzbek translations for various Odoo Enterprise modules. This improves the software's usability and accessibility for users who speak Uzbek, expanding the platform's reach and supporting a wider customer base. The changes cover several key accounting and financial modules.
Original PR description
Related: https://github.com/odoo/odoo/pull/243574 Forward-Port-Of: odoo/enterprise#104176
Enhancements to existing features
This update modifies the tax names and descriptions used in Odoo's accounting system for Belgium. These changes ensure accurate reporting and compliance with Belgian tax regulations. The update aligns with internal task 5363874.
Original PR description
### With this commit:- - We are updating the current tax name and its description in Belgium. - Please visit the task for more reference. task-5363874 Forward-Port-Of: odoo/odoo#243142 Forward-Port-Of: odoo/odoo#236242
This update enhances the Point of Sale interface by visually indicating payment status. Remaining amounts are now highlighted in green when positive and red when negative, providing clearer feedback to users about outstanding balances. This improves the user experience and helps ensure accurate order processing.
Original PR description
The aims of this pr is to put the payment status and amount in green when the Remaining amount is positive. And in red for negative amount. task: 5491579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243760
Resolved issues and error corrections
This update resolves an issue where applying a zero-amount discount in the sales order system would trigger an error. The fix ensures the system handles zero discounts gracefully, preventing disruptions to the sales process. This improves the reliability of discount application.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The system now verifies read access to the related record before redirecting, ensuring a smoother sign-off experience for all users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
This update fixes an issue where formatting applied to text using shortcuts didn't consistently transfer to newly typed content. Previously, the cursor would jump outside the formatting element after applying a shortcut. Now, formatting will correctly inherit when using shortcuts, ensuring a smoother and more reliable experience for users creating and editing formatted content within the HTML editor.
Original PR description
#### Description of the issue this PR addresses: - When using shortcuts (e.g. typing '1. ') after applying inline formatting, newly typed text did not inherit the formatting. - This occurred because extracting the shortcut text left the formatting element empty, causing the cursor to move outside it. #### Desired behavior after PR is merged: - Ensure the caret remains inside the formatting element by filling the closest element of `focusNode` when it becomes empty during shortcut handling. #### Steps to Reproduce: - Go to To-Do, Create a new record. - Type formatted text (e.g. Ctrl+[b|u|i]). - Press Enter. - Type '1. ' to create a list. - Type text inside the list item. => The text inside the list does not retain the formatting. task-5468358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242209
This update resolves a bug where the HTML editor incorrectly inserted tab characters into content, even when selecting mixed block types. The fix now ensures that tabs are only applied to contenteditable paragraph blocks (like headings and paragraphs), preventing unwanted indentation and improving editor usability. This ensures consistent formatting within the editor.
Original PR description
#### Description of the issue this PR addresses: - Tab indentation was applied to non-paragraph and non-contenteditable blocks, leading to incorrect indentation behavior when a selection contained mixed block types. #### Desired behavior after PR is merged: - Filter selected blocks to indent only contenteditable paragraph-related elements (h1–h6, p, pre, blockquote, and div.o-paragraph), while excluding blocks marked as contenteditable="false". #### Steps to Reproduce: - Open a new to-do record. - Insert: Table, Table of Content, Banners, attachment, (18.2 - Toggle List) - Select all editor content using Ctrl + A. - Press the Tab key multiple times. => Multiple editor tab characters are inserted at unintended positions. task-5452410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241806
This update fixes an issue where pressing the Backspace key in empty HTML editor banners or code blocks did nothing. Now, Backspace will correctly remove these elements, transforming them into a standard base container. This improves the editor's usability and ensures consistent behavior.
Original PR description
### Description of the issue/feature this PR addresses: - Pressing `Backspace` inside an empty banner or code block did nothing. ### Desired behavior after PR is merged: - Pressing `Backspace` in an empty banner or code block will transform them into a base container. task- 5384545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238640
This update removes a redundant CSS class from the Point of Sale module. The class was previously used to limit button width but is no longer needed. This cleanup improves the codebase and reduces potential maintenance overhead.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/243770 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243831
This update resolves an error that occurred when users deleted the 'Balance' line in the General Ledger Report. The fix prevents the report from crashing when a balance isn't present, ensuring a smoother user experience. This improves the reliability of a core accounting function.
Original PR description
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting >…
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting > Configuration > Accounting (section) > Accounting Reports - Open the General Ledger report - Delete the balance line from the Column tab - Go to Reporting > General ledger >> Error occurs (If an error does not occur, try opening the detailed view of the journal in the report.) Error: `KeyError: 'balance'` This issue was generated because at code line [1] tries to access `balance` key from the `colname_to_idx[col_group_key]` but since the user deleted `balance` it will not fount there and we got an error. This commit fixes the issue by preventing the processing of `line_balance` when the balance key is not present in `colname_to_idx[col_group_key]`. [1]: https://github.com/odoo/enterprise/blob/340abdc1b00df4d3d6130b26650519ae8354d199/account_reports/models/account_general_ledger.py#L326 sentry-7105657812 Forward-Port-Of: odoo/enterprise#102113
This update fixes a visual glitch in Firefox where the page would jump after undoing actions involving tall snippets. The team adjusted how snippets are scrolled to the top, which is now the more intuitive behavior. This ensures a smoother user experience.
Original PR description
Steps to reproduce: - On Firefox, drop a snippet taller than the page height. - Remove it. - Undo. => The page shows a white gap until you scroll again. Same issue when showing a hidden tall snippet. After investigation, no real explanation was found for this bug in Firefox. We only observed that changing the "center" parameter to "start" in the "scrollIntoView" function fixes the issue. In the end, this is not a bad idea, since scrolling a snippet to its beginning arguably makes more sense than centering it, especially when the snippet’s height is larger than the viewport. task-5194559 Forward-Port-Of: odoo/odoo#241518
A customer modified their Gift Card and E-Wallet products to use stock, causing an inventory inconsistency. This fix prevents the system from reverting these products to their original service-type status, resolving a test case error. Given the recurring nature of this request, we're considering a more general solution.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update removes unnecessary system notifications (like user joins/leaves) from appearing on leads. These notifications were distracting and irrelevant to users. This change improves the lead management experience by streamlining information.
Original PR description
Before this commit, system notifications such as "user join/leave the chat" would be displayed in the created lead/ticket. Those messages are not useful in anyway and should be excluded. task-5491212 enterprise: https://github.com/odoo/enterprise/pull/104336 Forward-Port-Of: odoo/odoo#243856
This update resolves an issue where the USB printer functionality would unexpectedly stop working when a printer lid was open. The fix ensures the system gracefully handles situations where printer data isn't immediately available, returning an empty byte string instead of a failure result. This maintains consistent printer operation.
Original PR description
When using the `python-escpos` library with a USB printer, we had to patch the read method to retry due to the result not always being immediately available. However, in the case where all the retries are exhausted, it currently returns `None`, whereas the library always expects a `bytes` result. This commit fixes the issue by returning `b""` when no result can be read. This prevents the `python-escpos` functionality from being disabled when the printer lid is open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244043
This update ensures that survey spreadsheet exports consistently use the originally recorded date/datetime format for all answers, regardless of changes to the question type. Previously, modifying a question type after a response could cause formatting issues. This change guarantees data integrity and avoids errors when exporting historical survey results.
Original PR description
Current behavior before PR: - Survey spreadsheet export derived date and datetime formatting from the current question type. - Changing a question type after submission (date to datetime) could lead to incorrect formatting or export errors for existing answers. Desired behavior after PR is merged: - Spreadsheet export now derives value conversion and formatting from the stored answer type instead of the question definition. - Historical answers keep their original date or datetime format, even if the question type is modified later. Task: [5410758](https://www.odoo.com/odoo/project/2328/tasks/5410758) Forward-Port-Of: odoo/enterprise#102930
This update fixes a technical error that could cause a failure when displaying complex web pages. The fix ensures that the system only attempts to unfold and read data when a specific specification is provided, preventing a 'NoneType' error. This improves overall stability and prevents unexpected disruptions to web page functionality.
Original PR description
An error occurs when `web_read_group` is called without an unfold specification. **Error:** `TypeError - 'NoneType' object is not iterable` **Cause:** Here the method `web_read_group` unconditionally calls `all_records.web_read(unfold_read_specification)` - [1] However, `web_read` requires a valid read specification. If `unfold_read_specification` is None [2], it fails when trying to iterate over it during record mapping. **Fix:** This commit only unfold and reads group records when `unfold_read_specification` is given. [1] - https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/web/models/models.py#L449-L449 [2] - https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/web/models/models.py#L317 sentry-7112641140 Forward-Port-Of: odoo/odoo#241754
This update fixes an issue where dynamic snippet templates weren't fully updating their container widths after a change. The fix ensures all container classes are cleared, preventing outdated styles from persisting and guaranteeing consistent layout updates for dynamic content. This improves the overall visual presentation of the website.
Original PR description
Steps to Reproduce: 1. Drop a dynamic snippet from debug block. 2. Set the fetched elements to 1. 3. Set the content width to Thin (o_container_small). 4. Change the template of the snippet. When changing a dynamic snippet's template, previously set container widths (e.g., "Thin") could persist even though the option resets. Issue: Only template defined containerClasses were removed, leaving manually set classes like "o_container_small" behind. Fix: All container classes are cleared before applying the new template's containerClasses or falling back to "container". Forward-Port-Of: odoo/odoo#241804
This update ensures that users who have set their status to 'do not disturb' are no longer receiving inbox messages. Previously, this functionality was inconsistent with push notifications, leading to unnecessary alerts. This change improves user experience and reduces potential distractions.
Original PR description
Users shouldn't be notified when they set their status as "do not disturb". It's already done for push notifications but inbox messages follow a different path. 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#244059
This update fixes a problem where inviter notifications were sent for all invited users, including portal users, leading to unnecessary alerts. Now, inviter notifications are only triggered when an internal user connects for the first time, streamlining the process and improving the user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited…
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users. For portal users, this resulted in unnecessary toast notifications and chat window pop-ups. **Current behavior before PR:** --------------------------------- - The inviter is notified when any invited user connects for the first time. - This includes portal users. - Unnecessary notifications and chat pop-ups are shown for portal user connections. **Desired behavior after PR is merged:** ----------------------------------------- - The inviter is notified **only when an internal user** connects for the first time. - Portal users no longer trigger first-connection notifications. - The notification message is updated to: “[Username] just connected for the first time. Wish them luck!” **Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242235
This update resolves a recurring test failure in the HTML Editor's toolbar. The issue stemmed from the toolbar being a popover, requiring a longer wait time for updates. By using a 'waitFor' mechanism, the test is now more reliable and consistent, ensuring smoother operation for users.
Original PR description
Waiting one animation frame for the toolbar to update is not enough because the toolbar is a popover and is therefore affected by [1]. Use `waitFor` to avoid non-deterministic test failures on runbot. runbot-237773 [1]: https://github.com/odoo/odoo/commit/54da715df84789f9a1acc0cfc91be41dcdbab140 Forward-Port-Of: odoo/odoo#243568
This update fixes a reporting issue in our Point of Sale (POS) system. Previously, sales statistics didn't fully account for completed transactions with 'done' statuses. Now, all invoiced orders in the 'done' state are included, providing a more accurate and complete picture of each POS session's sales performance.
Original PR description
When computing the sales statistics for a POS session, include invoiced orders (state 'done') along with paid orders (state 'paid'). This ensures that all completed transactions are accounted for in the session summary. opw-5475876 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242808
This update resolves a technical issue that caused a traceback error when removing a pay category selection for employees in the payroll section. The fix ensures the system handles data removal correctly, preventing unexpected errors and improving payroll stability.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432
This update addresses a technical issue where clicks within editable lists were unintentionally triggering unwanted actions. A new feature was added to allow developers to 'ignore' clicks within specific list elements, ensuring proper list editing functionality. This resolves a bug impacting user experience.
Original PR description
Since commit 37d78a4, the global click listener sets `capture: true`, which prevents other components to stop the propagation of the click event in order to maintain the focus on the selected list element. This commit introduces a special data key that can be set on an element so that any click occurring within it will be ignored by the list renderer. task-none but necessary for https://github.com/odoo/enterprise/pull/103732
This update resolves a test failure within the 'test_discuss_full' module. The fix ensures the correct time zone is set for a test record, preventing an assertion error. This improves the reliability of our automated testing process.
Original PR description
This commit fixes a failing assert in `test_10_init_store_data`. The test fails since [1] due to asserting the value of the OdooBot time zone as False. This commit explicitely sets the time zone of the OdooBot partner record and asserts it. [1] https://github.com/odoo/odoo/pull/210094 runbot-237777
This update corrects a reporting issue where live chat response times continued to track even after a customer closed the conversation. The fix ensures response times accurately reflect the actual chat duration by stopping the tracking when the chat is closed, preventing inflated reporting figures. This improves the accuracy of live chat performance data.
Original PR description
Before this commit, the response time for a live chat conversation did not stop until the operator leaves the conversation, even if the customer had already closed it. This leads to response times that are longer than the conversation duration. The reason for this behavior is that the response time is indiscriminately checking for the first agent message. If the live chat gets closed by the customer without answer, the first message will be "Agent left the channel", posted upon the agent leaving the conversation. Once the conversations is closed the response time should stop as it can be expected that an operator does not pay attention to already closed chats This commit fixes the issue by setting the `time_to_answer` to NULL if the first message is posted after the live chat is closed. task-5117556 Forward-Port-Of: odoo/odoo#242895
This update fixes an issue where appointment dates were displayed out of order in the online booking cart. The fix prevents dates from being split into multiple lines, which previously caused the reversal of date order when the data was processed. This ensures accurate date presentation for customers during the booking process.
Original PR description
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The…
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The appointment dates are displayed in an incorrect order in the cart. **Root cause:** - In the linked commit, the logic reverses the `self.name` lines to fix a display issue. - However, since appointment dates are split across multiple lines, reversing the list also unintentionally reverses the appointment date order. **Solution:** - Ensure that the appointment dates are formatted to appear on a single line, preventing them from being split into multiple list entries and incorrectly reordered when the lines are reversed. [commit]: https://github.com/odoo/odoo/pull/223433/changes/5b69176e64e6a4cc46966a8c41b675ed3d98dd0a Before: <img width="554" height="138" alt="image" src="https://github.com/user-attachments/assets/3e13a2a5-61d5-48c5-8e6a-85f313f7b6ca" /> After: <img width="566" height="120" alt="image" src="https://github.com/user-attachments/assets/f0b04592-7fd4-4104-b200-cf9b6f080962" /> opw-5420805 --- Forward-Port-Of: odoo/enterprise#104100
This update fixes an issue where the HTML editor would incorrectly display extra lines when multiple lines were selected. The change filters out empty text nodes to prevent unnecessary font wrappers, resulting in a cleaner and more accurate display of the editor's content. This ensures a better user experience when editing rich text.
Original PR description
**Current behavior before PR:** - When multiple lines were selected within a block, any empty text nodes between them would also receive a font wrapper when applying a color. - As a result, it appeared as though an extra line was being inserted when the color was applied. **Desired behavior after PR is merged:** - Empty text nodes that are not visible and are not zero-width space or line-break nodes are now filtered out before the font tag is created. - This prevents font wrappers from being created around those nodes. task-5344051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236824
This update ensures that internal users can still invite colleagues to closed live chat conversations, as previously the invite link was hidden by mistake. This change removes a restriction, allowing for seamless collaboration and ensuring users can easily extend access to chats when needed. It's part of a larger effort to improve chat functionality.
Original PR description
Invite link is hidden on closed live chat but it doesn't make sense. Internal users still want to invite collegues to the chat (e.g. inviting salesperson to the chat). Morever, the link is hidden but nothing prevents users to user it technically. This commit shows the invite panel, even on closed live chats. part of task-4873812
This update corrects a bug in how the system determines if a stock location is a child of another. The fix replaces a potentially misleading check with a more reliable method, ensuring accurate location relationships. This resolves a previous issue that could cause test failures and maintain data integrity.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
7 changes
Resolved issues and error corrections
This update resolves an issue where applying a zero-amount discount on sale orders would trigger an error. The fix ensures the system handles zero discounts gracefully, preventing disruptions to the sales process. The change improves data integrity and user experience.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system verifies read access to the related record before redirecting, resulting in a smoother sign-off experience for users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
A customer modified their Gift Card and E-Wallet products to use inventory, causing an inconsistency in the system. This fix prevents these products from being automatically converted back to service-type products, maintaining accurate inventory counts. This change addresses a recurring customer request and highlights the need for a more general solution.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update removes a redundant CSS class from the Point of Sale module. The class was previously used to limit button width but is no longer needed in the current design. This cleanup improves the codebase and reduces potential styling conflicts.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/243770 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243831
This update corrects a bug in how the system identifies sub-locations within the stock management system. Previously, matching location IDs could lead to incorrect sub-location detection. This fix ensures accurate sub-location identification, preventing potential errors in related processes.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update addresses a technical issue related to how Odoo handles record deletions, specifically cascade deletes in the database. It ensures that related records linked to messages and activities are not accessed after deletion, improving overall system performance and stability. This change was prompted by a community recommendation to enhance data management practices.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104410 Forward-Port-Of: odoo/enterprise#101185
This update resolves an issue preventing stable IoT Box responses from being correctly interpreted. The system now prioritizes data from a specific key, ensuring that IoT Box data is reliably displayed and processed. This enhances the overall stability and functionality of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
5 changes
Resolved issues and error corrections
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system verifies read access to the related record before redirecting, improving the signing process for all users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
A customer modified their ‘Gift Card’ and ‘E-Wallet’ products to use them as stock items. This created an inventory inconsistency. This fix prevents these products from being automatically converted back to service-type products, resolving the issue and ensuring accurate stock counts.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update corrects a bug in how the system determines if a stock location is a child of another. The fix replaces a potentially misleading comparison with a more reliable check, preventing errors in location-based processes. This ensures accurate stock management and avoids potential disruptions to workflows.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update fixes an issue that occurred when users deleted combo choices linked to products and then attempted to load sample data in the Furniture Point of Sale (PoS). The change prevents a parsing error that would block the demo data from loading, ensuring a smooth experience for users.
Original PR description
When combo choices associated with products are deleted and the user attempts to load sample data in the Furniture PoS, a traceback occurs. Steps to reproduce the error: - Install ``point_of_sale``…
When combo choices associated with products are deleted and the user attempts to load sample data in the Furniture PoS, a traceback occurs. Steps to reproduce the error: - Install ``point_of_sale`` module without demo data - Go to Point of Sale > Click on Furniture > Open Register > Load Sample > Close register - Go to Point of Sale > Products > Combo choices > Delete all combo choices - Go to Settings > Restrict Categories > Unset all categories > Save - Go to Point of Sale > Dashboard > Furniture > Open Register > Load Sample Traceback: ```py ParseError: while parsing /home/odoo/src/odoo/19.0/addons/product/data/product_demo.xml:905 A combo product must contain at least 1 combo choice. ``` https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/point_of_sale/models/pos_config.py#L1025 When clicking Load Sample button in the Furniture PoS, the ``_load_onboarding_furniture_demo_data`` method loads the ``data/product_demo.xml`` file. If the combo choices linked to products have been deleted, loading the following record triggers the above traceback. https://github.com/odoo/odoo/blob/c81e50d3b8f0ffc0297c97b06afd77e2c92ad508/addons/product/data/product_demo.xml#L664-L671 Solution: Restrict deletion of combo choices if they are linked to any products. sentry-6943167929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users with limited access to the Appraisal module would encounter errors when loading sample data. The problem stemmed from the sample data attempting to create records within the Recruitment module, which required broader permissions. This fix ensures the data load process is stable for users with the Appraisal module access.
Original PR description
The system will crash when user try to load sample data in appraisal. **Steps to produce:-** - Install `Appraisals` and `Recruitment` module. - Make a new user with access right of administrator to…
The system will crash when user try to load sample data in appraisal.
**Steps to produce:-**
- Install `Appraisals` and `Recruitment` module.
- Make a new user with access right of administrator to `only Appraisals`.
- Login with new user.
- `Appraisals > Load sample data`.
**Error:-**
```py
AccessError: You are not allowed to create 'Job Position' (hr.job) records.
This operation is allowed for the following groups:
- Recruitment/Officer: Manage all applicants
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside <record id="job_consultant" model="hr.job" forcecreate="1">
<field name="name">Consultant</field>
<field name="no_of_recruitment">5</field>
<field name="contract_type_id" ref="hr.contract_type_interim"/>
<field name="description">We are currently looking for someone like that to join our Consultant team.</field>
</record>
ValueError: ParseError('while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:21, somewhere inside\n<record id="job_consultant" model="hr.job" forcecreate="1">\n <field name="name">Consultant</field>\n <field name="no_of_recruitment">5</field>\n <field name="contract_type_id" ref="hr.contract_type_interim"/>\n <field name="description">We are currently looking for someone like that to join our Consultant team.</field>\n </record>') while evaluating
'action = model._load_demo_data()'
```
**Root Cause:-**
- When a user is granted access rights only for the Appraisal module and attempts to load sample data for it, an error occurs. This happens because the sample data at [1] includes the `creation of records` related to the `Recruitment module`. Since the user does not have the required access rights for Recruitment, the system raises a permission error.
**Solution:-**
- In this commit, we resolve the issue by using `sudo()` while loading the data.
[1]: https://github.com/odoo/odoo/blob/fabfeb55c56fbc7136bd1c3a72e9d6ee99f39714/addons/hr/data/scenarios/hr_scenario.xml#L21-L26
**sentry-6795776877**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr7 changes
Resolved issues and error corrections
This update fixes an issue where placeholder hint text in the HTML editor would wrap awkwardly onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more consistent user experience. This improves readability and visual appeal.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243006
This update simplifies the GSTR report generation process by removing an unnecessary credit note warning. Previously, a warning appeared on GSTR reports when a credit note was present on an invoice, which has now been corrected. The warning is now cleared only after the credit note is fully posted and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#102106
A test related to inventory adjustments was intermittently failing due to a race condition involving notification messages. This commit resolves the issue by automatically closing the initial success notification before processing subsequent adjustments, ensuring accurate test results.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692)
This update fixes a potential issue in how the system determines if a stock location is a child of another. The change replaces a method that could incorrectly identify related locations due to matching IDs, preventing a specific test from failing. This ensures more reliable stock management processes.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update resolves an issue where the HTML editor would crash when attempting to remove formatting from a cell with a lingering color after text deletion. Now, users can reliably remove color formatting without encountering errors, improving the overall stability and usability of the HTML editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241829
This update resolves an issue where the 'product_barcodelookup' module would crash when attempting to retrieve images for products that didn't have associated images in the Barcode Lookup API. The fix ensures the code handles cases where the API returns a different data type than expected, preventing the error and allowing image retrieval to function correctly.
Original PR description
Attempting to fetch pictures for a product via the Barcode Lookup API that has no images causes a traceback. Steps to reproduce the error: - Install ``product_barcodelookup`` module and set API Key -…
Attempting to fetch pictures for a product via the Barcode Lookup API that has no images causes a traceback. Steps to reproduce the error: - Install ``product_barcodelookup`` module and set API Key - Create a new product > Barcode: ``7896539200843`` > Save - Actions > Get Pictures from Barcode Lookup > Get Pictures Traceback: ``AttributeError: 'dict' object has no attribute 'status_code'`` https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25 When a product does not have picture in barcode lookup, ``barcode_lookup_request`` method returns ``dict`` instead of ``Response`` object. This causes a traceback when the code later tries to access ``status_code`` at: https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/wizard/product_fetch_image_wizard.py#L277-L278 ref: https://github.com/odoo/enterprise/commit/48582d98d6a1bc275a6f6c2baa83431dda085516 sentry-6886021547
This update resolves an error that prevented users from exporting CRM forecasts. The issue stemmed from changes in how forecast data is displayed, leading to a division-by-zero error when attempting to export. The fix ensures the export functionality works reliably, regardless of the data displayed in the forecast views.
Original PR description
Currently an error occurs when we try to export CRM forecast. **Steps to replicate:** - Go to CRM > Reports > Forecast. - Click on the gear menu and click `Export All`. **Error:** `ZeroDivisionError: division by zero` **Cause:** - The error due to a modification in the List and Kanban views, which are now merged into the DynamicList. - This change resulted in the `Export All` option appearing in the CRM Forecast kanban view and forecast views can have empty stages. - The issue occurs at line [1] where `self.count` becomes zero for stages without records, leading to the error. **Solution:** - This commit solves the issue by returning default value 0 when data is empty. [1]: https://github.com/odoo/odoo/blob/6be0e8ad57c531fb88dc33e126df884430f1ab21/addons/web/controllers/export.py#L97 sentry-6720460271 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
23 changes
New functionality added to Odoo
This update adds estimated return dates to the EC Sales List and Tax reports. This provides customers with clearer timing information for reporting, allowing them to verify data accuracy before submission. It improves transparency and helps ensure accurate financial reporting.
Original PR description
The aim of this commit is adding returns for EC Sales List report and the Tax report. These returns allow customers to know when they have to report both reports and help them to check that every value are correctly set before sending the report. task-4893984 Forward-Port-Of: odoo/enterprise#100572
This pull request adds Uzbek translations for various Odoo modules. This expands Odoo's language support, making the software accessible to a wider user base who speak Uzbek. It improves the usability of Odoo for Uzbek-speaking customers and partners.
Original PR description
Related: https://github.com/odoo/enterprise/pull/104176 Forward-Port-Of: odoo/odoo#243574
This pull request adds Uzbek translations for several key Odoo modules, including accounting and financial management. This expands Odoo's support for the Uzbek language, making the software more accessible and usable for users in Uzbekistan. It improves localization and user experience for a significant user base.
Original PR description
Related: https://github.com/odoo/odoo/pull/243574 Forward-Port-Of: odoo/enterprise#104176
Enhancements to existing features
This update allows HR users to archive departure reasons that are no longer in use. Previously, HR users could only manage these reasons by naming them, leading to confusion. Now, HR users can actively archive unused reasons, preventing their continued use and simplifying HR processes.
Original PR description
An HR user has currently no way to prevent use of specific /deprecated departure reason other than specifying it in the name. This commit an active field on `hr.departure.reason` so that an HR user can archive departure reasons that should not be used (as he can't delete them if they are referenced at least once). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the tax names and descriptions used in Odoo for Belgium. These changes ensure accurate reporting and compliance with Belgian tax regulations. The update impacts the accounting and point-of-sale modules within the Odoo system.
Original PR description
### With this commit:- - We are updating the current tax name and its description in Belgium. - Please visit the task for more reference. task-5363874 Forward-Port-Of: odoo/odoo#243142 Forward-Port-Of: odoo/odoo#236242
This update simplifies the process for sharing documents with partners who don't have existing user accounts. Now, when a partner accesses a document with a public link, they can create a user directly linked to that partner, streamlining document sharing and improving user experience. This change ensures partners can easily access documents without needing to create a full user profile.
Original PR description
Purpose ======= We can share a document to a partner without a user, and with `access_via_link == 'none'`. In that situation, the partner is forced to create a user, but if he clicks on signup, then the new user won't be linked to the partner set on the `documents.access` (a new partner will be created). Now, when inviting a member, if he doesn't have a user, we invite him to create a user. If the partner has a user, then we just redirect him to the login page. Task-5242208 Forward-Port-Of: odoo/enterprise#104374 Forward-Port-Of: odoo/enterprise#100628
This update enhances the appearance of full-size popups on the website to prevent content from blending with transparent backgrounds. A 10px margin and a default white background have been added to improve visual separation and readability, ensuring a clearer user experience.
Original PR description
The full-size option for popups could be misleading when using transparent backgrounds, as the dialog content could visually merge with the page and become hard to read. This change keeps the same…
The full-size option for popups could be misleading when using transparent backgrounds, as the dialog content could visually merge with the page and become hard to read. This change keeps the same behavior as other popup sizes while adding a 10px margin on both sides of the snippet. It also applies a default white background in full-size mode, ensuring better visual separation and improved readability. | Before | After | | ------------- | ------------- | | <img width="1646" height="456" alt="image" src="https://github.com/user-attachments/assets/122b266d-8391-45fe-a6be-08177b97f99c" /> | <img width="1659" height="466" alt="image" src="https://github.com/user-attachments/assets/df4e09de-850e-4735-9169-5115465c1372" /> | | <img width="1641" height="707" alt="image" src="https://github.com/user-attachments/assets/51d549f8-f7ff-42de-aba1-52ab0b4adaf0" /> | <img width="1655" height="687" alt="image" src="https://github.com/user-attachments/assets/2085b8ec-f318-4f04-a9ed-af8ecb0d6fa8" /> | task-5435802
This update adds helpful guidance to the Odoo POS pricing tool, specifically for the `pos.pricer` and `pricer.tag` models. This change simplifies the setup process for new users and administrators, making it easier to configure pricing strategies within the system.
Original PR description
Following this commit: ==== - Added help for pos.pricer and pricer.tag models to ease implementation for new user. task-5462933
Resolved issues and error corrections
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with approved expenses are now correctly copied, improving the accuracy and completeness of financial records. This resolves a previous reporting discrepancy.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update resolves an issue where applying a zero-amount discount in the sales order system caused an error. The fix ensures the system handles zero discounts gracefully, preventing a division-by-zero error and allowing users to correctly apply discounts when needed. This improves the reliability of the sales order discount functionality.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The system now checks for read access to the related record before redirecting, ensuring a smoother signing experience.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
This update resolves an issue where the date range picker in the website sale section was unintentionally resetting its selected dates, causing disruption for users. The fix targets overly broad selectors that triggered this restart. This change ensures a smoother and more reliable experience when selecting date ranges for sales.
Original PR description
The selectors in some of the `stopInteractions`/`startInteractions` calls were too broad, resulting in a restart of the daterange picker interaction. However, this interaction is stateful, and restarting it resets its dates. task-5118772 Enterprise PR: https://github.com/odoo/enterprise/pull/98161
This update corrects a bug where half-day leave requests were incorrectly calculated as full days. The fix removes a problematic filter, ensuring that half-day 'sandwich leave' requests (like December 12-15, 2025) now accurately display a duration of 2 days instead of 4. This improves the accuracy of leave time tracking for Indian companies.
Original PR description
**Steps:** 1. Install the `l10n_in_hr_holidays` module and create an Indian company 2. Create a time-off type that has `half-days` as the request unit and set "sandwich leave" to true 3. Create a leave request from December 12 to December 15, 2025 it should display a duration of 2 days instead of 4 **Cause:** The filter was removing leaves that had `half-day` set as the request unit **Fix:** The half-day filter is removed. In `_l10n_in_is_full_day_request` method we will check for actual half-day leave If the `request_date_from_period` and `request_date_to_period` are the same, then it is not considered a full-day leave, and it will not be calculated as a sandwich leave. Task-5427415 Forward-Port-Of: odoo/odoo#243617 Forward-Port-Of: odoo/odoo#240542
This update optimizes the ThemeSelector rendering in mass mailing tests to reduce delays and improve test reliability. Additionally, unnecessary assets used during testing have been removed, significantly speeding up test execution times. This ensures more consistent and faster testing of the mass mailing functionality.
Original PR description
The ThemeSelector rendering was optimized ([commit]) to minimize UX transition delays for the user, but that makes it a bit tricky to wait for in tests. This commit adds a function to properly wait for everything required to select a theme/favorite by clicking on it, in order to reduce non-determinism in `mass_mailing` tests. [commit]: https://github.com/odoo/odoo/commit/0f7ee1764e8b59029003c6ad7269e185b30c6b43 It also removes some assets loading during `mass_mailing` tests that are not relevant. This helps shave off 10-40% test time per test, depending on the complexity of the test. runbot-error-237513 runbot-error-237747 runbot-error-237769 runbot-error-237770 runbot-error-237772 task-5500038 Forward-Port-Of: odoo/odoo#243972
This update corrects a visual glitch in the HTML Builder module for Firefox, specifically preventing a white gap from appearing after undoing actions with tall snippets. The fix involves adjusting how snippets are scrolled to the top, improving the user experience and ensuring consistent rendering.
Original PR description
Steps to reproduce: - On Firefox, drop a snippet taller than the page height. - Remove it. - Undo. => The page shows a white gap until you scroll again. Same issue when showing a hidden tall snippet. After investigation, no real explanation was found for this bug in Firefox. We only observed that changing the "center" parameter to "start" in the "scrollIntoView" function fixes the issue. In the end, this is not a bad idea, since scrolling a snippet to its beginning arguably makes more sense than centering it, especially when the snippet’s height is larger than the viewport. task-5194559 Forward-Port-Of: odoo/odoo#241518
A customer modified Gift Card and E-Wallet products to be treated as stock items, leading to inventory discrepancies. This fix prevents these products from being automatically converted back to service types, maintaining accurate stock levels. Given multiple similar requests, a more general solution is being considered.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update removes unnecessary system notifications (like user joins/leaves) from appearing on leads. These notifications were distracting and irrelevant to users. This change improves the lead management experience by streamlining information.
Original PR description
Before this commit, system notifications such as "user join/leave the chat" would be displayed in the created lead/ticket. Those messages are not useful in anyway and should be excluded. task-5491212 enterprise: https://github.com/odoo/enterprise/pull/104336 Forward-Port-Of: odoo/odoo#243856
This update fixes a technical issue where failed IoT driver actions were incorrectly recorded, preventing them from being re-executed. Now, actions are only registered upon successful completion, improving the overall reliability and efficiency of the IoT driver system. This ensures actions are properly tracked and can be retried if needed.
Original PR description
We currently reject an action if it has the same id of a previous one. If the action failed, we still registered it, making it impossible to be executed again. We now only register if the action succeeds. Forward-Port-Of: odoo/odoo#244045 Forward-Port-Of: odoo/odoo#243247
This update ensures that when a module is imported with demo data, a flag is set to indicate this. This improvement will enhance our testing process by providing more accurate information about demo data usage, particularly in industry-standard tests.
Original PR description
Currently even if an imported module was imported with demo data, the 'demo' field is not set to True. Setting this field properly will allow to have a better handling of demo data in industry tests.
This update resolves an issue where the USB printer functionality was intermittently failing due to a problem with how the system handled printer data reads. The fix ensures that the printer continues to function correctly, even when data isn't immediately available, preventing disruptions to printing operations.
Original PR description
When using the `python-escpos` library with a USB printer, we had to patch the read method to retry due to the result not always being immediately available. However, in the case where all the retries are exhausted, it currently returns `None`, whereas the library always expects a `bytes` result. This commit fixes the issue by returning `b""` when no result can be read. This prevents the `python-escpos` functionality from being disabled when the printer lid is open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244043
This update resolves a recurring test failure in the HTML editor's toolbar. The issue stemmed from the toolbar being a popover, requiring more than just a single animation frame to fully update. By using a 'waitFor' mechanism, the test is now more reliable and consistent, preventing disruptions to automated testing.
Original PR description
Waiting one animation frame for the toolbar to update is not enough because the toolbar is a popover and is therefore affected by [1]. Use `waitFor` to avoid non-deterministic test failures on runbot. runbot-237773 [1]: https://github.com/odoo/odoo/commit/54da715df84789f9a1acc0cfc91be41dcdbab140 Forward-Port-Of: odoo/odoo#243568
This update fixes a reporting issue in the Point of Sale module. It now includes 'done' state invoices (completed sales) in the session sales statistics, providing a more accurate picture of sales performance. This ensures that all finished transactions are reflected in the session summary, leading to better business insights.
Original PR description
When computing the sales statistics for a POS session, include invoiced orders (state 'done') along with paid orders (state 'paid'). This ensures that all completed transactions are accounted for in the session summary. opw-5475876 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242808
This update resolves a technical issue where browser translation plugins were interfering with article editing and auto-save functionality. By adding a 'translate="no"' attribute to article content, we've ensured that original content is preserved and edits are saved correctly.
Original PR description
Description: Browser translation plugins were altering articles by replacing the original content with translated versions, which caused issues when paired with auto-save. To prevent this behavior, the attribute `translate="no"` has been added to the `<div>` containing the article edits. task-5485078
18 changes
Resolved issues and error corrections
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with approved expenses are correctly copied, improving the accuracy of financial reporting. This prevents data loss and provides a more complete record of expenses.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update fixes a bug where changes to analytic distribution weren't being saved correctly when editing a line in the Bank Reconciliation Widget. Now, when you leave the line editing field, the analytic widget automatically closes and retains your changes, mirroring the behavior of other widgets like invoices. This ensures data consistency and a smoother user experience.
Original PR description
**Issue** When editing a line on the reco widget, close and keep change on analytic widget on unfocus **Steps to Reproduce** 1. Activate Analytic Accounting 2. Go on the Bank Reconciliation Widget 3. Edit a line 4. Change the Analytic Distribution. 5. Click elsewhere. 6. The Analytic Widget should close and keep the changes. (as it does on invoices) **Fix** Properly detect the condition for closing the widget. task-5232476 Forward-Port-Of: odoo/odoo#234398
This update resolves an issue where applying a zero-amount discount in the sales order system would cause an error. The fix ensures the system handles zero discounts gracefully, preventing disruptions to the sales process. This improves the reliability of discount application.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system checks for read access to the related record before redirecting, eliminating these errors and improving the user experience.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
This update fixes an issue where gift card PDFs were generated even after the card's points were fully used. The change ensures that PDFs are only created for gift cards with a remaining balance, streamlining the POS process and reducing unnecessary reports. This improves the user experience and prevents redundant document generation.
Original PR description
**Steps to produce:** - Install `pos_loyalty` module. - Go to POS > select clothes > Load sample data > Buy one gift card. - Now make another order > add product above 50 > use the gift card. -…
**Steps to produce:** - Install `pos_loyalty` module. - Go to POS > select clothes > Load sample data > Buy one gift card. - Now make another order > add product above 50 > use the gift card. - Complete payment. **Issue:** - Even when the gift card is fully consumed (its points are reduced to 0), a gift card PDF is still generated after the POS payment. **Root cause:** - In `_process_existing_gift_cards` ([1]), when a gift card is updated, it is always added to `updated_gift_cards` and returned. - Later, at [2], all gift cards in updated_gift_cards are used to generate and print PDFs, without checking whether the remaining points are 0. **Solution:** - Do not generate or print a PDF for gift cards whose points are 0 after being updated. Only gift cards with a positive remaining balance should be included for PDF generation. [1]https://github.com/odoo/odoo/blob/57206cc4e3dd988382a063517546ca5dcd74da58/addons/pos_loyalty/models/pos_order.py#L236-L237 [2]https://github.com/odoo/odoo/blob/57206cc4e3dd988382a063517546ca5dcd74da58/addons/pos_loyalty/models/pos_order.py#L132-L133 opw-5474006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual glitch in Firefox where the page would jump after undoing actions involving tall snippets. The team adjusted how snippets are scrolled to the top, which is now the preferred behavior for larger snippets. This ensures a smoother and more consistent user experience.
Original PR description
Steps to reproduce: - On Firefox, drop a snippet taller than the page height. - Remove it. - Undo. => The page shows a white gap until you scroll again. Same issue when showing a hidden tall snippet. After investigation, no real explanation was found for this bug in Firefox. We only observed that changing the "center" parameter to "start" in the "scrollIntoView" function fixes the issue. In the end, this is not a bad idea, since scrolling a snippet to its beginning arguably makes more sense than centering it, especially when the snippet’s height is larger than the viewport. task-5194559 Forward-Port-Of: odoo/odoo#241518
This update fixes an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The change ensures that read-only users with accounting permissions can now view customer statements, improving usability for a wider range of users. This resolves a restriction in user access controls.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update removes a redundant CSS class from the Point of Sale module. The class was previously set to a maximum width but was no longer being used. This cleanup improves the codebase and reduces potential styling conflicts, ensuring a cleaner user interface.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/243770 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243831
A customer modified gift card and e-wallet products to be tracked in stock, which caused a technical inconsistency. This fix prevents these products from being automatically converted back to service types, maintaining accurate stock levels. Given multiple similar requests, a broader solution is being considered.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update resolves an issue where the USB printer functionality would stop working when a printer lid was open. The fix ensures the printer driver correctly handles situations where data isn't immediately available, preventing unexpected errors and maintaining reliable printing.
Original PR description
When using the `python-escpos` library with a USB printer, we had to patch the read method to retry due to the result not always being immediately available. However, in the case where all the retries are exhausted, it currently returns `None`, whereas the library always expects a `bytes` result. This commit fixes the issue by returning `b""` when no result can be read. This prevents the `python-escpos` functionality from being disabled when the printer lid is open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244043
This update fixes a minor issue in the Point of Sale tour testing process. By adding a final check to ensure a paid order exists, the tour now reliably completes. This ensures that the testing process is consistent and accurate, preventing potential disruptions to the tour.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where numbers extracted from OCR boxes were incorrectly formatted due to language settings. The change simplifies the parsing process by consistently using a standard Javascript `Number` parser, ensuring accurate number representation regardless of the user's language. This improves data integrity for financial transactions.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979)
This update resolves an issue where gift cards were being printed repeatedly during point-of-sale transactions. Now, gift cards are only printed once at the time of creation, streamlining the process and reducing unnecessary printing. This improves efficiency and reduces waste.
Original PR description
*: pos_loyalty Gift card are now printed only one time at the creation not after each use.
This update corrects a bug in how the system determines if a stock location is a child of another. The change uses a more precise method (`indexOf`) to ensure accurate sublocation identification, preventing errors that could cause test failures. This improves the reliability of stock operations.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update corrects a bug in the HTML editor that was causing an error when attempting to remove formatting from cells with lingering colors. Previously, deleting text and leaving a colored cell would trigger an infinite loop. Now, users can reliably remove formatting from empty colored cells without encountering this issue.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242938 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where filtering work entries by country wasn't functioning properly, leading to errors. The fix ensures country-based searches and filters work as intended, resolving a technical problem that prevented accurate reporting and data management. This improves the reliability of our HR data.
Original PR description
Issue: The country_id related field on work entries was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter on field to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/odoo#243428 Forward-Port-Of: odoo/odoo#239573
This update resolves a technical error that prevented users in India from successfully processing payments through Razorpay within the Point of Sale (POS) system. The issue stemmed from an attempt to use 'sudo' on a Razorpay-related object, which wasn't designed to support this function. Removing this unnecessary access ensures smooth payment processing.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update resolves an issue preventing stable IoT Box responses from being correctly read. By adding a check for a 'result' key in the data, the system now reliably processes data from these terminals, ensuring smoother operation. This enhances the overall stability and usability of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
8 changes
Resolved issues and error corrections
This update resolves a technical error that prevented users in India from processing payments through Razorpay within the POS system. The issue stemmed from an attempt to use 'sudo' on a payment request object, which wasn't designed to support this function. This fix ensures smooth payment processing for Indian customers.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634
This update fixes a potential issue where location IDs could incorrectly identify related locations, leading to test failures. The change replaces a method of checking location hierarchy with a more reliable approach, ensuring accurate stock barcode processing. This resolves a build error and improves the stability of the stock module.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update fixes a bug that caused the survey session manager to fail when a question was deleted. The issue stemmed from incorrect data handling when a question was removed, leading to an error. This change ensures the session manager functions correctly even after questions are deleted, improving user experience.
Original PR description
Currently, an error occurs when opening the session manager after deleting a question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, add two questions, and click…
Currently, an error occurs when opening the session manager after deleting a question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, add two questions, and click `Create Live Session`. - Complete the survey and leave it on the `Thank You` page. - Switch back to the first tab, delete the second question, and click `Open Session Manager`. (Refer [this](https://drive.google.com/file/d/1_f7OwV6h2gWd-CluCYc7HpOXyDMIqGga/view?usp=sharing) for step to produce.) **Error:** `ValueError: False is not in list` **Root Cause:** At [1], the code assumes the `page_or_question` exists and tries to access `.index(page_or_question.id)`, but when the question has been deleted, `page_or_question.id` is `False`, causing an `error`. **Fix:** This commit prevents a crash when opening the session manager if the question was deleted. [1]: https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/survey/models/survey_survey.py#L810 sentry-5285798473
A bug was causing overdue invoices to appear twice in PDF follow-up reports. This update corrects a process error where invoices were incorrectly re-attached during report generation, ensuring invoices now appear only once in the final PDF. This improves the accuracy of follow-up reminders.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870
This update fixes a crash that occurred when Odoo users synced Google Calendar events with invalid timezone information. The system now gracefully handles invalid timezones by defaulting to UTC, preventing disruptions to the calendar sync process. This improves the reliability of Google Calendar integration.
Original PR description
- When users attempt to sync Google Calendar with Odoo, a crash occurs if the event’s timezone is invalid.
- In Sentry, we have observed multiple occurrences of this issue.
**Error: -**
`UnknownTimeZoneError: 'GMT+05:30'`
**Cause: -**
- At [1], we call `pytz.timezone` and if `self.event_tz` contains an invalid timezone string, `pytz` raises a time zone error, causing the sync to fail.
**Solution: -**
- Wrap the `pytz.timezone` call in a `try/except`.
- First, attempt with `self.event_tz or self.env.context.get('tz') or 'UTC'`.
- If that fails due to an invalid timezone, gracefully fall back to `UTC`.
[1]
https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/calendar/models/calendar_recurrence.py#L513
**sentry-6738882905**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where image saving in the HTML editor would fail due to missing data, often caused by browser extensions. The fix adds a validation step to ensure the image source exists before attempting to save, preventing a 'bool' object is not subscriptable' error.
Original PR description
Third-party extensions like ad blockers or image blockers might remove base64 encoded data from the frontend when an image is changed or when the page doesn’t load correctly using the `html_editor`.…
Third-party extensions like ad blockers or image blockers might remove base64 encoded data from the frontend when an image is changed or when the page doesn’t load correctly using the `html_editor`. In the video [1], this problem is shown by manually removing the base64 data for replication. It’s suspected that these common browser extensions could be causing the issue since this error has appeared in multiple databases. **Error:** `TypeError: 'bool' object is not subscriptable` **Root cause:** * Since data is `None` at [2], the checksum is not computed and remains `False` because [3] is not called. This leads to an error at [4] when attempting to index it. **Solution:** * Add an additional validation to check if the checksum exists. If it does not, set the image source to `False`. [1]: https://drive.google.com/file/d/1fC0HlvVKfkcAAit7UhQWDM9r4O3jMutF/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/95ed5c75582631c7cc417b000569ff6451cc5006/addons/html_editor/controllers/main.py#L368 [3]: https://github.com/odoo/odoo/blob/95ed5c75582631c7cc417b000569ff6451cc5006/odoo/addons/base/models/ir_attachment.py#L280 [4]: https://github.com/odoo/odoo/blob/95ed5c75582631c7cc417b000569ff6451cc5006/addons/html_editor/models/ir_attachment.py#L54 sentry-6776476775
This update fixes a crash that occurred when loading demo employee data. The issue was caused by deleting the 'Administrative department' before attempting to load the demo data. The fix ensures that the system handles missing departments gracefully.
Original PR description
The system crash with error when user tries to load demo data of employees. **Steps to produce:-** - Install the `Attendances` module without demo data. - Navigate to `Employees > Departments` and…
The system crash with error when user tries to load demo data of employees.
**Steps to produce:-**
- Install the `Attendances` module without demo data.
- Navigate to `Employees > Departments` and **delete** the `Administrative department`.
- **Remove** all employees.
- Go to `Attendances > Load Demo`.
- Observe the error.
**Error:-**
```py
ValueError: External ID not found in the system: hr.dep_administration
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/hr/data/scenarios/hr_scenario.xml:126, somewhere inside <record id='employee_mw' model='hr.employee' forcecreate='1'>
<field name='active'>True</field>
<field name='name'>Michael Williams</field>
<field name='private_street'>349-943 Miania St.</field>
<field name='certificate'>master</field>
<field name='private_zip'>58198</field>
<field name='private_city'>Williston</field>
<field name='private_country_id' ref=base.us/>
<field name='private_phone'>+1 555-555-5757</field>
<field name='work_email'>williams@mycompany.example.com</field>
<field name='department_id' ref='hr.dep_administration'/>
<field name='job_id' ref='job_ceo'/>
<field name='job_title'>Chief Executive Officer</field>
<field name='company_id' ref='base.main_company'/>
<field name='category_ids' eval='[Command.set([ref('emplo...
```
- The error occurs because the user deleted the Administrative department, and then try to load data, that reference the deleted department.
- This commit resolves the error by providing a False value for the field if the employee department is missing.
**sentry-6856979884**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents a potential error when refreshing YouTube access tokens. Previously, an empty response from the YouTube endpoint would cause a parsing error. The fix now gracefully handles empty responses by using an empty dictionary, ensuring the system continues to function correctly.
Original PR description
When refreshing the YouTube access token, the endpoint may return an empty response.
**Error:**
`JSONDecodeError - Expecting value: line 1 column 1 (char 0)`
**Cause:**
The method directly calls `.json()` on the response without validating whether the body is non-empty or valid JSON.
**Fix:**
This commit wraps the request handling in try/except and fall back to an empty dict (`{}`) when the response cannot be parsed as JSON.
sentry-68497112892 changes
Enhancements to existing features
This update ensures that Thai province names within Odoo are displayed in their native Thai language. This improves consistency and accuracy for users operating in Thailand, aligning with local naming conventions.
Original PR description
State names are not translatable in Odoo, so they should be stored in their native language for consistency. This PR updates all Thai provinces to use their native Thai names. task-5484432
Resolved issues and error corrections
This update fixes an issue where tooltips on the Contact Us page weren't displaying translated text. The fix ensures that saved website snippets, including their translations, are correctly applied when dropped on the Contact Us page, resolving a previous display problem.
Original PR description
Issue: Tooltip not retaining translations Steps to Reproduce : - Have a website with English as main lang and French as second lang. - Drop an image block and set a tooltip on it - Save and translate…
Issue: Tooltip not retaining translations Steps to Reproduce : - Have a website with English as main lang and French as second lang. - Drop an image block and set a tooltip on it - Save and translate the tooltip in French - In english, save the block with the image (to be able to reuse it elsewhere) - When you drop the block in a website pages or event pages, the tooltip keeps its translation, but if you drop it in the /contactus page, the tooltip has no translation. Before this PR: - A saved custom snippet would not retain its translations when dropped for the first time on the "Contact Us" page. - This occurred because the `ir.ui.view` model had only one record for `website.contactus` with `website_id=NULL`. When the snippet was dropped, a new `ir.ui.view` record was created for `website_id=1` (or the current website). During this process, only the English `jsonb` content of the snippet was added to the `arch_db` field of `ir.ui.view`. After this PR: - The saved custom snippet now retains its translations when dropped for the first time on the "Contact Us" page. Task-4543654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr