Daily updates from Odoo
Monday, February 3, 2025
94 changes
14 changes
Miscellaneous changes
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c
Original PR description
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id.…
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd - On TODO picking, do the following steps WITHOUT CLICKING ON SAVE - Operations -> Add a line: (demand 0, quantity 0) - Click on 'Open Move' button (fa-list icon) - Popup 'Open: Stock move': Add a line - Popup 'Add line: <product>': click on 'New' - Popup 'Create Move Line': click on 'Save & Close' - Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close' - Validate picking -> Create backorder => Check picking move_line_ids = EMPTY ## Solution Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list). OPW-3974109 Forward-Port-Of: odoo/odoo#171766
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On…
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477 ### Fix: Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`. opw-4428050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194068
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test
Original PR description
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test by default drops at the middle and top of the drop zones. To avoid this kind of situation, in this commit, we add a step at the beginning of the test to hide the header. [1]: https://github.com/odoo/odoo/commit/e0c16bb9a90dfb378b75e0de059e71f0aebd84fb opw-4494945 Forward-Port-Of: odoo/odoo#195768 Forward-Port-Of: odoo/odoo#195554
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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#179592
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be
Original PR description
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓…
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be translated anymore. We also do the same for other xpath-ed classes that don’t have `t-translation="off"`, to prevent the same issue elsewhere. Since the class is already translated in the existing databases, in stable versions, we add the class a second time to the list of droppable element selectors. This second class won't be translated, which will fix the issue for Dutch users. [opw-4461785](https://www.odoo.com/web#id=4461785&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) ----------- Note: This PR also fix 2 minor bugs: - The text on the button to install a block overflows when translated into certain languages that make it longer. <kbd></kbd> - The `Embed code` block "Click on Edit..." message is not visible on dark background. <kbd></kbd> Forward-Port-Of: odoo/odoo#195854 Forward-Port-Of: odoo/odoo#193819
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other
Original PR description
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any others field types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195432
Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#195818 Forward-Port-Of: odoo/odoo#194014
Original PR description
Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#195818 Forward-Port-Of: odoo/odoo#194014
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
Original PR description
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. 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#196036 Forward-Port-Of: odoo/odoo#195909
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represe
Original PR description
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represented correctly in Python (including 7, 3.3 etc.). opw-4485316 Forward-Port-Of: odoo/odoo#195328
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Original PR description
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#195073 Forward-Port-Of: odoo/odoo#193971
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Original PR description
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
Original PR description
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
11 changes
Enhancements to existing features
This update cleans up the mail features after recent changes and fixes a small typo affecting mobile mail notification handling. It also adds groundwork to let some email notifications be delayed or handled in batches, which can improve reliability and efficiency for larger mail operations.
The helpdesk portal grouping option now uses the label "Sales Order Item" instead of "Sales Order". This makes the interface more accurate and avoids confusion, since the grouping already worked at the sales order item level and no behavior has changed.
Original PR description
Renamed the group by field from 'Sales Order' to 'Sales Order Item'. The behavior was not changed as it was already grouping by Sales Order Item. task-4260389
This update streamlines the website signup form in Studio by removing actions that are not needed in that context. This should make the form editing experience clearer and reduce the chance of users selecting unsuitable options.
Original PR description
WIP
India payroll salary rules were simplified by removing duplicate entries for salary assignment and attachment. This reduces confusion in payroll configuration while keeping the net salary calculation unchanged.
Original PR description
Currently, the 'Assignment of Salary' and 'Attachment of Salary' rules are duplicated in the salary rules, and the NET formula is the same. I have removed these duplicate rules from the India payroll. task-4383807
Miscellaneous changes
This error occurs when clicking ``Send to eTIMS``, as the system cannot retrieve tax details for the invoice lines. The issue is caused by the newly created tax lacking proper details, leaving the tax information empty. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module - Switch to ``KE Company`` - Invoicing > Configuration > Accounting > Taxes - Create a NEW Tax -> (Tax Computation= Group of Taxes, Tax Type = Purchase, KRA Tax Code = Select any one) - Create a NEW Vendors Bi
Original PR description
This error occurs when clicking ``Send to eTIMS``, as the system cannot retrieve tax details for the invoice lines. The issue is caused by the newly created tax lacking proper details, leaving the…
This error occurs when clicking ``Send to eTIMS``, as the system cannot retrieve tax details for the invoice lines. The issue is caused by the newly created tax lacking proper details, leaving the tax information empty.
Steps to reproduce:
---
- Install ``l10n_ke_edi_oscu`` module
- Switch to ``KE Company``
- Invoicing > Configuration > Accounting > Taxes
- Create a NEW Tax -> (Tax Computation= Group of Taxes, Tax Type = Purchase, KRA Tax Code = Select any one)
- Create a NEW Vendors Bill > Add a Product and set a new tax for it
- Click ``Send to eTIMS``
Traceback:
---
```
StopIteration: null
File "odoo/http.py", line 2406, in __call__
response = request._serve_db()
File "odoo/http.py", line 1934, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1997, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1964, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2214, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 334, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 733, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 36, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/service/model.py", line 62, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 497, in action_l10n_ke_oscu_confirm_vendor_bill
content = move._l10n_ke_oscu_json_from_move()
File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 192, in _l10n_ke_oscu_json_from_move
line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 243, in _l10n_ke_oscu_get_json_from_lines
tax, line_tax_details = next(
```
At [1], we are encountering ``tax_details['tax_details_per_record'][line] ['tax_details'] = {}`` because there are no tax details available for the newly created tax.
This commit now ensures that both tax lines and tax repartition lines are present in the tax.
[1] - https://github.com/odoo/enterprise/blob/d7d816efdff81c9c6eab1f11b04445f08c73e519/l10n_ke_edi_oscu/models/account_move.py#L243-L247
sentry-6236536577
Forward-Port-Of: odoo/enterprise#77624runbot-error-108304 Forward-Port-Of: odoo/enterprise#78094
Original PR description
runbot-error-108304 Forward-Port-Of: odoo/enterprise#78094
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
Original PR description
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Original PR description
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2
Original PR description
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted…
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.
To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
* Recurring plan: Monthly
* Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.
---
Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
self.assertTrue(bool(second_picking))
AssertionError: False is not true
```
OPW-4280155
Forward-Port-Of: odoo/enterprise#73825
Forward-Port-Of: odoo/enterprise#73484This commit fix 2 tests who nightly fails on runbot: Test 1, `test_01_orders_no_invoiced` (https://runbot.odoo.com/odoo/runbot.build.error/111519): This test failed because of a `flush_all()`, who raised an error because of an `api.depends_context` on a computed field in `product_template` Solution: remove the `api.depends_context` as he's useless (the compute still trigger as it should) Test 2, `test_read_purchase_order` (https://runbot.odoo.com/odoo/runbot.build.error/111518): This te
Original PR description
This commit fix 2 tests who nightly fails on runbot: Test 1, `test_01_orders_no_invoiced` (https://runbot.odoo.com/odoo/runbot.build.error/111519): This test failed because of a `flush_all()`, who raised an error because of an `api.depends_context` on a computed field in `product_template` Solution: remove the `api.depends_context` as he's useless (the compute still trigger as it should) Test 2, `test_read_purchase_order` (https://runbot.odoo.com/odoo/runbot.build.error/111518): This test failed because of access right error Solution: add a compute_sudo on `l10n_ke_validation_message` field and add a `groups="point_of_sale.group_pos_user"` on account_move view. no-task Forward-Port-Of: odoo/enterprise#77636
The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id Forward-Port-Of: odoo/enterprise#78260
Original PR description
The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id Forward-Port-Of: odoo/enterprise#78260
69 changes
Enhancements to existing features
The Mexican payroll module now includes the official UMA value for 2025. This keeps payroll-related calculations aligned with the latest required reference amount, helping businesses remain accurate and compliant.
Original PR description
New UMA value for 2025. Task: 4465318
Resolved issues and error corrections
The editor no longer errors when users remove formatting from styled links. This makes content editing smoother and prevents interruptions when cleaning up text formatting.
Original PR description
**Current behavior before PR:** - Clicking the Remove Format button to remove the style from an anchor tag caused a traceback error. **Desired behavior after PR is merged:** - Clicking the Remove Format button now successfully removes any applied styles from the selected text. task: 4427649
The rating display was showing an unwanted border around rating images because of an incorrect styling class. This fix removes that class so rating images appear as intended, improving the visual polish of customer-facing rating views.
Original PR description
Related Ticket: https://www.odoo.com/odoo/my-tasks/4482430 Signing up the CLA [FIX] rating: Extra border line on the rating image The 'btn' class was incorrectly applied to the rating label in `rating_templates.xml`, which affected the styling, making extra border line displaying on the rating image. Removing this class restores the expected appearance. 
This fixes an issue where copying a link from tools like Visual Studio Code and pasting it into Odoo's editor did not create a proper link. The editor now recognizes single valid links even when they are pasted as HTML content, making link insertion more reliable for users.
Original PR description
**Problem**: When a link is copied with HTML content, `handlePasteText` is called after `handlePasteHtml`, and the content type is `text/html`. **Solution**: Extract the pasted content as text inside `handlePasteHtml` and check if it is a single valid link. If so, skip further processing. **Steps to Reproduce**: 1. Copy a link from Visual Studio Code. 2. Paste the link into the editor. 3. Observe that the link is not created. opw-4460599 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue where customer-facing Chatter comments could disappear while scrolling when a portal page used the sidebar header layout. Users previewing documents such as sales orders should now have a steadier, more reliable page experience.
Original PR description
Since [1] ensures that the Chatter is positioned under the page header, the introduction of the new "sidebar" header template caused misplacement when scrolling. This commit adds a check to avoid applying padding when the header is a sidebar (o_header_sidebar), preventing unintended scrolling behavior in the sidebar layout. Steps to reproduce: - Install the Sales module. - On a sales order, add some comments in the Chatter. - Click on Preview. - Edit the header template and select the last option, "Sidebar". - Save the changes. - Scroll down and observe that the Chatter disappears. opw-4515419 [1]: https://github.com/odoo/odoo/commit/368eb78a9cedfce0802b64fd2782e1c018541e40
This fixes an issue in the HTML editor where converting certain paragraph-like content into a paragraph could remove the intended structure, especially inside list items. The change keeps the paragraph tag in place, helping edited content retain the correct layout and appearance.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When converting paragraph related elements (other than the `<p>` tag itself) to a `<p>` tag, the tag would be unwrapped. Desired behavior after PR is merged: The tag is now converted directly to a `<p>` tag without unwrapping it. task-4488784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents archived products from being shown again on the Point of Sale product screen when loading a previously paid order that used them. It helps keep sales screens clean and aligned with current product availability.
Original PR description
Before this commit, when a product used in a paid order was archived, loading the paid order would cause the product to appear on the product screen. opw-4493666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The EAS field label has been widened so longer electronic invoicing codes are easier to read. This improves the form layout and reduces confusion when users review or enter these values.
Original PR description
Let's increase the label size since the EAS are quite long. task-no Before:  After: 
This fixes a visual issue in the HTML editor where collaborator avatars could briefly disappear and reappear during live editing. Users working together in the same document now get a smoother, less distracting editing experience.
Original PR description
### Steps to reproduce: - Open the same document in two tabs. - Press Enter multiple times in one tab. - Observe the avatar flickers on the other tab with each Enter press. ### Description of the issue/feature this PR addresses: - `refreshSelection` replaced `this.avatarOverlay` children and re-appended the avatar element in `drawPeerAvatar`, causing flicker. ### Desired behavior after PR is merged: - The avatar no longer flickers when pressing Enter. task-4367144
Fixes an issue where Italian invoices could fail to print or send after the tax agency submission option was initially skipped. This helps users complete invoice downloads and later submissions without encountering an error.
Original PR description
This error occurs when an invoice is not initially sent to the tax agency, but we later attempt to print it and send it to the agency. Steps to reproduce: --- - Install ``l10n_it_edi`` module - Switch to ``IT Company`` - Create Customers Invoice > ``Confirm`` > ``Print & Send`` - Disable ``Send to Tax Agency`` > ``Print & Send`` - Now again ``Print & Send`` and ``Print & Send`` Traceback: --- ``KeyError: 'l10n_it_edi_values'`` This commit resolves the error by checking that ``l10n_it_edi_values`` is present in ``move_data``. sentry-6191573767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale loyalty issue where loyalty cards could still receive an expiration date even though that behavior was meant to be disabled. Businesses using POS loyalty programs will see card validity handled consistently with the intended loyalty program settings.
Original PR description
In commit https://github.com/odoo/odoo/commit/837e67e82d4cf662b2dcd5d5750253dbc080bd96 we prevent setting expiration date on `loyalty` type programs for UI and wanted to ensure expiration date is not set on loyalty cards. This PR remove a line which is setting expiration date on `loyalty` type program in POS which missed during forward port PR https://github.com/odoo/odoo/pull/183044
Swiss invoice PDFs generated without payment details no longer include an unexpected blank page at the end. The invoice report is now correctly identified so the Swiss QR code handling works as intended.
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a blank page at the end ### Cause: The report "account.report_invoice" does not have a field `is_invoice_report` set to `True`. When generating an invoice with Swiss localization. It reads the field `is_invoice_report` to add or not the QR code. The bug appears after this [commit](https://github.com/odoo/odoo/commit/bb60952c944db27d71d7fe32ead2dff05c3fe922#diff-b6e108b605fbefba066e3b20f8e030ea78881bbed816f8ac5cb38e745c542739R50) which modified the `_is_invoice_report` method to use the field, but only added the field in "account_invoices". ### Solution: Set the field to True for the report. opw-4467250
Fixes a Point of Sale issue that could show an error when a user tried to change cashier and no cashier options were available. The cashier selection dialog now opens correctly, improving reliability during store operations.
Original PR description
Description of the issue/feature this PR addresses: - Fixed an issue where changing the cashier with no available cashiers caused a traceback due to an undefined `this.dialog` Replaced it with the correct `dialog` reference. ## step to reproduce - install `point of sale` - setup a new point_of_sale , as shown  - start session in that pos. - try to change the cashier 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
The web interface now keeps the database name clearly visible when debug mode and dark mode are both enabled. This improves readability for users and administrators working in dark mode.
Original PR description
Previously after activating debug mode and then dark mode, the letters of database name are not visible clearly. It is happening because in new bootstrap version we are having a color attribute in mark tag which was previously not there. After this commit the database name will be clearly visible in dark mode. Task-4389154 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Discuss now displays exact message times using the browser's locale settings, so users see either 12-hour or 24-hour time based on their personal environment. This makes chat timestamps feel more familiar and avoids layout issues caused by AM/PM labels in compact message views.
Original PR description
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so…
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so that this is the expected format as the user is used to see in all browser apps. Note that we don't choose DB date format, because discuss app are used by many other users and the custom format on whole DB might make some users happy but others not. In particular, the default en_US language time format in Odoo uses 24-hour when lots of english americans are used and prefer 12-hour format. Using the locale format of browser, which tend to rely on OS settings, makes (almost) everyone happy. Also the extra AM/PM could lead to size issue on small squashed messages, this commit also fixes it. opw-4482727 Before / After  
The contract details screen now shows the labels in the part-time section when Belgian payroll group S is installed. This fixes a display issue that could make contract information harder for HR and payroll users to read.
Original PR description
Steps to reproduce: - Install the l10n_be_hr_payroll_group_s module. - Open any contract in employee or payroll. - Check the part-time section under the Details tab. Issue: - Labels do not display. Reason: - The view is inherited in both hr_payroll and l10n_be_hr_payroll_group_s modules. - In hr_payroll, the fields are not grouped, while in l10n_be_hr_payroll_group_s, they are. Solution: - Change the position of the "group_s_code" in l10n_be_hr_payroll_group_s module from inside to after task-4440190
This fixes an incorrect connection mapping in the Shopee sales integration that was introduced shortly before the module was merged. The correction helps ensure Shopee data is interpreted properly, reducing the risk of failed or inaccurate sales synchronization.
Original PR description
Bug introduced in the last changes before merging the module that wasn't caught
The update removes date-dependent information from a Mexican electronic invoicing test file so automated checks no longer fail when the calendar changes. This keeps validation reliable without changing customer-facing behavior.
Original PR description
Now we move to february, the test is failing on runbot... See (similar): https://github.com/odoo/enterprise/commit/e29b2265fe60e90443d753558e6c9a071ee23d33 task-no
Miscellaneous changes
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
Original PR description
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
Original PR description
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
steps to reproduce: -Create a new time off type. -Set the approval radio button to either "By Time Off Officer" or "By Employee's Approver and Time Off Officer." -Leave the "Notified Time Off Officer" field empty. -Try to create a new allocation for the newly created time off type. -Notice that an activity is created for the user who created the allocation. cause: When the "Notified Time Off Officer" field is left empty, no activity or email should be created. solution: Remove sel
Original PR description
steps to reproduce: -Create a new time off type. -Set the approval radio button to either "By Time Off Officer" or "By Employee's Approver and Time Off Officer." -Leave the "Notified Time Off Officer" field empty. -Try to create a new allocation for the newly created time off type. -Notice that an activity is created for the user who created the allocation. cause: When the "Notified Time Off Officer" field is left empty, no activity or email should be created. solution: Remove self.env.user.ids to prevent the creation of an activity for the user. task-4351747 Forward-Port-Of: odoo/odoo#189407
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Original PR description
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Steps to reproduce: - In V17.0 drag and drop an "Image Gallery" block into the page. - Upgrade to 18.0 - Click on the last "Image Gallery" indicator and then quickly on the first one. - Traceback: "TypeError: Cannot read properties of null (reading 'classList') at Carousel._setActiveIndicatorElement ..." This issue is caused by the front-end code of the image gallery, which updates the active indicator during a slide event. When the crash happens, it cannot find the active slide in the
Original PR description
Steps to reproduce: - In V17.0 drag and drop an "Image Gallery" block into the page. - Upgrade to 18.0 - Click on the last "Image Gallery" indicator and then quickly on the first one. - Traceback: "TypeError: Cannot read properties of null (reading 'classList') at Carousel._setActiveIndicatorElement ..." This issue is caused by the front-end code of the image gallery, which updates the active indicator during a slide event. When the crash happens, it cannot find the active slide in the DOM. After investigation, everything already works with Bootstrap, and the purpose of this code remains unclear. However, in the stable version, we are not taking any risks and will not modify it. In this commit, we simply added a return; in case the active slide is not found. opw-4519455 Forward-Port-Of: odoo/odoo#195606
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test
Original PR description
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test by default drops at the middle and top of the drop zones. To avoid this kind of situation, in this commit, we add a step at the beginning of the test to hide the header. [1]: https://github.com/odoo/odoo/commit/e0c16bb9a90dfb378b75e0de059e71f0aebd84fb opw-4494945 Forward-Port-Of: odoo/odoo#195996 Forward-Port-Of: odoo/odoo#195554
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) The stats only occupies a small portion of the width and the button are very cl
Original PR description
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple…
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) The stats only occupies a small portion of the width and the button are very close to the title. We solve the problem by enlarging the stats like the previous result screens to get a layout similar as in v16.0. [FIX] documents: fix close buttons - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) - Click on the "Close" button Nothing happens while it should close the session and get back to the survey form. Actually, the code was closing the session but failed to get back to the survey as it was using "window.history.back()" and the button "create session" launches the session in a new tab that has no history as all the survey happens on the same URL. We solve the problem by reloading the page instead. As the session is closed, the page then displays "Thank you". We change slightly the tour as it expects that at the end, the close button leads to the survey back-end form (as it checks the presence of the button "Create Session" which is the action "action_start_session"). But as the session is started in a new tab, we have decided that it is better to display the final "Thank you" screen rather than returning to the back-end survey form as this is meant to be displayed in public. [FIX] documents: fix infinite line when max score is 0 How to reproduce: - Create a live survey - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the wrong answer to the question At the end of the survey, the score bar size is very big (multiple time of the screen width). We solve the problem by avoiding dividing by 0. Task-4381603 Forward-Port-Of: odoo/odoo#195706 Forward-Port-Of: odoo/odoo#190442
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 --- I confirm I have si
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195468
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. 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#196036 Forward-Port-Of: odoo/odoo#195909
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Original PR description
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange meth
Original PR description
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from…
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange method `_onchange_location_in` triggers. https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/product_strategy.py#L80-L83 We get the `loc_in` value as an empty recordset, because the user removed the `location_in_id` value. So it will lead to the above traceback from the below line https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/stock_location.py#L453-L455 sentry-6210564390 Forward-Port-Of: odoo/odoo#195555
There were problems reported on some invoices caused by rounding errors. This PR solves these problems, and adds more test cases to the precision unit tests. Moreover, handling special tax amount across different tax groups was not done correctly before this commit. Finally, this commit removes the method _aggregate_totals, and relies on accurate subtotals to always calculate the totals. Along with other refactoring and comments added to the code, this commit makes the code more clear an
Original PR description
There were problems reported on some invoices caused by rounding errors. This PR solves these problems, and adds more test cases to the precision unit tests. Moreover, handling special tax amount across different tax groups was not done correctly before this commit. Finally, this commit removes the method _aggregate_totals, and relies on accurate subtotals to always calculate the totals. Along with other refactoring and comments added to the code, this commit makes the code more clear and sound. task-4464702 task-4509607 X-original-commit: https://github.com/odoo-dev/odoo/commit/88f0254f8db263c75d972520226fa17fdef1c96b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194813
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Fo
Original PR description
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Forward-Port-Of: odoo/odoo#193421
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other
Original PR description
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any others field types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195432
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196104 Forward-Port-Of: odoo/odoo#194843
Original PR description
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196104 Forward-Port-Of: odoo/odoo#194843
[opw-4421055](https://www.odoo.com/odoo/project.task/4504454) Forward-Port-Of: odoo/odoo#195786
Original PR description
[opw-4421055](https://www.odoo.com/odoo/project.task/4504454) Forward-Port-Of: odoo/odoo#195786
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n
Original PR description
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina -…
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n_ar_withholding_post_init`, for each company, we will compare a previously created dict to the existing accounts. If an account already exists, the data is removed from the dict, and since it is created before we start looping through the Companies to make the comparison, any removed data is removed for the companies that follow as well. ### Fix reasoning: We will copy the original dict to keep a safe version of the data and only modify the copy during the comparison process. opw-4446501 Forward-Port-Of: odoo/odoo#194329
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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#179592
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196064 Forward-Port-Of: odoo/odoo#195380
Original PR description
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196064 Forward-Port-Of: odoo/odoo#195380
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On…
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477 ### Fix: Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`. opw-4428050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194068
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet
Original PR description
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet 1 - Drop text snippet 2 and hide it for desktop - Drop text snippet 3 - Remove text snippet 3 - Bug => text snippet 1 is not activated as expected [1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337 [2]: https://github.com/odoo/odoo/commit/2de0ad7259993f654ca8d826f5430f78090a28c5 task-4531506 Forward-Port-Of: odoo/odoo#195941 Forward-Port-Of: odoo/odoo#195743
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in `purchase.order` - Set a domain with analytic_distribution e.g - - e.g. ("order_line.analytic_distribution", "=", "Administrative") - Click on Refresh button - The refresh button preview shows x records - Create a new purchase.order - Add analytic on op
Original PR description
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in…
Steps:
- Install `purchase` or any other model with analytic_mixin
- Install `analytic`
- Install `web_studio`
- Enable analytic in configuration
- Add a new approval on 'button_confirm' in `purchase.order`
- Set a domain with analytic_distribution e.g
- - e.g. ("order_line.analytic_distribution", "=", "Administrative")
- Click on Refresh button
- The refresh button preview shows x records
- Create a new purchase.order
- Add analytic on optional column
- Add a new product with analytic_distribution Administrative
- Try to use `button_confirm`
- Approval is not working while the refresh shows record is available
The json fields, in particular the `analytic_distribution` fields, are not designed to be searched via a `filtered_domain` (which is what studio approval uses to check whether or not a button can be used by the current user), this is currently a technical limitation.
To avoid any future problems, this commit prevents users from using a json field to search on them, since this is not supported.
opw-4416646
Forward-Port-Of: odoo/odoo#195916
Forward-Port-Of: odoo/odoo#195765Issue Before This Commit: ============================ A traceback occurs when attempting to sort pickings by zip if any picking has a False or empty zip value. Steps to Reproduce: ===================== 1. Install the stock_fleet module. 2. Navigate to Batch Transfer in the Stock module under the Operations tab. 3. Create a new batch and add pickings, ensuring some have a zip value while others do not. 4. Save the batch, which triggers a traceback error: TypeError: '<' not
Original PR description
Issue Before This Commit: ============================ A traceback occurs when attempting to sort pickings by zip if any picking has a False or empty zip value. Steps to Reproduce: ===================== 1. Install the stock_fleet module. 2. Navigate to Batch Transfer in the Stock module under the Operations tab. 3. Create a new batch and add pickings, ensuring some have a zip value while others do not. 4. Save the batch, which triggers a traceback error: TypeError: '<' not supported between instances of 'bool' and 'str'. With This Commit: ===================== The issue occurred because sorting directly on the zip caused an error when the zip was False. this fix ensures that sorting treats zip as an empty string () when it is False, preventing the error. task - [4535113](https://www.odoo.com/odoo/my-tasks/4535113) Forward-Port-Of: odoo/odoo#195957
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c
Original PR description
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id.…
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd - On TODO picking, do the following steps WITHOUT CLICKING ON SAVE - Operations -> Add a line: (demand 0, quantity 0) - Click on 'Open Move' button (fa-list icon) - Popup 'Open: Stock move': Add a line - Popup 'Add line: <product>': click on 'New' - Popup 'Create Move Line': click on 'Save & Close' - Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close' - Validate picking -> Create backorder => Check picking move_line_ids = EMPTY ## Solution Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list). OPW-3974109 Forward-Port-Of: odoo/odoo#171766
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195496 Forward-Port-Of: odoo/odoo#194500
Original PR description
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195496 Forward-Port-Of: odoo/odoo#194500
**[FIX] account: Account Journal Late Bills Count** This fix mitigates an issue when a line of a Bill is paid but appears in the late Bills count in the dashboard. **Steps to reproduce:** 1. Create a payment term to pay in installemts. 2. Create a bill an X amount back in the past to have one installment as late. 3 - Pay the late installment **Issue**: The paid installment will still be counted as late in the dashboard. **Fix**: filter out line with residual amount different than
Original PR description
**[FIX] account: Account Journal Late Bills Count** This fix mitigates an issue when a line of a Bill is paid but appears in the late Bills count in the dashboard. **Steps to reproduce:** 1. Create a payment term to pay in installemts. 2. Create a bill an X amount back in the past to have one installment as late. 3 - Pay the late installment **Issue**: The paid installment will still be counted as late in the dashboard. **Fix**: filter out line with residual amount different than zero. _opw-4327227_ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191600
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill
Original PR description
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product…
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill with **Product B**, with a cost of 1000 and a quantity of 2. - Add a line with **Product B**, with the same cost but a quantity of -1. In the product margin report, the `total_cost` for **Product B** is shown as 3000, even though we only bought for 1000. In `_compute_product_margin_fields_values`, the SQL query takes the absolute value of the balance of every account move line to compute `total`. This means negative values become positive and are added to the positive values instead of canceling each other out, creating the above issues. As a result, the product margin report does not align with the balance sheet. The absolute value is used because `total` is used to compute statistics related to both `out_invoice` (e.g., turnover) and `in_invoice` (e.g., total cost), which both need to be positive. However, the same result can be achieved by inverting the sign for `out_invoice`. opw-4342691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193440
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field
Original PR description
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field does not appear. - Attempt to submit the form. - Bug: the form is not sent and there is an error message. The error occurs preventing the record from being created because all required fields are not present, we should use the default value as it has been provided. This commit prevents adding the "disabled" attribute to inputs that are required for models. opw-4447039 Forward-Port-Of: odoo/odoo#195660 Forward-Port-Of: odoo/odoo#194902
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent
Original PR description
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent crashes. [1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1#diff-b51336c1ad97255bfb3646f013327eca1904ca194078f4ce671e517096233c58 task-4420262 Forward-Port-Of: odoo/odoo#195940 Forward-Port-Of: odoo/odoo#194976
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task
Original PR description
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task- 4494040 Forward-Port-Of: odoo/odoo#194465
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
Original PR description
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the w
Original PR description
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the website_sequence of conflicting products to ensure all products have unique values. **Affected Versions:** 16.0~master opw-4150099 Forward-Port-Of: odoo/odoo#195880 Forward-Port-Of: odoo/odoo#191297
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from
Original PR description
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from 17.4): - Install website_sale module - Go to /sitemap.xml - Observe that all the products and category urls are duplicated. [1]: https://github.com/odoo/odoo/commit/1b52b00d2aa96b9360d50a0f0960f1febb5e607e opw-4420398 task-4074719 Forward-Port-Of: odoo/odoo#195949
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527
Original PR description
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527 Forward-Port-Of: odoo/enterprise#77238
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when tr
Original PR description
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the…
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when trying to read on it. When exporting a report with sections, `dispatch_report_action` is called on the first section, it detects that this is a section and calls the same method on the parent report. This commit (https://github.com/odoo/enterprise/commit/8213813e68f02d88934285a44a3413505f6ca187) removed the line getting the options for the parent report call to keep the specific options of each section. Specifically, the "report_id" key in the options is the id of the first section, causing the method to be called on the section. ### Solution: Setting the key "report_id" in the options of the parent report. This way the fix of the commit introducing the bug is still active. opw-4501376 Forward-Port-Of: odoo/enterprise#78185
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 F
Original PR description
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 Forward-Port-Of: odoo/enterprise#78074
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/ente
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/enterprise#78085
Before this commit, if a user was an attendee of an event linked to an appointment type, but did not have access to the appointment (not part of the staff_user_ids), an access error would occur when trying to sync their calendar with Google or Microsoft. This error happened inside the `_get_customer_description` function overridden in the appointment module. opw-4402859 Forward-Port-Of: odoo/enterprise#76113
Original PR description
Before this commit, if a user was an attendee of an event linked to an appointment type, but did not have access to the appointment (not part of the staff_user_ids), an access error would occur when trying to sync their calendar with Google or Microsoft. This error happened inside the `_get_customer_description` function overridden in the appointment module. opw-4402859 Forward-Port-Of: odoo/enterprise#76113
Steps to reproduce ================== - Install hr_timesheet - Use an android device - Click on a time field => A numeric virtual keyboard appears. This prevents us from entering the `:` character. Cause of the issue ================== The inputmode attribute is set to numeric Solution ======== Set the inputmode to it's default value: text. See also [float_time_field] --- [float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2e
Original PR description
Steps to reproduce ================== - Install hr_timesheet - Use an android device - Click on a time field => A numeric virtual keyboard appears. This prevents us from entering the `:` character. Cause of the issue ================== The inputmode attribute is set to numeric Solution ======== Set the inputmode to it's default value: text. See also [float_time_field] --- [float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2eb632 opw-4344083 Forward-Port-Of: odoo/enterprise#77339
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Original PR description
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
Original PR description
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Original PR description
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Step: - Install colombian localisation and other localisation which is part of latam localisation and contains `Identification Type` field in checkout address for example Argentina. - Install Ecommerce app. - Set Argentina as country on company and in accounting settings. - Go to shop page. - Add an product in cart and goto checkout address page. - Try to change `Identification Type` field. Issue: - Traceback cannot find parentElement. Cause: - For setting visibility of colombian r
Original PR description
Step: - Install colombian localisation and other localisation which is part of latam localisation and contains `Identification Type` field in checkout address for example Argentina. - Install Ecommerce app. - Set Argentina as country on company and in accounting settings. - Go to shop page. - Add an product in cart and goto checkout address page. - Try to change `Identification Type` field. Issue: - Traceback cannot find parentElement. Cause: - For setting visibility of colombian related fields depending on `ID Type` field we forgot to check website country and selected country is columbian country and which cause issue when multiple latam related localisation install in same db. Fix: - Check colombian country before setting visibility for colombian related field. task-3628329 Forward-Port-Of: odoo/enterprise#77829
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
Original PR description
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78319 Forward-Port-Of: odoo/enterprise#77941
Original PR description
This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78319 Forward-Port-Of: odoo/enterprise#77941
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Sen
Original PR description
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- *…
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Send the request to terminal * Disconnect ethernet cable from the worldline terminal * Cancel the payment > Observation: After the timeout, two errors appear: 1: underfined:undefined (Bug) 2: Please check if your iot box is still connected. (Normal) Why the fix: ------------ This commit https://github.com/odoo/enterprise/commit/35a392c27e70ffb5f4a5d8ca32bf10c38d7f709c added one more error throwing other than `_onActionFail()` when sending requests. In our case since the error is due to a timeout, it will raise the `_onActionFail()` but also the `Promise.reject(e)`. We consider that the `_onActionFail()` is enough for all potential failure here. opw-4414175 Forward-Port-Of: odoo/enterprise#77606 Forward-Port-Of: odoo/enterprise#77555
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
Original PR description
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
The date field description was saying "customs number", but it should be "Customs Number Date". opw-4507567 Forward-Port-Of: odoo/enterprise#78252 Forward-Port-Of: odoo/enterprise#78165
Original PR description
The date field description was saying "customs number", but it should be "Customs Number Date". opw-4507567 Forward-Port-Of: odoo/enterprise#78252 Forward-Port-Of: odoo/enterprise#78165
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Original PR description
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;  - Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`). ___ **Issue:** Can't access `EC Sales List` o
Original PR description
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or…
**Steps to reproduce:**
- Use the `NL Company`;
- Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`):
- Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;
- Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`).
___
**Issue:**
Can't access `EC Sales List` of the Dutch company after deleting any or both of the `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers.
___
**Expected:**
Users should be able to access `EC Sales List` even when an identifier is deleted as there is a fallback.
___
**Cause:**
The fallback doesn't refer to the good tax options.
https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/models/account_sales_report.py#L82-L84
___
**Fix:**
Adapt the fallback references' module for retrieval as done for testing in: https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/tests/test_sales_report.py#L22-L24
___
opw-4425376
Forward-Port-Of: odoo/enterprise#78032
Forward-Port-Of: odoo/enterprise#76366### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab)
Original PR description
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries…
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab) is set as regular operation. 3. Add both fields (type for 347 and type for 349) to the customer invoices list view using Studio. 4. Observe that for invoices where 347 is set, 349 is also set (E-Suministros/Supplies). ### Cause: In the `account_move` model of `l10n_es_reports`, the field `l10n_es_reports_mod349_invoice_type` was being set with a default value even when `Available for Mod349` is False. opw-4339292 Forward-Port-Of: odoo/enterprise#77699 Forward-Port-Of: odoo/enterprise#76042