Daily updates from Odoo
Navigate
Branch
Friday, January 16, 2026
308 changes
32 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
This update introduces a new feature to the Finnish l10n reports, specifically the EC Sales List and Tax reports. It now provides customers with clear return deadlines and allows them to verify report accuracy before submission, improving reporting compliance and reducing potential errors.
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
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
This update enables public users to access documents via a link without needing to create a standard user account. Previously, inviting a public user would force them to register, creating a separate user. Now, the public user's registration is linked to the document access, streamlining the sharing process and improving usability.
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
Resolved issues and error corrections
This update resolves a problem that prevented the tax module from loading correctly during database upgrades. The fix disables tracking computations during the module's loading process, preventing errors that were causing delays and failures. This ensures smoother database upgrades and avoids disruptions to the system.
Original PR description
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.
```py
/home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```
Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.
```py
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
tracking = records.with_context(context)._message_track(fnames, initial_values)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
record._message_log(
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```
This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae
The resulting tracking computation crashes with a KeyError when processing repartition line diffs.
Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.
opw-5467986
upg-3753990
tbg-2380
Forward-Port-Of: odoo/enterprise#103931This 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 resolves two issues impacting the website editor. First, it fixes blurry countdown canvases and text when zooming, ensuring sharp visuals at any scale. Second, it prevents text overlap with icons, particularly when using the Unsplash photo option, improving the overall user interface.
Original PR description
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the…
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the countdown canvas and text appears blurry The countdown was rendered at a low resolution, which caused it to blur when zooming. This fix updates the canvas to draw at the proper resolution so the countdown remains sharp at any zoom level. ## [FIX] web_editor: prevent text overlap with icon [Commit 2] Steps to reproduce: - Go to Website -> Edit Mode - Add a Image snippet - Enter a long text in search bar: Issue: 1. Text overlaps with search icon. 2. Selecting the "Photos (via Unsplash)" option causes the text to overlap the dropdown icon. The fix adjusts the end padding to provide sufficient spacing between the text and the icons. task-[4771268](https://www.odoo.com/odoo/project/974/tasks/4771268) Forward-Port-Of: odoo/odoo#242814 Forward-Port-Of: odoo/odoo#213373
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 fixes formatting issues in live chat ticket descriptions created by the chatbot. Previously, system notifications were included, making tickets difficult to read. Now, only relevant chat messages are used, ensuring clearer and more organized ticket descriptions for support agents.
Original PR description
In [1], chat bot's create lead/ticket steps were improved to set the formatted discussion as the lead/ticket description. The same holds for lead/ticket commands. However, the /ticket command was not properly updated. As a result, the discussion is poorly formatted, making it difficult to read. Also, the description should only include relevant messages, not system notifications such as "agent joined the channel". This commit fixes both issues. task-5491212 community: https://github.com/odoo/odoo/pull/243856 Forward-Port-Of: odoo/enterprise#104336
This update fixes an issue where payment advice reports (PDF and XLSX) were incorrectly displaying only the first bank account when employees had multiple salary distributions. The fix ensures that all bank accounts with salary splits are accurately reflected in the payment advice, providing correct financial reporting.
Original PR description
Issue: When an employee had multiple bank accounts with salary distribution, the payment advice (PDF and XLSX) was displaying only the first bank account and assigning the full salary amount to that account. This resulted in incorrect payment information being generated. Fix: When multiple bank accounts are configured with salary distribution, the payment advice now displays the correct information in both PDF and XLSX reports. task-5390429 Forward-Port-Of: odoo/enterprise#101818
This update resolves an issue where overtime work entries were incorrectly generated, even when overtime rules were disabled. It also fixed a bug where regenerating work entries caused shifts in attendance hours across consecutive days. The fix ensures accurate overtime calculations and consistent results during payroll regeneration.
Original PR description
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that…
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that normally generates overtime. - Navigate to the work entries in payroll. - Overtime work entries are created! This fix will skip generating work entries when their will be no `paid` rules in a ruleset. # Bug 2: ## Steps to reproduce: - Create attendances with overtime for multiple consecutive days. - Navigate to Work Entries in Payroll. - Click on Reset->"Regenerate Work Entries” on the same period for bulk regeneration. - Observe that attendance and overtime hours are shifted between days. ### Fix: In `_get_overtime_intervals`, the overtime list was recreated inside the per-day loop, causing previously computed overtime intervals to be lost when multiple days were involved. Overtime intervals are now accumulated per resource across all days in the requested range before building the final Intervals. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151) Forward-Port-Of: odoo/enterprise#103028
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 resolves a validation error that occurred when creating partial backorders within wave transfers. The issue stemmed from the system incorrectly processing ongoing batches, leading to validation failures. This change ensures that the system accurately handles backorder creation and prevents these errors.
Original PR description
## How to reproduce: - Enable Wave transfert in setting - Go to the Receipt Operation type: - Create Backorder: always - Automatic Batches: Enabled - Wave Grouping: Products - Create and confirm…
## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
- Create Backorder: always
- Automatic Batches: Enabled
- Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."
## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.
## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.
OPW-5413921
---
Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ...
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ======================================================================
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
wave.action_done()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
return pickings.with_context(**context).button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
res = super().button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
records.write({self.name: write_value})
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
self.batch_id._sanity_check()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243873
Forward-Port-Of: odoo/odoo#243519This 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 provides users with more detailed error messages when sending documents to HMRC, including the specific error code and message returned by the system. This change simplifies troubleshooting and reduces the need for support, leading to faster issue resolution.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests. Forward-Port-Of: odoo/enterprise#104407
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 fixes a problem where users received unclear error messages when cash point closing with Fiskaly failed. The change now displays the full response from Fiskaly, providing more detailed information to help users quickly diagnose and resolve the issue. This improves the user experience and reduces troubleshooting time.
Original PR description
When a cash point closing fails with Fiskaly, the error message shown to the user was not very informative. This commit enhances the error message to include the actual response from Fiskaly, making it easier for users to understand what went wrong. opw-5461084 Forward-Port-Of: odoo/enterprise#103358
5 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 resolves a critical issue causing the IoT Box to freeze when used as a kiosk. The team updated the browser configuration to correctly pass arguments, preventing excessive memory consumption and restoring stable operation. This ensures consistent performance for our IoT Box deployments.
Original PR description
In odoo/odoo#233676 we switched from `chromium-browser` to `chromium` to adapt to new executable name in raspbian. We also need to update this name in the check to set the arguments of the browser, or they will never be passed. This fixes the issue where the IoT Box freezes when using it for kiosk, as the browser was eating all the memory. Forward-Port-Of: odoo/odoo#243979
6 changes
Resolved issues and error corrections
This update enhances how users access messages and search results within Odoo, ensuring consistency and proper permissions across different scenarios like portals and activities. It addresses previous inconsistencies in access checks, particularly for portal users and activity scheduling, improving the overall user experience.
Original PR description
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need…
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need write access to create a message (post) but on some models you can post when you can read. Calendar events message access depends on calendar privacy settings. This is controlled via '_get_mail_message_access'. However currently it is "globally called", for all documents. It should be done on a per-document basis, as each document could define different access check. Keep code somewhat optimized by doing access checks in batch for a given operation. Make _search and read symmetric. Reading documents should be allowed on search results, and search results should match what is available for reading. Portal users have some specific domains applied when accessing messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for 'website_message_ids' domain, mail controllers, ...). However there are still some cases where search and read are not coherent with portal users. This is not really annoying as most messages are accessed using sudo and correctly tailored domains via controllers but let us try to have a more correct code. Fix discuss display of chatter-related buttons * not taking into account '_get_mail_message_access' to check if user has right to post (generally used to indicate users can post on readonly records, but not limited to that); * not adding the same check on Activities button as on Send message and Log note. We consider generally that rights should be aligned and UX should match that behavior; * not adding the same check on attachments buttons, currently limited to write access (or always accessible). This is a preliminary work for attachments, further fixes are probably incoming; Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 . Task-5138368 opw-4785878 Forward-Port-Of: odoo/odoo#244009 Forward-Port-Of: odoo/odoo#233725
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 technical issue preventing the IoT Box from functioning correctly as a kiosk. The change ensures the browser receives necessary arguments, preventing excessive memory usage and subsequent freezing. This improves the stability and usability of the IoT Box.
Original PR description
In odoo/odoo#233676 we switched from `chromium-browser` to `chromium` to adapt to new executable name in raspbian. We also need to update this name in the check to set the arguments of the browser, or they will never be passed. This fixes the issue where the IoT Box freezes when using it for kiosk, as the browser was eating all the memory. Forward-Port-Of: odoo/odoo#243979
This update fixes an issue where custom button snippets weren't consistently appearing in the website editor. The code was updated to correctly handle button snippets next to existing buttons, preventing incorrect wrapping and ensuring all custom snippets are displayed correctly. This improves the usability of the website editor for creating and managing custom buttons.
Original PR description
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur…
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur with standard button snippets or when the buttons were wrapped in a `<p>` tag. ### Steps to reproduce: 1. Drag a standard "Button" snippet next to an existing button (e.g., in the navbar). The structure is correctly `<a/><a/>`. 2. Save a button as a custom snippet. 3. Drag this new custom button snippet next to a button wrapped in a `<div>` (navbar in our example). 4. Observe the structure: `<div><a/><p><a class="s_custom_snippet"/></p></div>`, but it should be like `<div><a/><a class="s_custom_snippet"/></div>`. ### Fix The logic has been corrected to only wrap a button snippet in a paragraph tag if it has no sibling buttons and is not already inside a `<p>`. This ensures consistent behaviour between standard and custom button snippets. A tour test is also added, ensuring the behaviour is correct. Backport of https://github.com/odoo/odoo/commit/3a8f2cc418510c3b91f8b9086bb4a89a1745e40d task-[5032130](https://www.odoo.com/odoo/project/974/tasks/5032130) Forward-Port-Of: odoo/odoo#241937 Forward-Port-Of: odoo/odoo#224476
This update provides users with more detailed error messages when sending documents to HMRC, including specific error codes and messages from HMRC itself. This allows for quicker identification of issues and reduces the need for support, streamlining the process for users.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests. Forward-Port-Of: odoo/enterprise#104407
5 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 corrects a bug where custom button snippets were incorrectly wrapped in paragraph tags when placed next to existing buttons. The fix ensures custom buttons are consistently displayed in the snippet panel, improving usability for users creating and managing buttons. This resolves an issue where custom buttons weren't always visible.
Original PR description
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur…
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur with standard button snippets or when the buttons were wrapped in a `<p>` tag. ### Steps to reproduce: 1. Drag a standard "Button" snippet next to an existing button (e.g., in the navbar). The structure is correctly `<a/><a/>`. 2. Save a button as a custom snippet. 3. Drag this new custom button snippet next to a button wrapped in a `<div>` (navbar in our example). 4. Observe the structure: `<div><a/><p><a class="s_custom_snippet"/></p></div>`, but it should be like `<div><a/><a class="s_custom_snippet"/></div>`. ### Fix The logic has been corrected to only wrap a button snippet in a paragraph tag if it has no sibling buttons and is not already inside a `<p>`. This ensures consistent behaviour between standard and custom button snippets. A tour test is also added, ensuring the behaviour is correct. Backport of https://github.com/odoo/odoo/commit/3a8f2cc418510c3b91f8b9086bb4a89a1745e40d task-[5032130](https://www.odoo.com/odoo/project/974/tasks/5032130) Forward-Port-Of: odoo/odoo#241937 Forward-Port-Of: odoo/odoo#224476
This update corrects a technical issue that caused the IoT Box to freeze when used as a kiosk. The team adjusted how the browser arguments are passed, preventing excessive memory consumption and ensuring stable operation. This resolves a critical bug impacting the functionality of our IoT Box devices.
Original PR description
In odoo/odoo#233676 we switched from `chromium-browser` to `chromium` to adapt to new executable name in raspbian. We also need to update this name in the check to set the arguments of the browser, or they will never be passed. This fixes the issue where the IoT Box freezes when using it for kiosk, as the browser was eating all the memory. Forward-Port-Of: odoo/odoo#243979
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
This update provides users with detailed error messages from HMRC when document sending fails, instead of generic alerts. By displaying the specific error code and message, users can quickly diagnose and resolve issues, reducing support requests and improving efficiency.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests. Forward-Port-Of: odoo/enterprise#104407
24 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 pull request streamlines the Odoo website's rental functionality by simplifying the underlying code and improving performance. Specifically, it removes redundant code, centralizes timezone handling, and ensures accurate date calculations, resulting in a smoother and more reliable user experience for customers.
Original PR description
In particular: - Move the website timezone into the session. This allows us to avoid explicitly fetching the timezone from the server and having to pass it around in the renting-related JS code. - Drop the renting mixin. Instead, we now use a stateless renting utils class for shared code (without `this` references). Any code that was only used in a single Interaction has been moved into said Interaction. - Rely on dataset instead of hidden inputs. - Remove the client-side default date computation, and solely relies on the server-side default date computation. As a result, the daterange inputs are correctly populated during the initial load, and the customer doesn't see any flickering. - Fix a few client-side issues. task-5118772 Community PR: https://github.com/odoo/odoo/pull/234405
This update improves the Odoo Enterprise HR app by allowing appraisal managers to easily view their next scheduled appraisal date. Previously, this information was hidden, making planning difficult. Now, managers have a clear, readily available view of upcoming appraisals.
Original PR description
Before: * Appraisal managers couldn't see their next appraisal date if the user have access of employee public view. * The field was only accessible in settings, making planning harder. After: * Added a read-only next_appraisal_date below the manager field. * Added a field which will be computed to whether show the next_appraisal_date or not. Impact: * Helps managers quickly view upcoming appraisal dates. task-5366841
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
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 fixes an issue where US clearing numbers were not being correctly identified in Odoo, leading to errors in exports and payroll processing. The fix ensures the correct country code is used when retrieving clearing numbers for US-specific transactions, resolving problems with direct deposit, NACHA payments, and US payroll reports.
Original PR description
*: l10n_us_check_printing, l10n_us_direct_deposit, l10n_us_hr_payroll, l10n_us_hr_payroll_account, l10n_us_payment_nacha Post the res_partner_bank refactor at odoo/odoo#234974 all clearing/routing numbers are retrieved via `_get_clearing_number` calls. However, all of the ones for the US were missing the correct country_code parameter, which broke direct deposit, nacha and iso batch payment exports, check printing, and US payroll. This is because the US by default has it's own custom clearing label record `clearing_label_us` which has a country set, and since `_get_clearing_number` compares the country it will always return None. This was missed in the test cases as they were hardcoded to `clearing_label_all` which lets the blank case through.
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 two issues impacting the website editor. First, it fixes blurry countdown displays when zooming, ensuring sharp visuals. Second, it prevents text overlap with icons, particularly when using the search bar or the Unsplash photo option, improving usability and visual clarity.
Original PR description
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the…
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the countdown canvas and text appears blurry The countdown was rendered at a low resolution, which caused it to blur when zooming. This fix updates the canvas to draw at the proper resolution so the countdown remains sharp at any zoom level. ## [FIX] web_editor: prevent text overlap with icon [Commit 2] Steps to reproduce: - Go to Website -> Edit Mode - Add a Image snippet - Enter a long text in search bar: Issue: 1. Text overlaps with search icon. 2. Selecting the "Photos (via Unsplash)" option causes the text to overlap the dropdown icon. The fix adjusts the end padding to provide sufficient spacing between the text and the icons. task-[4771268](https://www.odoo.com/odoo/project/974/tasks/4771268) Forward-Port-Of: odoo/odoo#242814 Forward-Port-Of: odoo/odoo#213373
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 fixes issues where button previews and link previews displayed incorrectly after changes. Specifically, it ensures button previews accurately reflect settings after converting to links and that link previews inherit the correct theme colors from their parent elements. This improves the overall user experience and consistency of the website editor.
Original PR description
*: html_editor Issue: 1. Button previews displayed incorrectly after converting button type to link 2. Link preview displayed incorrect theme colors when parent and ancestor elements had different…
*: html_editor Issue: 1. Button previews displayed incorrectly after converting button type to link 2. Link preview displayed incorrect theme colors when parent and ancestor elements had different themes applied Steps to reproduce (Issue 1): 1. Add a button component 2. Set it to primary and modify its size/shape 3. Convert the button type to link 4. Re-open the button type dropdown 5. Observe incorrect button preview Steps to reproduce (Issue 2): 1. Add the `s_text_cover` snippet 2. Apply theme 1 (o_cc1) to Text Cover and theme 2 (o_cc2) to Column 3. Press Enter after the button 4. Start typing `/link` to create a link 5. Observe that the link preview in the powerbox dropdown shows incorrect theme colors After this commit: 1. Preview now correctly calculates based on previously configured button properties, even after type conversion 2. Link preview now correctly inherits theme styles from its direct parent element --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240527
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 fixes issues where documents weren't correctly linked to invoices and accounting records, leading to incorrect folder placement and tag assignments. The changes ensure documents are automatically moved to the correct accounting folders and receive the appropriate tags when an invoice is created or linked, improving data accuracy and streamlining workflows.
Original PR description
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation.…
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation. Fixed a regression (introduced in 2333367) where documents failed to move to the correct Journal folder and apply tags when creating a new account move. Also added a small refactor to flatten the structure. The tests added in Fix 3 would catch this regression in the future. **Fix 2:** Sync on Miscellaneous Entry Creation Previously, creating a Miscellaneous Entry (move_type='entry') from an existing document failed to move the document from its original location (e.g., "Finance") to the correct accounting folder. The existing sync logic explicitly skipped entries to avoid issues with multi-attachement invoices. **Fix 3:** Execution Order of Multi-Actions. Previously, multi-step server actions (e.g., 'Create Vendor Bill') executed child actions alphabetically. This caused the manual "Move to Taxes" action to execute after the record creation sync, effectively overriding the correct journal folder placement and moving the document to a generic folder (e.g. 'Taxes'). Changes: - Enforced a specific execution order: The document is now moved before the accounting record is created. This ensures the final automatic sync prevails. - Additionally, the action is temporarily embedded (pinned) on the intermediate folder during execution to allow the subsequent record creation to proceed even after the document has been moved to a new folder (which would otherwise fail consistency checks). Changes: - Extended `ir.attachment.write` to detect when a document is linked to an account.move of type 'entry'. - Triggers `_update_or_create_document` immediately upon linking to ensure tags and folders are synchronized. Task-5452729 Forward-Port-Of: odoo/enterprise#104022 Forward-Port-Of: odoo/enterprise#103096
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
This update optimizes how Odoo handles web sockets, particularly under heavy load. By delaying cursor acquisition attempts, the system avoids connection bottlenecks and disconnections, ensuring smoother communication for users. The changes also improve the reliability of websocket connections by ensuring proper socket cleanup.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#244013 Forward-Port-Of: odoo/odoo#241330
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 formatting issues in live chat ticket descriptions created by the helpdesk chatbot. Specifically, it ensures that chat messages are correctly included as part of the ticket and removes unnecessary system notifications. This improves the clarity and usability of tickets for support agents.
Original PR description
In [1], chat bot's create lead/ticket steps were improved to set the formatted discussion as the lead/ticket description. The same holds for lead/ticket commands. However, the /ticket command was not properly updated. As a result, the discussion is poorly formatted, making it difficult to read. Also, the description should only include relevant messages, not system notifications such as "agent joined the channel". This commit fixes both issues. task-5491212 community: https://github.com/odoo/odoo/pull/243856 Forward-Port-Of: odoo/enterprise#104336
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 resolves a validation error that occurred when creating backorders within wave transfers. The issue stemmed from the system incorrectly processing ongoing batches, leading to a user error. The fix prevents this by temporarily excluding the current batch from the auto-batching process during validation, ensuring smooth operation.
Original PR description
## How to reproduce: - Enable Wave transfert in setting - Go to the Receipt Operation type: - Create Backorder: always - Automatic Batches: Enabled - Wave Grouping: Products - Create and confirm…
## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
- Create Backorder: always
- Automatic Batches: Enabled
- Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."
## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.
## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.
OPW-5413921
---
Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ...
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ======================================================================
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
wave.action_done()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
return pickings.with_context(**context).button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
res = super().button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
records.write({self.name: write_value})
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
self.batch_id._sanity_check()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243873
Forward-Port-Of: odoo/odoo#24351922 changes
Enhancements to existing features
This update streamlines the preparation display by merging multiple orderlines for combo products that share the same base product. Previously, the POS system handled different pricing, but for preparation displays, we're standardizing the presentation to avoid confusion and improve efficiency. This change ensures a clearer view of ingredients when preparing items from a combo.
Original PR description
When ordering a combo product, the POS will split the included products from the extra products in different orderlines. This is done because of the extra products have a different price/unit than the extra items. But for the preparation display we don't care about different prices, so this PR will make the different orderlines of the same combo be merged in the preparation display if they target the same product. Task-[5473387](https://www.odoo.com/odoo/project/1737/tasks/5473387) Enterprise PR-[#104188](https://github.com/odoo/enterprise/pull/104188) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the preparation display by merging identical products from combo orders. Previously, the POS system split combo items from additional items due to price differences. Now, the preparation display consolidates these items into a single line, streamlining the order review process and reducing manual effort.
Original PR description
When ordering a combo product, the POS will split the included products from the extra products in different orderlines. This is done because of the extra products have a different price/unit than the extra items. But for the preparation display we don't care about different prices, so this PR will make the different orderlines of the same combo be merged in the preparation display if they target the same product. Task-[5473387](https://www.odoo.com/odoo/project/1737/tasks/5473387)
This update simplifies the preparation display by merging identical products within combo orders. Previously, the system treated combo items separately from add-ons due to price differences. Now, the preparation display shows all items within a combo orderline, streamlining the order preparation process and improving clarity for staff.
Original PR description
When ordering a combo product, the POS will split the included products from the extra products in different orderlines. This is done because of the extra products have a different price/unit than the extra items. But for the preparation display we don't care about different prices, so this PR will make the different orderlines of the same combo be merged in the preparation display if they target the same product. Task-[5473387](https://www.odoo.com/odoo/project/1737/tasks/5473387)
This update simplifies the preparation display by combining multiple instances of the same combo product into a single orderline. Previously, the POS split combo products from additional items based on price differences. This change ensures a cleaner, more streamlined preparation display for users, improving clarity and efficiency.
Original PR description
When ordering a combo product, the POS will split the included products from the extra products in different orderlines. This is done because of the extra products have a different price/unit than the extra items. But for the preparation display we don't care about different prices, so this PR will make the different orderlines of the same combo be merged in the preparation display if they target the same product. Task-[5473387](https://www.odoo.com/odoo/project/1737/tasks/5473387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes an issue where cash rounding (UP or DOWN methods) didn't accurately calculate change when customers paid more than the order total. The change ensures correct change calculations during transactions, improving the reliability of the Point of Sale system. This resolves a previous error impacting payment accuracy.
Original PR description
When using cash rounding with UP or DOWN methods, the change was not being calculated correctly when paying more than the total amount due. opw-5476693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the weigh scale displayed incorrect prices due to a lack of consideration for pricelists and fiscal positions. Now, the weigh scale accurately reflects the price, including any adjustments defined in a customer's pricelist or fiscal position, leading to clearer and more reliable sales transactions.
Original PR description
Before this commit, the pricelist and fiscal position where not taken into account when displaying the price on the weigh scale. This caused confusion when selling products with pricelists or fiscal positions that modified the price. opw-5456144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 previous issue where the product configurator displayed inaccurate prices. Now, the configurator correctly reflects the selected product attributes, the current order's pricelist, and fiscal position, leading to a more reliable and user-friendly experience for customers.
Original PR description
Before this commit, product configurator popup did not consider selected attributes, and pricelist or fiscal position of the current order when displaying the price of the product being configured. This could lead to confusion for the user. opw-5472946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate financial reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243801 Forward-Port-Of: odoo/odoo#238428
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 resolves an issue where the payment gateway was incorrectly sending callback URLs, causing verification problems. The fix ensures the callback URL only triggers when a redirect is expected, aligning with Razorpay's documentation and improving payment reliability. This prevents errors during payment processing.
Original PR description
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only…
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only trigger when `redirect` is `True`. Cause: - In Razorpay documentation it's not clearly mention it will only trigger `callback_url` when `redirect` is `True`, so in some cases it redirect to `callback_url` even `redirect` is `False` which is cause issue during signature verification as it try to verify signature according to `is_redirect` with `razorpay_secret` but in oAuth `razorpay_secret` is not set. Razorpay doc link: https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/integration-steps/#123-checkout-options <img width="670" height="537" alt="image" src="https://github.com/user-attachments/assets/81c855c0-aaca-4953-bcff-942bc11a32d2" /> Fix: - Only set `callback_url` for `REDIRECT_PAYMENT_METHOD_CODES` PMs where we expect it to redirect to `return_url` and not in the oAuth flow, Instead relying on the `redirect` option of the Razorpay. opw-5389499 Forward-Port-Of: odoo/odoo#243054
The website's ability to retrieve pickup locations from OpenStreetMap was failing due to a 403 error. This PR resolves this by adjusting the request headers to comply with OpenStreetMap's usage policy, allowing the system to correctly obtain and display pickup locations.
Original PR description
**Steps to reproduce:**
* Install website_sale_collect module
* Setup Geo localization with OpenStreetMap
* When customer chooses pick up location, a 403 error is sent back from
OSM
* No pickup location is returned on the map
* The message from OSM is
Code : 403... You have been blocked because you have violated the\n<a href="https://operations.osmfoundation.org/policies/nominatim/">usage policy</a>\nof
**Observed behavior:**
* No pickup location is seen on the map
**Cause:**
* we don't know what's the real cause of reject
**Fix:**
* We improve the header to have a more standard request and let OSM
respond
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis 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 streamlines the product search within our Point of Sale system, making it faster and more responsive, especially when dealing with a large number of products. By optimizing the search process, we've reduced delays and improved the overall user experience. This change focuses on internal performance improvements.
Original PR description
Previously, the product search performed normalization inside the filter and sort loops. Because sort algorithms perform O(n log n) comparisons, the `normalize` function was called redundantly thousands of times for the same product, leading to UI lag when handling large products. This commit optimizes the search by: - Moving normalization to the model getters - Flattening the template search string to include all variants, removing the need for nested `.some()` loops during filtering. - Replacing `localeCompare` with primitive string comparison for faster sorting. opw-5448113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 provides users with more detailed error messages when sending documents to HMRC, including the specific error code and message returned by HMRC. This change simplifies troubleshooting and reduces the need for support, leading to faster issue resolution.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests. Forward-Port-Of: odoo/enterprise#104407
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
1 change
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
5 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 the company tolerance time wasn't being calculated accurately when employees had multiple attendance entries for the same day. Previously, overtime was incorrectly computed, leading to inaccurate extra time calculations. This change ensures that the tolerance time is applied correctly, preventing unnecessary overtime charges.
Original PR description
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to…
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to attendances. 2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes. 3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12. ### Expected behavior As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed. ### Unexpected behavior 12 minutes of overtime are computed. ## Origin of the issue Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time. Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code. note: the same bug exists for the employee tolerance time, which is corrected in this commit. __ opw-5136861 ---
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
This update resolves an issue where predictions were incorrectly enabled during the Peppol retrieve (BIS3) process, potentially leading to data changes. By correctly passing the necessary context and adding preventative tests, this fix ensures the stability and reliability of this critical functionality within version 17.0.
Original PR description
Before this commit, the Peppol retrieve (BIS3) had the possibility of being changed because predictions were not disabled correctly due to the context not being passed properly. To avoid this issue, we now pass the context correctly and added tests to prevent future errors. This commit is specific to version 17.0, as this version requires different changes compared to upper versions. Ticket [link](https://www.odoo.com/odoo/project.task/5441710) opw-5441710
This update corrects a problem where predictions were incorrectly enabled during the Peppol retrieve (BIS3) process, potentially leading to data changes. By ensuring the correct context is passed and adding preventative tests, this fix enhances the stability and reliability of this critical business function. This change is specific to version 17.0.
Original PR description
Before this commit, the Peppol retrieve (BIS3) had the possibility of being changed because predictions were not disabled correctly due to the context not being passed properly. To avoid this issue, we now pass the context correctly and added tests to prevent future errors. This commit is specific to version 17.0, as this version requires different changes compared to upper versions. Ticket [link](https://www.odoo.com/odoo/project.task/5441710) opw-5441710