Daily updates from Odoo
Monday, January 19, 2026
176 changes
12 changes
Resolved issues and error corrections
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from subscription end dates being set to December 31, 2026, causing a system error. This fix ensures the subscription logic functions correctly regardless of the year.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658 Forward-Port-Of: odoo/enterprise#104604
This update ensures that documents are correctly moved to the appropriate folder and receive the correct tags when linked to a journal entry (like a vendor bill). Previously, the system didn't update document locations, but this fix resolves that issue, streamlining document management within Odoo.
Original PR description
Steps to reproduce: 1. Open the Documents app and select an uploaded file. 2. Click the action "Create Vendor Bill" (or any journal entry action). 3. The Invoice is created and the document is…
Steps to reproduce: 1. Open the Documents app and select an uploaded file. 2. Click the action "Create Vendor Bill" (or any journal entry action). 3. The Invoice is created and the document is attached to it. **Current Behavior:** The document remains in its original folder (e.g., Finance) and does not receive the tags defined on the journal settings. **Expected Behavior:** The Document should be moved to the specific folder linked to the Journal (e.g., "Vendor Bills") and receive the configured tags. **Cause:** The `write` method attempts to identify documents to sync by calling `_get_document_attachments_to_sync`, which inspects the current record (`self`). However, when an invoice is being linked to a document for the first time, the attachment ID exists only in `vals` and has not yet been applied to `self` via `super().write()`. Consequently, the code assumes there are no documents to sync and skips the folder/tag update. This issue was introduced in 2333367. **Fix:** Detect the specific case where `attachments_to_sync` is empty (no current link) but `vals` contains a `message_main_attachment_id`. In this scenario, force the synchronization flag to `True` so the document is updated after the changes are saved. Note: The loop logic was also refactored to flatten the structure and accommodate the new check more cleanly. Task-5452880
This update resolves a test failure within the im_livechat module. The issue stemmed from a mismatch between the demo data's time zone setting and the test's expectations. By explicitly setting the time zone for the OdooBot partner record, the test now passes correctly.
Original PR description
This PR fixes a failing assertion in `test_channel_get_livechat_visitor_info`. The test fails since [*] because the demo data sets the OdooBot time zone to 'Europe/Brussels', while the test was asserting it to be False. This PR explicitly sets the time zone of the OdooBot partner record and updates assertions accordingly. [*] https://github.com/odoo/odoo/pull/210094 runbot-237778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the Point of Sale system that prevented users from creating orders with custom prefixes. The change ensures order names are correctly generated, avoiding errors related to data type conversions. This ensures consistent order naming functionality across Odoo 19.1.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving data accuracy. This change impacts the generation of invoice reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to fail intermittently due to a race condition caused by a lingering success notification. This commit resolves the issue by automatically closing the notification message after an inventory adjustment, ensuring accurate test results. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
This update resolves an issue where demo data installation caused incorrect packaging behavior during a specific test. The fix ensures that new packages are created with unique names, preventing the system from incorrectly adding items to the demo data package instead of the intended new package. This improves the reliability of the demo data.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update removes a recent change that was causing performance issues and instability within the spreadsheet dashboard feature. The previous attempt to use ETags for efficiency wasn't delivering the expected benefits and was creating more problems than it solved. This reversion ensures the dashboard continues to function reliably.
Original PR description
This reverts commit 3b014027cb785a2c567ec94fd14ae24f39f92783. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation in spreadsheet dashboards. Task: 5504270 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes a recent update that was causing issues with spreadsheet performance. The effort to implement etag computation in spreadsheets didn't outweigh the problems encountered, so we've reverted the changes to restore previous functionality. This ensures spreadsheets continue to operate efficiently.
Original PR description
This reverts commit 60fc64d0fd2458f60b5d922fe12c0d09dc2bcde0, 67ba628326b4eb0336095b912f40d0f320a848aa and 8f3e242e197b2f269827499b0d89b2e9080f5d09. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation for spreadsheets. Task: 5504270
This update resolves a recurring issue in the Odoo message copy test that occasionally failed. The fix modernizes the test to more reliably capture the copy functionality by focusing on the composer's state rather than relying on potentially unreliable keyboard shortcuts. This ensures the test consistently passes, improving overall system stability.
Original PR description
Before this commit, the "Copy Message Link" test was sometimes failing. It happens for two reasons: - It presses "ctrl+v" with the intent of copying the message link in the composer but doesn't check if the composer is focused (it should not be as the test clicks away to copy the link). - It then presses "enter" with the intent of posting the message, without checking if the composer is filled or even ready to send. This test replaces the "press" steps: - "ctrl+v" is replaced by `insertText`: we already check that the copy works and "press" is less reliable. - We click on the send button when enabled. runbot-237538 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue that prevented test cases from running correctly. The `pickup_time` and `return_time` fields were initially defined in one module, but later moved to another. This change required updating related code to ensure proper functionality and test case setup.
Original PR description
During the development of odoo/enterprise#102625, the fields `pickup_time` and `return_time` were first defined in `sale_renting`, as they were prior to the PR, but during development it was decided to move the fields into `website_sale_renting`, where they are actually used. Unfortunately, some remaining code in `sale_renting` was not updated accordingly, which caused the setup of test cases to fail when `website_sale_renting` was not installed along with `sale_renting`. runbot-237987
This update resolves a technical issue that caused translation tests to fail due to delays in loading sidebar content. By preloading translated elements, the system now ensures the sidebar is fully ready before tests begin, improving test reliability and speed. This enhances the overall translation process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
4 changes
Resolved issues and error corrections
This update corrects a technical issue where the website's payment providers were incorrectly linked to multiple companies, causing errors during testing. The fix ensures that each payment provider is associated with the correct website company, resolving the test failure and improving data consistency.
Original PR description
What is fixed ------------- The test_payment_provider_visibility_with_portal didn't pass due to a multi company issue. In demo data, "Demo" payment provider exists for different companies which led the search method to return every one of them. Trying to assign the shop website id to each of them then raises an error as their company_id are inconsistent. The fix ------------- We now ensure only one provider is selected and its company is the same as the website's company. Runbot error : 237822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invalid warehouse locations triggered repeated geolocation requests to OpenStreetMap. Now, when geolocation fails for an invalid address, a default coordinate is set, preventing further unnecessary requests and improving system performance. This ensures smoother location selection for users.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#244439
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the window to remain open and block the newly opened page. The change automatically folds the chat window after a link click, ensuring users can immediately view the linked content. This enhances usability and prevents frustration for mobile users.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244383 Forward-Port-Of: odoo/odoo#208440
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices referenced the same payment method. The fix ensures that the system correctly handles these scenarios, preventing errors and improving data accuracy for Mexican electronic invoicing reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#1034606 changes
Enhancements to existing features
This change updates the source of lead mining data within the IAP system. We've switched from the Clearbit provider to Dun & Bradstreet, a provider already used for partner autocomplete. This ensures more consistent and reliable lead information is available to our users.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#235521
Resolved issues and error corrections
This update resolves an issue where tables inserted into the To-Do module appeared after the existing text instead of before it. The fix streamlines the table insertion process by moving the logic to a more robust component, ensuring tables are now correctly positioned at the beginning of the block where the user intended.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244299 Forward-Port-Of: odoo/odoo#243242
This update fixes an issue where sign templates created in languages other than English didn't correctly reflect the document name. The fix ensures that template names are always updated to match the document name, regardless of the user's language setting, improving the user experience for international users.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747
This update corrects a technical issue preventing users from importing XML invoices through the accounting module. The problem stemmed from a required 'CustomizationID' tag being missing from the XML files, which is now enforced. This ensures proper invoice processing and avoids import failures.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398 Forward-Port-Of: odoo/odoo#236668
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving invoice generation reliability. This change impacts the Mexican e-invoicing reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460This update fixes a minor visual issue in the contact view of delivery addresses. The GLN field was awkwardly positioned and lacked a label, making it difficult to find. The change repositions the label before the notes field for better clarity and usability.
Original PR description
The field is placed weirdly in the view when opening the contact view of the delivery address. There is no label, making it almost impossible to discover, and it is in the middle of everything. Let's put it down before the notes field. Before: <img width="971" height="510" alt="image" src="https://github.com/user-attachments/assets/2e0e7d96-1a7f-4fe5-b17d-4c5b25a3e7bf" /> After: <img width="824" height="554" alt="image" src="https://github.com/user-attachments/assets/3bc47f20-72a9-4247-8dd3-9e939046c6d7" /> task-none
2 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers – including those prefixed with 'UA' – are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469 Forward-Port-Of: odoo/odoo#243258
Resolved issues and error corrections
This update corrects a bug that prevented users from importing XML invoices through the accounting module when the CustomizationID tag was missing. The CustomizationID tag is a required element in UBL files, and this fix ensures that invoices with this tag are now correctly processed.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398 Forward-Port-Of: odoo/odoo#236668
38 changes
New functionality added to Odoo
This update introduces two new icons – 'phone-in-talk' and 'phone-times' – to the Odoo UI icon set. These icons will be used within the VoIP module to visually represent a user's call status, improving clarity and usability.
Original PR description
This commit adds two new icons to the Odoo UI icon set: 'phone-in-talk' and 'phone-times'. These icons are intended for use in the VoIP module to represent the user's call status. task-5479064 Requires: - https://github.com/odoo/enterprise/pull/104624 | `phone-in-talk` | `phone-times` | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update enhances the Sign app by adding keyboard shortcuts for key actions like 'Send' and 'Sign now'. This improves user efficiency and accessibility within the Sign workflow. The changes focus on streamlining the user experience for this important application.
Original PR description
Currently, some buttons in the Sign app, such as "Send" and "Sign now", do not have shortcuts available. This commit adds shortcuts for these buttons and other important actions. task-5442673
This update aligns the payment field widget in the Enterprise version of Odoo with the Community Edition. This ensures consistency and simplifies the process of entering payment information for invoices, improving user experience and data accuracy.
Original PR description
Added extra fields to align with the widget in CE task-5258726 Forward-Port-Of: odoo/enterprise#104300
This update streamlines the display of buttons within the bank reconciliation widget. Previously, buttons were shown on separate lines, now they consistently appear alongside the last displayed button for a cleaner and more intuitive user experience. This improves usability and reduces visual clutter.
Original PR description
This commit aims to: Avoid having the dropdown toggle on a separate line, it should always stick to the last displayed button. task-5382731 Forward-Port-Of: odoo/enterprise#103799 Forward-Port-Of: odoo/enterprise#101692
Resolved issues and error corrections
This update resolves a technical issue that prevented demo data from installing correctly. The problem stemmed from a missing timezone setting for employees, introduced during a recent update to the working schedule. This fix ensures demo data installs without errors.
Original PR description
This PR fixes a bug in a test when demo data is installed. A timezone setting was missing on the employee. The refatoring PR of the working schedule (https://github.com/odoo/enterprise/pull/96139) introduced the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238014 task-5704131
This update clarifies the 'Do Not Disturb' (DND) icon in the softphone interface. Previously, the DND icon was visually similar to other status indicators, leading to potential user confusion. This change ensures a clearer visual distinction for the DND status, improving usability.
Original PR description
This commit updates the DND icons in the softphone to avoid confusion with other status icons represented by a colored dot. task-5479064 Requires: - https://github.com/odoo/odoo/pull/244291 | Before | After | |--------|--------| | <img width="168" height="91" alt="Capture d’écran 2026-01-16 à 16 15 32" src="https://github.com/user-attachments/assets/ad7447d2-8d8d-4963-abf8-6b4ac27270c0" /> | <img width="155" height="86" alt="Capture d’écran 2026-01-16 à 16 16 17" src="https://github.com/user-attachments/assets/485ec299-1f39-4bc4-84c8-199c0bbdf6cc" /> | | <img width="399" height="159" alt="Capture d’écran 2026-01-16 à 16 16 58" src="https://github.com/user-attachments/assets/c590e7bf-c3ee-45c7-a6bf-69080c2a158c" /> | <img width="397" height="156" alt="Capture d’écran 2026-01-16 à 16 17 32" src="https://github.com/user-attachments/assets/32b3ec65-4ca4-492a-a9c4-642b16be5340" /> |
This update ensures that optional field toggles within the Odoo list view are always visible above column resize handles. Previously, these toggles could be obscured, making it harder for users to quickly select or deselect optional fields. This change improves the user experience and clarity of the list view.
Original PR description
This commit increases the z-index of the toggle of the optional field dropdown s.t. it is always above the column resize handle. Task~5504022 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing the bank reconciliation view from functioning correctly offline. The change disables caching for this specific view, ensuring it can access data even without an internet connection. This improves the reliability of this key financial reporting tool.
This update resolves an issue where excessive logging was appearing in Odoo's unit tests. By hiding these logs, the tests now run more efficiently and reliably. This improves the overall stability and performance of the Odoo platform.
Original PR description
This commit hides unwanted logs in unit tests check_undeterminisms Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances how users manage their consent for online account synchronization. The change allows for a more flexible approach to handling consent requests, addressing a previous technical issue. This improves the user experience and ensures compliance with data privacy regulations.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update addresses several small issues within the l10n_hr_edi module, primarily focused on improving error handling and the user interface. Specifically, it enhances the process of fiscal document status checks, supports multi-company operations, and streamlines bill approval workflows. These changes ensure greater stability and usability for users.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
This update corrects a data issue within the Odoo Enterprise system related to Chilean SII (Service de Impuestos Internos) reporting. Specifically, the information for the 'Alto Hospicio' Regional Office and its associated Comuna (Alto Hospicio) within the Taracapá region has been added, ensuring accurate tax reporting compliance.
Original PR description
Oficina Regional Alto Hospicio Comuna Alto Hospicio Región Taracapá Forward-Port-Of: odoo/enterprise#102712
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503 Forward-Port-Of: odoo/enterprise#103218
This update fixes an issue where numbers extracted from OCR boxes were incorrectly parsed due to language-specific decimal separator settings. The change simplifies the parsing process by consistently using a standard JavaScript `Number` parser, ensuring accurate numerical data entry within the system. This improves data integrity and reliability.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979) Forward-Port-Of: odoo/enterprise#104467
This update fixes an issue where cash order creation in Point of Sale was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244287
This update fixes an issue where order processing within batch picking was inconsistent. The change ensures that order lines are correctly associated with picking IDs by using the ID field instead of the field itself, resolving a technical problem related to how Odoo compares related data. This improves the reliability of batch picking operations.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512 Forward-Port-Of: odoo/enterprise#104561
This update fixes a problem with the Point of Sale testing process. Previously, the tour wouldn't always complete successfully. By adding a final check to ensure at least one paid order exists, the tour now reliably finishes, guaranteeing consistent and accurate test results. This improves the quality of our Point of Sale testing.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243815
This update resolves an issue where group channels (DMs with fewer than 3 members) were causing confusing display behaviors like incorrect status indicators and missing author names. By removing a specific calculation, the system now accurately reflects the nature of group channels, providing a more reliable user experience.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243874 Forward-Port-Of: odoo/odoo#242058
This update fixes a technical issue that caused tracebacks when a member was typing in group chats with multiple users. The fix ensures that the 'ImStatus' component isn't incorrectly displayed in group chats, preventing errors and improving stability. This resolves a potential disruption for users engaging in group conversations.
Original PR description
Before this commit, when another member of a group chat with more than 2 members was typing it would result in a traceback. Steps to reproduce: 1. Have `hr_homeworking` and/or `hr_holidays` installed 2. Create group chat with 2 other users 3. Open said group chat 4. Have another member start typing -> traceback This happens because since [1] the condition to show the `ImStatus` component became `showImStatus`, which is true in group chats when another member is typing. However since group chats with more than 2 members have no correspondent, this leads to the `ImStatus` component having no `persona` attribute, which in turn causes a crashes in templates without a guard on `persona` access. This commit fixes the issue by making `showImStatus` only true in DMs, since it's not expected for group chats to have a correspondent and hence an IM status should not be shown. [1]: https://github.com/odoo/odoo/pull/234715 Forward-Port-Of: odoo/odoo#243798
This update adjusts the size of the 'looking for help' timers in live chat conversations on the discuss sidebar. The change makes the overall text content of these conversations more visually balanced, improving readability and the user experience. This is a minor cosmetic fix.
Original PR description
Timers on "looking for help" live chat conversations on discuss sidebar were slightly too big. This commit reduces the size to make the overal text content of a discuss item more balanced. Before / After <img width="296" height="100" alt="Screenshot 2026-01-16 at 16 58 50" src="https://github.com/user-attachments/assets/32d8e304-c00f-4d2f-bcb9-3b58be7f01c4" /> <img width="298" height="99" alt="Screenshot 2026-01-16 at 16 58 57" src="https://github.com/user-attachments/assets/2cc6fff7-8613-4b56-b44c-22ad72738286" /> Forward-Port-Of: odoo/odoo#244306
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no follow-up' enabled. This simplifies reporting and prevents unnecessary notifications for these common transaction types, streamlining our accounting processes. It’s a small change that improves efficiency and reduces potential noise in our reporting.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244309
This fix addresses an issue where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only created when a valid quantity of the service is ordered, streamlining the quoting process and preventing unnecessary project creation. This resolves a potential confusion and improves data accuracy.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118 Forward-Port-Of: odoo/odoo#240608
This update resolves a technical issue causing duplicate entries in the Accounts Coverage Report, specifically when using the Ireland reports. The fix ensures accurate reporting by ignoring identical report lines with the same name and code, preventing misleading results.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732 Forward-Port-Of: odoo/enterprise#101311
A technical issue prevented the correct installation of the l10n_be_hr_payroll module. This update resolved a conflict related to a field definition, ensuring the module functions properly when installed independently. This change improves the stability and usability of the Belgian payroll functionality.
Original PR description
A traceback about bike_id occurs when only installing l10n_be_hr_payroll. The field bike_id is in the fleet bridge of the belgian payroll. The field is already present in the _get_whitelist_fields_from_template method in that module. Removing the field from the l10n_be_hr_payroll method solves the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/234856 task-5504273 Forward-Port-Of: odoo/enterprise#104612
A technical issue in the tour test was causing it to incorrectly select contacts. This update resolves the problem by ensuring the tour always uses the correct contact associated with the call being demonstrated, specifically selecting from the Recent tab instead of the Contact tab when demo data is used.
Original PR description
`call_activity_chatter_link` tour fails when test contains demo data. When contains demo data, the test select a wrong contact in Contact tab. In this commit, we change to select the first call in Recent tab to ensure this is the contact of the call we just made. Forward-Port-Of: odoo/enterprise#104687
This update resolves a problem where customers couldn't change product selections within the Point of Sale configurator. The issue stemmed from overly restrictive attribute exclusions, preventing valid combinations. The fix removes the problematic code to allow customers to freely select product options.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are…
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244347 Forward-Port-Of: odoo/odoo#241259
This update resolves a recurring issue where the quotation signing tour occasionally failed to complete correctly. The fix adds a deliberate pause within the tour to ensure all interactions have finished loading, resulting in a more stable and reliable experience for users. This enhances the overall usability of the sale management process.
Original PR description
This commit fixes the flaky quotation signing tour in sale_management by adding an explicit step to wait for interactions to fully load before proceeding with the next steps. runbot error-224021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242848 Forward-Port-Of: odoo/odoo#242746
This update resolves a technical issue where the HTML editor would crash when attempting to remove formatting from a cell with a lingering color. Now, users can reliably remove colors from empty cells without encountering errors, improving the overall stability and usability of the editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243976 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where right-clicking on links within messages was obscured by extra message actions. Now, users will see the standard browser context menu options like 'Open Link' and 'Copy Link' when right-clicking on a message link, improving usability.
Original PR description
Before this commit, when right-clicking on a link in a message body, this was showing the list of message actions in dropdown. This is a problem because right-click on link has features like "Open link" / "Copy link" and so on. They were over-shadowed by the right-click on message for showing of message actions. This commit prevent the showing of message actions in dropdown from right-click in links in message body, so that the browser context menu is open instead in that scenario, showing features like "Open link" and "Copy link". Forward-Port-Of: odoo/odoo#244252
This update resolves a technical error in the Point of Sale system that prevented users from creating order names with custom prefixes. The fix ensures order names, including prefixes, can be generated correctly, preventing tracebacks and ensuring proper order functionality. This improves the reliability of the POS experience.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from a subscription end date set for December 31, 2026, causing a system error when processing invoices in 2027. This ensures the subscription functionality operates correctly across different years.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658 Forward-Port-Of: odoo/enterprise#104604
This update fixes an issue where the Netherlands localization incorrectly created duplicate fiscal positions. The change removes the duplicate and properly defines the NL Domestic fiscal position, ensuring accurate VAT handling and compliance with Dutch regulations. This ensures the accounting system functions correctly for Dutch businesses.
Original PR description
Installing the Netherlands localisation creates two Domestic fiscal positions, both incorrectly configured. This commit removes the empty duplicate fiscal position and properly defines the NL Domestic fiscal position by setting the Country Group, leaving Country empty, and disabling VAT requirement. task-5489829 Forward-Port-Of: odoo/odoo#244183
This update resolves a problem where Odoo incorrectly displayed a "Resume" prompt after successfully importing large CSV files in batches. The fix ensures the 'Resume' prompt disappears automatically when the import process is truly complete, improving the user experience. This prevents unnecessary prompts and streamlines the import process.
Original PR description
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce:…
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce: 1. Create a CSV file with enough records to trigger at least 2 batches 2. Go to any list view and select "Import records". 3. Upload the file and click "Import". 4. Wait for the import to complete. 5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears. The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes. * In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated. * If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch. * `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value. This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`). opw-5343837 Forward-Port-Of: odoo/odoo#241490
This update resolves an issue where demo data in the stock barcode module incorrectly packed items into existing demo packages instead of new ones. The fix ensures a unique package name is created during demo data installation, preventing this conflict and maintaining accurate inventory tracking.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update corrects a technical issue that was preventing the generation of accurate invoice reports for Mexican EDI (l10n_mx_edi) transactions. The fix prevents an error that occurred when multiple invoices with the same payment method code were processed, ensuring consistent report output.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to occasionally fail due to a timing issue with notification messages during inventory adjustments. This commit resolves the problem by automatically closing the success notification after the first adjustment, ensuring the subsequent adjustment runs correctly. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
Features or functions removed from Odoo
This pull request removes a previously identified, unused piece of code within the Odoo Enterprise VoIP module. The code was introduced but never utilized, streamlining the system and reducing potential maintenance overhead. This change improves the overall efficiency of the application.
Original PR description
The `onCountrySelectorStateChanged` method was introduced at [1] but it was already dead code at the time. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 Related to task-5366961
This update removes unnecessary code related to barcode functionality. Previously, a check for a dataset was included as a leftover from a recent update. This cleanup improves the efficiency of the barcode system without impacting its core functionality. It's a minor technical adjustment.
Original PR description
This code was introduced in [1] with the new views but part of the code was legacy and was removed in [2]. We can safely remove this leftover line. [1]: https://github.com/odoo/odoo/commit/920df597d3d7174723736a395e94dc8ff413c70b [2]: https://github.com/odoo/odoo/commit/49297bc7bba75541ca139e6c84e0d3b311765145 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
8 changes
Enhancements to existing features
This update aligns the invoice payment field with the standard version used in the Community Edition of Odoo. This ensures consistency and simplifies the process for users entering payment information, leading to fewer errors and a smoother user experience.
Original PR description
Added extra fields to align with the widget in CE task-5258726
Resolved issues and error corrections
This update resolves a technical issue where Stripe was not properly reporting the reason for failed expense authorization requests. Specifically, when Stripe reached its spending limit, a 'authorization_controls' reason wasn't displayed. This change adds a user-friendly translation of this reason, improving the clarity of error messages and enabling better tracking of expense authorization problems.
Original PR description
When Stripe refuses an authorization due to the maximum allowed being reached, there is a specific technical reason "authorization_controls" that wasn't mentioned in their documentation. This adds the reason with a user-friendly translation See [doc](https://docs.stripe.com/api/issuing/authorizations/object?api-version=2025-01-27.acacia#issuing_authorization_object-request_history-reason)
This update corrects a visual glitch where dynamic website snippets would briefly appear and disappear. The issue stemmed from a change in how snippets were styled, and this commit restores the original design: snippets now start with no visibility class, relying on content to determine display.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523 Forward-Port-Of: odoo/odoo#240475 Forward-Port-Of: odoo/odoo#238305
This update corrects a bug where free product rewards in the loyalty program were incorrectly displaying a non-zero price in the shopping cart. The issue stemmed from an override in the `sale_subscription` module that was causing unnecessary discount calculations. This fix ensures accurate pricing for free loyalty rewards.
Original PR description
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on…
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on configuration. 3- Create a `promotion`: - rule: minimum quantity: 0, minimum purchase: 10 - reward: free product, quantity: 1 4- Set a non-zero price on reward product from product page. 5- Create a product with price of 6 and publish it on the website. 6- On website, add 1 unit of created product to cart. 7- Open cart, and increase the quantity. 8- As you see the free product is added to cart but the price is non-zero. ### Cause: Based on #89397, the reward line have the discount of 100. In the `_compute_discount` this discount is set to 0: https://github.com/odoo/odoo/blob/e48a7f1b03f23a4c96e35ee4350029439ec73e47/addons/sale/models/sale_order_line.py#L797 As `compute_discount` only depends on `product_id`, `product_uom_id`, `product_uom_qty` this shouldn't cause issue. However, in `sale_subscription` its override includes `sale_order.plan_id` as dependency: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/sale_subscription/models/sale_order_line.py#L86-L90 Which setting `plan_id` to `False` here makes discount to be recomputed: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/website_sale_subscription/models/sale_order.py#L27-L30 ### Fix: This can be avoided by filtering reward lines in a `_compute_discount` override. As none of reward lines regardless of reward type are expected to have a discount calculated this fix will not break any other flows. It's noteworthy to mention that in the test, `_compute_discount` is directly called in order to mimic the flow without the need to install `sale_subscription`, as the `sale_subscription` is not root cause of the issue and the same issue could reproduced by any other modules overriding `_compute_discount`. opw-5485796
This update resolves a minor issue within the email invite tour process. Previously, the tour's speed caused conflicts with the automatic opening of the channel member list. This fix ensures the tour waits for the member list to open, preventing a rare but disruptive behavior. This improves the overall user experience for inviting new members to channels.
Original PR description
The `test_01_invite_by_email_flow` test ensures we can invite partners to a channel using their email. The tour opens the invitation panel, then sends an email. However, it conflicts with the auto-open of the member list. Sometimes, the member list opens after clicking on the invite panel button. This only occurs because the tour runs very fast. It's very unlikely that this occurs to a real user. This commit fixes the tour in order to wait for the member list to open initially. runbot-237994 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a performance issue in the translation sidebar. By preloading translated elements, the sidebar now renders fully before tests begin, preventing delays and ensuring tests pass consistently. This improves the reliability of our translation testing process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
This update prevents unnecessary WebRTC testing when the IoT Box record is a stable version, which doesn't support this feature. This avoids a potential performance issue and ensures the 'Test' button functions correctly for the intended use case. It's a minor fix improving the user experience.
Original PR description
We now avoid testing WebRTC when pressing "Test" button on the IoT Box record, when the IoT Box is a stable IoT Box (which does not support it). Task: 5490291
This update resolves a technical issue that was preventing embedded actions from functioning correctly in our web interface. The fix involved adjusting a test to accurately simulate user interaction and ensure the action is correctly triggered. This improves the reliability of embedded actions for users.
Original PR description
In this commit, we fix an embedded action test that failed because when clicking on the sliders to show the top bar, the dropdown was directly opened as there is only one visible action (since this commit: https://github.com/odoo/odoo/pull/208005/commits/a5709e870e033b83d50a2f581c81cceb2a98d91b). We then adapt the test to wait for the dropdown to open automatically, and then when it's the case, create the new custom embedded action. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when generating invoices with similar payment information. The fix ensures that the system correctly handles multiple invoices sharing the same payment details, preventing errors and improving invoice generation reliability. This ensures consistent invoice creation for users.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#1034605 changes
Resolved issues and error corrections
This update fixes a technical issue that caused errors during server shutdowns. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures a smoother and more reliable shutdown process, preventing these errors from occurring.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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
A test was failing in the website sale module due to a sale order not requiring payment. This update forces the sale order to always require a payment, resolving the test failure and ensuring consistent functionality. This ensures the website sale process functions correctly.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a discrepancy in how holiday allocations are calculated when employees have different working schedules. Previously, the system produced inconsistent hour counts for related allocations. The fix ensures that all child allocations accurately reflect the total hours defined in the parent allocation, improving allocation accuracy and reporting.
Original PR description
### Steps to reproduce: - Create two employees with two different working schedule - Create a multi employee allocation for the created employees with 40 hours - Validate the allocation you created - Notice the number of hours is differenc between the two allocations ### Cause: When validating the multi employee allocation and while creating the children allocations we compute the number_of_hours_display and since we calculate it with number of days * hours per day it will result into two different values for the number of hours as the hours per day is different for each working schedule. ### Fix: To fix this we check if the allocation is an hourly one we change the number of days depending on the number of hours that we already got from the parent allocation. So when computing the number of hours for the children allocations we get the same value opw-5232797
This update resolves an issue where the UBL export incorrectly interpreted VAT information represented with a forward slash ('/'). The change ensures that VAT is properly handled when a partner doesn't have VAT, and the CompanyID field is correctly required in those cases, aligning with PEPPOL standards. This improves the accuracy of electronic invoices.
Original PR description
To signify that you know a partner does not have vat, we advise using '/'. But we should take care of that in the UBL export, to not consider it a real vat Also, in the cases where we don't have the vat, the CompanyID is supposed to be mandatory. https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-TaxRepresentativeParty/cac-PartyTaxScheme/ So, remove the whole PartyTaxScheme if vat is not present. Zatca does not override that rule (except enforcing that seller must have vat, which raises a constraint), so we modify the tests for the simplified documents. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that prevented users from correctly selecting a company after it had been unarchived. The problem stemmed from a timing conflict in the system's data processing, which caused incorrect company access permissions. This change ensures a smoother and more reliable unarchiving process.
Original PR description
**Steps to reproduce** - Have at least two active companies - Archive one company - Unarchive the company - Select the just unarchived company in the company selector - `Access Error: Access to unauthorized or invalid companies.` **Cause** There was a timing issue between the cache invalidation and the call to super. After the cache invalidation, if `_get_company_ids` of `res.users` was called before the call to `super` in the `write`, it would not return the just unarchived company. opw-5449925