Friday, April 25, 2025
68 changes · saas-18.2
Resolved issues and error corrections
Updated Spanish labels for Peruvian identification types to include their standard abbreviations. This reduces customer confusion when selecting or reviewing tax identification information.
Original PR description
This 'bug' was introduced when translating strings from data files became possible (87fc0d6b). The translation of some fields in Spanish did not include their respective abbreviations leading to confusion of clients. This commit appends the abbreviations of the problematic strings. RD Feedback task: 4679704 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The online store cart now converts customer-entered product quantities to whole numbers, preventing unexpected purchases of tiny fractional amounts like 0.01. This keeps the normal shopping experience consistent while still allowing custom integrations to use fractional quantities when intentionally configured.
Original PR description
Commit 34ba0d3251486a3f7fd16709debb5c2b2d14ffa9 dropped the cast to integer for cart quantities, potentially allowing customers to buy 0.01 quantities of a product, which isn't the expected behavior. This commit casts the values given through the controllers, still keeping the ability for custom code to generate lines with floats as quantities if needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#82782 Forward-Port-Of: odoo/enterprise#79775
Original PR description
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#82782 Forward-Port-Of: odoo/enterprise#79775
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83665
Original PR description
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83665
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83672
Original PR description
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83672
In [PR 191823](https://github.com/odoo/odoo/pull/191823) in the comunity repo, a new functionality was added to allow a user with salesman permissions to send and print the invoice. However this change had unexpected effects in the mexican localization, precisely in the _clean_cfdi_values function which now removes all values from the dictionary that are not plain text. The complemento's injector was using the addenda value from the dictionary which was a recordset of the l10n_mx_edi.addenda
Original PR description
In [PR 191823](https://github.com/odoo/odoo/pull/191823) in the comunity repo, a new functionality was added to allow a user with salesman permissions to send and print the invoice. However this change had unexpected effects in the mexican localization, precisely in the _clean_cfdi_values function which now removes all values from the dictionary that are not plain text. The complemento's injector was using the addenda value from the dictionary which was a recordset of the l10n_mx_edi.addenda model, with these changes, this recordset was removed from the dictionary, causing the complemento to never be added. To fix it, the values relevant to the complemento have been marked as unsudo, thus preventing them from being removed in the clean_cfdi_values function. Forward-Port-Of: odoo/enterprise#83772
Forward-Port-Of: odoo/enterprise#83084 Forward-Port-Of: odoo/enterprise#81187
Original PR description
Forward-Port-Of: odoo/enterprise#83084 Forward-Port-Of: odoo/enterprise#81187
…n manual line with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 Forward-Port-Of: odoo/enterprise#83880 Forward-Port-Of: odoo/enterprise#83809
Original PR description
…n manual line with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 Forward-Port-Of: odoo/enterprise#83880 Forward-Port-Of: odoo/enterprise#83809
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#83939 Forward-Port-Of: odoo/enterprise#82980
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#83939 Forward-Port-Of: odoo/enterprise#82980
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ
Original PR description
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian…
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occured in the generation of the return label ### Cause of the issue: The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here: https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point. #### Note: Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels. opw-4562040 Forward-Port-Of: odoo/enterprise#83436 Forward-Port-Of: odoo/enterprise#83357
In this commit we fix the website_sale_renting_select_wrong_period tour that can cause undeterministic errors. Forward-Port-Of: odoo/enterprise#83700 Forward-Port-Of: odoo/enterprise#83568
Original PR description
In this commit we fix the website_sale_renting_select_wrong_period tour that can cause undeterministic errors. Forward-Port-Of: odoo/enterprise#83700 Forward-Port-Of: odoo/enterprise#83568
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)
Original PR description
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)`, the date field gets considered 'dirty' by the ORM (unless it is explicitly set in the vals), and when the `account.move.line` tries to set-up its date, which is related to the move, the compute method for the date is triggered as the field was flagged as dirty. opw-4662209 Forward-Port-Of: odoo/enterprise#83870
The error occurs when attempting to add a date in line in the Salary Rule Parameters Steps to Reproduce: --- - Install the `hr_payroll` module - Payroll > Configuration > Rule Parameters - Create New > History > Add a Line > Add Date Traceback: --- AttributeError: 'bool' object has no attribute 'replace' At [1], this error occurs because `value_id.parameter_value` is False. This happens because first we're adding a date, so `value_id.parameter_value` is initially empty. [1]- ht
Original PR description
The error occurs when attempting to add a date in line in the Salary Rule Parameters Steps to Reproduce: --- - Install the `hr_payroll` module - Payroll > Configuration > Rule Parameters - Create New > History > Add a Line > Add Date Traceback: --- AttributeError: 'bool' object has no attribute 'replace' At [1], this error occurs because `value_id.parameter_value` is False. This happens because first we're adding a date, so `value_id.parameter_value` is initially empty. [1]- https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/hr_payroll/models/hr_rule_parameter.py#L101-L102 sentry-6531613276 Forward-Port-Of: odoo/enterprise#83224
Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559 Fo
Original PR description
Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559 Forward-Port-Of: odoo/enterprise#83512 Forward-Port-Of: odoo/enterprise#83141
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterpr
Original PR description
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterprise/commit/931d7b199f1183acfbb42325025a6b62b2e73de1 but not forward ported yet. task-4368532 Forward-Port-Of: odoo/enterprise#83842 Forward-Port-Of: odoo/enterprise#80201
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
Original PR description
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
Forward-Port-Of: odoo/enterprise#83865 Forward-Port-Of: odoo/enterprise#81174
Original PR description
Forward-Port-Of: odoo/enterprise#83865 Forward-Port-Of: odoo/enterprise#81174
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and s
Original PR description
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and shipping addresses. If the shipping address is unknown to the system, a validation error blocks payment. If known, the payment goes through but results in a generic shipping error with no further details or options for the user. Cause ----- `billing_address` was wrongly parsed as `shipping_address` in a5df1a7. Solution -------- Parse `shipping_address` correctly. opw-4710674 Forward-Port-Of: odoo/odoo#207010
### Steps to reproduce: - Create a storable product tracked by lot and lot valuated - Create a lot for 10 units of that product in stock - login a user that is not administrator in inventory - Create and confirm a delivery for 1 units of your product - Try to validate the delivery #### > access right error ### Cause of the issue: During the `_action_done` of the `stock.move` we will need to change the valuated price of the product after done: https://github.com/odoo/odoo/blob/6beb
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot and lot valuated - Create a lot for 10 units of that product in stock - login a user that is not administrator in inventory - Create and confirm a delivery for 1 units of your product - Try to validate the delivery #### > access right error ### Cause of the issue: During the `_action_done` of the `stock.move` we will need to change the valuated price of the product after done: https://github.com/odoo/odoo/blob/6beb3ea82d75513803ae78f5bc71024313938a97/addons/stock_account/models/stock_move.py#L378 https://github.com/odoo/odoo/blob/6beb3ea82d75513803ae78f5bc71024313938a97/addons/stock_account/models/stock_move.py#L461-L464 However, only admin inventory users have the read access rights to the `stock.valuation.layer` model. opw-4680641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204676
**Before this PR:** - In a fullscreen mode, mail preview was visible only on the top half of the screen. - Traceback when changing name of the image. - 'Create and edit' option when creating a new tag. **After this PR:** - String of `reward_message` will be changed to 'Thank You Message'. - Only 'Create' option will displayed while creating a new tag. - Mail preview will be visible in the center of the screen. - 'Add to Templates' in mass_mailing preview will no longer be visible. U
Original PR description
**Before this PR:** - In a fullscreen mode, mail preview was visible only on the top half of the screen. - Traceback when changing name of the image. - 'Create and edit' option when creating a new tag. **After this PR:** - String of `reward_message` will be changed to 'Thank You Message'. - Only 'Create' option will displayed while creating a new tag. - Mail preview will be visible in the center of the screen. - 'Add to Templates' in mass_mailing preview will no longer be visible. Updated the query count in 'test_campaign_send_mailing' due to the addition of the 'in' operator in '_get_card_element_values' function. Task-4387904 Forward-Port-Of: odoo/odoo#198470
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in
Original PR description
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between…
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product invoiced on ordered qty 2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique) 3. Make a purchase for the product, invoice -> post 4. The next day, receive the product 5. Check the exchange journal to see the offending AMLs **Cause of the issue:** In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`* https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's. It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts. **Fix:** Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.) opw-4655669 Forward-Port-Of: odoo/odoo#206484 Forward-Port-Of: odoo/odoo#204505
Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the P
Original PR description
Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205245 Forward-Port-Of: odoo/odoo#201253
Enable canvas image smoothing with high quality settings to improve the visual output of resized images. The issue was most noticeable in the 128px version, which appeared blurry or pixelated. <img width="1279" alt="Screenshot 2025-04-02 at 11 03 17" src="https://github.com/user-attachments/assets/dd2c9f92-1ad9-409b-9c17-184059dc5adf" /> opw-4689905 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204431
Original PR description
Enable canvas image smoothing with high quality settings to improve the visual output of resized images. The issue was most noticeable in the 128px version, which appeared blurry or pixelated. <img width="1279" alt="Screenshot 2025-04-02 at 11 03 17" src="https://github.com/user-attachments/assets/dd2c9f92-1ad9-409b-9c17-184059dc5adf" /> opw-4689905 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204431
…ne with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206946 Forward-Port-Of: odoo/odoo#206848
Original PR description
…ne with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206946 Forward-Port-Of: odoo/odoo#206848
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 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#206925 Forward-Port-Of: odoo/odoo#201846
Original PR description
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 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#206925 Forward-Port-Of: odoo/odoo#201846
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 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#207059 Forward-Port-Of: odoo/odoo#205048
Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207034
Original PR description
Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207034
Follow-up of https://github.com/odoo/odoo/pull/204922 PR above improved visual of (edited) label so that this is inline to the message content. Due to implementation details, it adds new test coverage when saving an edited message without changes, which may not have (edited) label with a simpler fix and this would be obviously a bug. The new steps to test may do `ctrl-ENTER` too soon, which would lead to not saving the message edition and instead the message is still being edited. As a res
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/204922 PR above improved visual of (edited) label so that this is inline to the message content. Due to implementation details, it adds new test coverage when saving an edited message without changes, which may not have (edited) label with a simpler fix and this would be obviously a bug. The new steps to test may do `ctrl-ENTER` too soon, which would lead to not saving the message edition and instead the message is still being edited. As a result, this assertion would fail: ``` Failed to find 1 of ".o-mail-Message-content" with text "edited again (edited)" (Timeout of 3 seconds). Found 0 instead. ``` This commit fixes the issue by awaiting that the message being edited shows the input with message content in textarea, ensuring the user can actually edit the message and thus the ctrl-ENTER shortcut works and saves the message edition. runbot-1629170 Forward-Port-Of: odoo/odoo#207079
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account. **Steps to reproduce:** - Make a Sale Order in the sales app - Go to POS and make a down payment for it. - Settle the order - See tha
Original PR description
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the…
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account. **Steps to reproduce:** - Make a Sale Order in the sales app - Go to POS and make a down payment for it. - Settle the order - See that the down payment has not been applied and only the product is present **Why the fix:** When reading the order we are trying to settle from the backend we also trigger the `missingRecursive` function as the lines corresponding to the downpayment line and the line sections were missing from the loaded records. `sale.order.line` records are thus read from the backend but are not linked back to the sale order leading to the missing lines on the pos order as well. opw-4718691 Forward-Port-Of: odoo/odoo#206638
This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag a menu item (without dropping it) to the right to create a sub-menu. - The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and uncle
Original PR description
This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu…
This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag a menu item (without dropping it) to the right to create a sub-menu. - The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and unclear from a UX perspective. | BEFORE | AFTER | | ------------- | ------------- | |  |  | ---------------- **Issue 2:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag and drop the second menu item to the right to create a sub-menu. - Drag another menu item (without dropping it) to the right to create a second sub-menu below the first one. - Without releasing it, continue dragging it to the right. - The issue is that the placeholder disappears at this point. To make it reappear, the menu item must be moved slightly to the left again. This results in a very poor user experience and makes sub-menu creation messy. | BEFORE | AFTER | | ------------- | ------------- | |  |  | task-4422810 Forward-Port-Of: odoo/odoo#204436
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current lo
Original PR description
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the…
This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current logic in `base_document_layout.py`, where the width (w) is computed using int(50 * base_w / base_h). For highly vertical images (e.g., width = 8, height = 901), this calculation results in w = 0, which subsequently causes a ValueError when passed to the resize() function. This commit resolves the error by using `math.ceil` to compute the width (w) instead of int, ensuring that the value is never zero, even for extremely vertical images. Sentry-6516888945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205017
When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are n
Original PR description
When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are not reflected. This commit ensures the correct handling of punycode domains so that the robots.txt is properly served, regardless of whether the domain is accessed in Unicode or punycode form. opw-4641081 Forward-Port-Of: odoo/odoo#206215
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users Steps to reproduce: - Select company BE Company CoA - Open Settings > Accounting > PEPPOL Electronic Invoicing - Activate Electronic Invoicing (if is not activated) - Go to
Original PR description
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test…
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users
Steps to reproduce:
- Select company BE Company CoA
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Activate Electronic Invoicing (if is not activated)
- Go to Accounting / Configuration / EDI Proxy Users
- Select the unique record (demo2peppol)
- Edit the id_client of the record to another one (this must need Odoo Studio or Odoo Inspector > Write > {"id_client": "another"})
- Go to tree view of EDI Proxy Users
- Archive it
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Remove from PEPPOL (archived record will not be deleted)
- Activate Electronic Invoicing Again (now you have one record active and another not)
- Go to Contacts > Search "BE Company CoA" > Select Contact
- Go to Accounting Tab > Customer Invoices section > Enable eInvoice Format (BIS Billing 3.0)
- Go to Contact & Addresses Tab
- Try to add a new Contact type (error while saving)
opw-4572074
Forward-Port-Of: odoo/odoo#206063
Forward-Port-Of: odoo/odoo#201606Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure" option in the settings. - Create a new quotation. - In the sale order line, enable the Product Variant field. - Try to create a new “product.product” **Problem:** A validation Error is triggered: ``` The operation cannot be completed - Create/update: a mandatory field is not set. - D
Original PR description
Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure"…
Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure" option in the settings. - Create a new quotation. - In the sale order line, enable the Product Variant field. - Try to create a new “product.product” **Problem:** A validation Error is triggered: ``` The operation cannot be completed - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Product (product.template) Field: Unit of Measure (uom_id) ``` **Explanation:** This happens because a default value for the UoM is passed through the context. As a result, we skip the computation of “uom_id”: https://github.com/odoo/odoo/blob/2b38c1f446441e04f8d85125a9ec6562d13b7ce8/addons/product/models/product_template.py#L27 However, this default is derived from the field “product_uom” that is present in the view but restricted to users in the "uom.group_uom" group. If the current user doesn't belong to this group (if you don't enable the param in the settings), the field is hidden and its value is empty, causing the default to be set to False. https://github.com/odoo/odoo/blob/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4/addons/sale/views/sale_order_views.xml#L537 **Solution:** Force the computation of “uom_id” by removing “default_uom_id” from the context when its value is “False”. opw-4717913 Forward-Port-Of: odoo/odoo#205881
Using `setContent` inside a test with a selection change and rely on the selectionchange event to trigger a modification of the interface that is the very subject of the test is error-prone as the sequence of events in that case is non-deterministic under heavy cpu load and thus ends up creating a hidden race condition. Forward-Port-Of: odoo/odoo#207192
Original PR description
Using `setContent` inside a test with a selection change and rely on the selectionchange event to trigger a modification of the interface that is the very subject of the test is error-prone as the sequence of events in that case is non-deterministic under heavy cpu load and thus ends up creating a hidden race condition. Forward-Port-Of: odoo/odoo#207192
**Current behavior before PR:** - When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback. **Desired behavior after PR is merged:** - Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly. task:4730500 Forward-Port-Of: odoo/odoo#206866 Forward-Port-Of: odoo/odoo#206272
Original PR description
**Current behavior before PR:** - When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback. **Desired behavior after PR is merged:** - Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly. task:4730500 Forward-Port-Of: odoo/odoo#206866 Forward-Port-Of: odoo/odoo#206272
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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#
Original PR description
The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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#206496 Forward-Port-Of: odoo/odoo#206420
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More acc
Original PR description
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More accurately select the correct insertion point of the inherited view OPW-4716782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205474
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#207135 Forward-Port-Of: odoo/odoo#205940
Original PR description
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#207135 Forward-Port-Of: odoo/odoo#205940
Forward-Port-Of: odoo/odoo#206969
Original PR description
Forward-Port-Of: odoo/odoo#206969
Scenario: - edit the website theme and change a font to external font Buda - save and go back to edition and theme tab Result: Infinite spinning when loading the theme tab, and we see an error of AssetsLoadingError as well as an error 400 in console when loading https://fonts.googleapis.com/css?family=Buda URL. Issue: Buda font only has a 300 size, but when loading for the FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts returns an error because there os no 400 size vers
Original PR description
Scenario: - edit the website theme and change a font to external font Buda - save and go back to edition and theme tab Result: Infinite spinning when loading the theme tab, and we see an error of AssetsLoadingError as well as an error 400 in console when loading https://fonts.googleapis.com/css?family=Buda URL. Issue: Buda font only has a 300 size, but when loading for the FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts returns an error because there os no 400 size version of the font. This is not an issue when adding the font because we use 300 up to 700: d0ba6c26e64e711e21b191bdba0ede14abc6afb9 This is also not an issue for self-hosted google font because we load it with the same parameters: 5145d84dc02d8068a5feaac769f5d83cefc65804 opw-4657897 opw-4497707 opw-4338034 opw-3236787 opw-3584322 opw-3306789 Forward-Port-Of: odoo/odoo#207229
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
Original PR description
During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_
Original PR description
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)`, the date field gets considered 'dirty' by the ORM (unless it is explicitly set in the vals), and when the `account.move.line` tries to set-up its date, which is related to the move, the compute method for the date is triggered as the field was flagged as dirty. opw-4662209 Forward-Port-Of: odoo/odoo#204665
Before this commit, if a combo product contains a product with multi options attribute, you will have an error when proceeding the order. opw-4637372 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202663
Original PR description
Before this commit, if a combo product contains a product with multi options attribute, you will have an error when proceeding the order. opw-4637372 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202663
Before this commit, if a POS session was open on two devices and closed on one, a new session would be automatically created and both devices would switch to it. However, if the "Backend" button was clicked on one device—removing the session—then clicking "Backend" on the second device would trigger a missing record error, since the session was already deleted. opw-4709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#
Original PR description
Before this commit, if a POS session was open on two devices and closed on one, a new session would be automatically created and both devices would switch to it. However, if the "Backend" button was clicked on one device—removing the session—then clicking "Backend" on the second device would trigger a missing record error, since the session was already deleted. opw-4709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205176
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id of this custom report (e.g. account.report_invoice_copy_1) - Go to "Settings / Technical / Email / Email Templates" - Open "Invoice: Sending" - In "Settings" tab, set the custom report as dynamic report - Go to "Settings / Technical / Parameters / System Parameters" - Add a new param
Original PR description
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id…
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id of this custom report (e.g. account.report_invoice_copy_1) - Go to "Settings / Technical / Email / Email Templates" - Open "Invoice: Sending" - In "Settings" tab, set the custom report as dynamic report - Go to "Settings / Technical / Parameters / System Parameters" - Add a new parameter: * Key: account.custom_templates_facturx_list * Value: [id of the custom report] (e.g. account.report_invoice_copy_1) - Create an invoice - Confirm the invoice - Send the the invoice via "Send & Print" button - Check the attached PDF **Issue:** 2 PDF are sent: the default invoice report and the custom one as configured on the email template. The default one has the factur-x version embedded in it, but not the custom one. **Cause:** The hook that embed factur-x into the PDF is called after the creation of the default PDF report. The custom reports (i.e. the dynamic ones) are created afterwards. However, the code that should trigger the hook for these ones is only doing it when coming from "Print" action and not from "Send & Print" action. **Solution:** Also trigger the hook to embed factur-x in custom report when using "Send & Print" action. opw-4645564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206763 Forward-Port-Of: odoo/odoo#204588
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207264 Forward-Port-Of: odoo/odoo#206985
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207264 Forward-Port-Of: odoo/odoo#206985
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi
Original PR description
Two lines in the French Chart of Accounts were inverted. 467 and 468 Steps to reproduce: ------------------- * French Fiscal Localization * Open the Chart of Accounts * Line 467 and 468 > Observation: Why the fix: ------------ Based on french gouvernement documentation https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/Plan-de-comptes-PCG-2025.pdf opw-4680252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207216 Forward-Port-Of: odoo/odoo#205323
Steps to reproduce the issue: - Create a new website using the configurator. - At the step where the color palette is defined, upload a large logo (e.g., 6 MB). - A traceback occurs. The issue comes from the fact that the logo is added to the browser's session storage, which has a 10 MB limit in most modern browsers. Before the logo upload, the session storage already contains some data, and adding a large file goes over the 10 MB limit, which causes the traceback. This commit prevent
Original PR description
Steps to reproduce the issue: - Create a new website using the configurator. - At the step where the color palette is defined, upload a large logo (e.g., 6 MB). - A traceback occurs. The issue comes from the fact that the logo is added to the browser's session storage, which has a 10 MB limit in most modern browsers. Before the logo upload, the session storage already contains some data, and adding a large file goes over the 10 MB limit, which causes the traceback. This commit prevents users from uploading a logo larger than 2.5 MB, which is already a lot for a logo shown in a website header. task-4742810 Forward-Port-Of: odoo/odoo#207071
Before this PR: When applying TDS through the TDS Entry wizard, the system would attempt to send a notification email when message is posted in chatter. If the sender's email address was not configured in the system, it would raise a blocking error. This prevented users from applying TDS without proper email configuration. After this PR: The TDS application process now works regardless of email configuration. The chatter message is still created and visible in the UI, but the email is
Original PR description
Before this PR: When applying TDS through the TDS Entry wizard, the system would attempt to send a notification email when message is posted in chatter. If the sender's email address was not configured in the system, it would raise a blocking error. This prevented users from applying TDS without proper email configuration. After this PR: The TDS application process now works regardless of email configuration. The chatter message is still created and visible in the UI, but the email is no longer required for TDS application. This ensures that TDS application is not blocked by email configuration. Task-4680364 Forward-Port-Of: odoo/odoo#204366
### Browser: Firefox ### Steps to Reproduce: - Go to To-Do - Type something - Select the typed text - Font size is not visible and dropdown doesn't appear on single click ### Description of the issue/feature this PR addresses: - Font size input inside the iframe was not properly initialized in Firefox due to delayed iframe load. - Clicking once on the font size selector did not open the dropdown. ### Desired behavior after PR is merged: - Font size input initialization is d
Original PR description
### Browser: Firefox ### Steps to Reproduce: - Go to To-Do - Type something - Select the typed text - Font size is not visible and dropdown doesn't appear on single click ### Description of the issue/feature this PR addresses: - Font size input inside the iframe was not properly initialized in Firefox due to delayed iframe load. - Clicking once on the font size selector did not open the dropdown. ### Desired behavior after PR is merged: - Font size input initialization is deferred until iframe is fully loaded. - Dropdown now opens correctly on single click and displays current font size. task-4735622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206581
### Description of the issue/feature this PR addresses: - The `_t` call was used with non-static string (title), which breaks translation extraction since only static strings can be exported to .pot files. - Additionally, the title was directly injected into the DOM without escaping. ### Desired behavior after PR is merged: - The `_t` call is removed, as title passed to `_getBannerCommand` is already a translated static string. The value is now also passed through `htmlEscape()` befo
Original PR description
### Description of the issue/feature this PR addresses: - The `_t` call was used with non-static string (title), which breaks translation extraction since only static strings can be exported to .pot files. - Additionally, the title was directly injected into the DOM without escaping. ### Desired behavior after PR is merged: - The `_t` call is removed, as title passed to `_getBannerCommand` is already a translated static string. The value is now also passed through `htmlEscape()` before being used in the aria-label attribute. task-4639885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206954 Forward-Port-Of: odoo/odoo#205322
In `syncAllOrders`, we can specify which orders should be synced using options. This means that not all pending orders need to be synced at once. However, `clearPendingOrder` currently removes all pending orders, even those that haven't been synced, leading to order loss. This commit ensures that only synced orders are removed from pendingOrders. Task: 4702408 Forward-Port-Of: odoo/odoo#204786
Original PR description
In `syncAllOrders`, we can specify which orders should be synced using options. This means that not all pending orders need to be synced at once. However, `clearPendingOrder` currently removes all pending orders, even those that haven't been synced, leading to order loss. This commit ensures that only synced orders are removed from pendingOrders. Task: 4702408 Forward-Port-Of: odoo/odoo#204786
Currently, an exception is generated when the system tries to find the product category after all product categories have been deleted. Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete all categories. 4. Navigate to Point of Sale -> load sample of furniture, bakery or restaurant shop 5. An error occurs. Error: ``` ParseError while parsing /home/odoo/src/odoo/saas-18.2/addons/product/dat
Original PR description
Currently, an exception is generated when the system tries to find the product category after all product categories have been deleted. Steps to reproduce: 1. Install the `point_of_sale` module…
Currently, an exception is generated when the system tries to find the product category after all product categories have been deleted. Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete all categories. 4. Navigate to Point of Sale -> load sample of furniture, bakery or restaurant shop 5. An error occurs. Error: ``` ParseError while parsing /home/odoo/src/odoo/saas-18.2/addons/product/data/product_demo.xml:10, somewhere inside ``` This issue[1] occurs because when the system tries to reference the missing product category, it results in a ParseError due to a missing required record. [1] - https://github.com/odoo/odoo/blob/6c01e3994fab23ff1b23da807ecb0bf551066816/addons/product/data/product_demo.xml#L10-L16 This fix resolves the issue by returning False when the reference product category is missing. sentry-6251128895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202516
### Before this commit: The warning message `Invoice will soon be sent to EDI` was not displayed correctly, resulting in a broken UI at the top of the invoice form. - **UI before fix:**  ### After this commit: The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling. - **UI after fix:**  ### After this commit: The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling. - **UI after fix:**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206983
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login` is checked; - Share the survey (copy the `Survey Link`); - In a private navigator (to ensure no login data are saved): - Log in as Demo user; - Answer the survey (using the copied link above); - Go to Surveys / Participations; - Enter the record of your test (`Contact` field shoul
Original PR description
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login`…
## Issue:
Survey's PDF certifications no longer display the company logo when printed by other companies' users.
## Steps to reproduce:
- Create a survey with certification and ensure `Require Login` is checked;
- Share the survey (copy the `Survey Link`);
- In a private navigator (to ensure no login data are saved):
- Log in as Demo user;
- Answer the survey (using the copied link above);
- Go to Surveys / Participations;
- Enter the record of your test (`Contact` field should match Demo's data);
- Open the PDF certification in the chatter.
## Cause:
The company `logo` field is a Binary field related to the partner's `image_1920`.
The retrieval method was changed to access `partner_id.image_1920` directly with `sudo`, since `sudo` does not apply when accessing the related field (`logo`) directly.
However, this change broke the standard certification printing layout, likely due to rendering issues with the direct access method.
## Fix:
Reverts logo access back to the related field `company_id.logo` to restore compatibility with certification printing.
Partial revert of commit 9b4c4ad8d1a238c6f7f4bea52d3f64016a6ff325 as already applied by JKE on Odoo.
Ensures the certification printing is still allowed for other companies' users.
opw-4266445
opw-4657294
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207081
Forward-Port-Of: odoo/odoo#204262### Steps to reproduce: - Accounting > Journals > Bank - Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments" - Create a payment with a partner - Confirm it, its state should be "Paid" - Create an invoice with the same partner and amount - Confirm and click the add button to link the payment - Return on the payment, its state is back to "In Process" ### Cause: This [commit](https://github.com/odoo/odoo/commit/533984ac5c1
Original PR description
### Steps to reproduce: - Accounting > Journals > Bank - Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments" - Create a payment with…
### Steps to reproduce:
- Accounting > Journals > Bank
- Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments"
- Create a payment with a partner
- Confirm it, its state should be "Paid"
- Create an invoice with the same partner and amount
- Confirm and click the add button to link the payment
- Return on the payment, its state is back to "In Process"
### Cause:
This [commit](https://github.com/odoo/odoo/commit/533984ac5c10fbd91742f34b740c63c04fbef094) added the return to the state "In process" when payment are unreconciled. The check is:
`if move.currency_id.is_zero(sum(liquidity.mapped('amount_residual')))`
When setting the journal "Bank" as the outstanding account, the line which appear in `liquidity` has the payment amount in `amount_currency` and `amount_residual`. So the amount is not 0 and the payment state is set back to "In Process".
### Solution:
When the account of the payment does not allow reconciliation, the payment is never supposed to be in the state "In Process". To prevent this, this commit adds a check on `account_id.reconcile`.
opw-4718717
Forward-Port-Of: odoo/odoo#206447To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and f
Original PR description
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and force unarchiving the employee even if it's already active. This commit ensure that unarchiving an already active employee does not create duplicate *future* public holidays. opw-4134712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207243 Forward-Port-Of: odoo/odoo#206997
Previously, an inline search was used to fetch the production location. If no production location existed for the company,a SQL constraint error would occur during warehouse creation due to the missing field default_location_dest_id. This change uses the existing _get_production_location method to raise a clear UserError instead, making the issue easier to understand. I have seen this on several tickets now so this would prevent future tickets from ending up in our pipe as now the user can
Original PR description
Previously, an inline search was used to fetch the production location. If no production location existed for the company,a SQL constraint error would occur during warehouse creation due to the missing field default_location_dest_id. This change uses the existing _get_production_location method to raise a clear UserError instead, making the issue easier to understand. I have seen this on several tickets now so this would prevent future tickets from ending up in our pipe as now the user can just create a production location themselves. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206500
## Issue When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a `KeyError`: ```python File "/home/odoo/src/odoo/18.0/addons/hr_calendar/models/res_partner.py", line 78, in _get_schedule calendar_interval = interval_by_calendar[calendar][employee.resource_id.id] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: <numbe
Original PR description
## Issue When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a…
## Issue
When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a `KeyError`:
```python
File "/home/odoo/src/odoo/18.0/addons/hr_calendar/models/res_partner.py", line 78, in _get_schedule
calendar_interval = interval_by_calendar[calendar][employee.resource_id.id]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: <number>
```
## Root Cause
Odoo uses the Standard 40 hours/week calendar (resource.resource_calendar_std) as a fallback for flexible (unset) calendars. However, when grouping resources by their calendars, resources without a calendar are included in a separate group.
Later, when Odoo computes work intervals per calendar, it assigns the default calendar to resource.resource(). If another user already uses the same calendar, the group duplication results in one being overwritten during iteration—causing the KeyError.
## Fix
Before grouping resources by calendar, explicitly assign the default calendar (resource.resource_calendar_std) to any resource that lacks a calendar. This ensures all resources are grouped correctly, avoiding duplication and key errors.
## Impacted versions:
18.0 and later
## Steps to Reproduce
### Pre-requisites:
- Install `hr_contract`, `calendar` apps.
### Steps:
1. Create **Employee 1**:
- Set **Working hours** to **Flexible** (unset)
- Create a **Contract**:
- Set **Working hours** to **Flexible** (unset)
2. Create **Employee 2**:
- Set **Working hours** to **Standard 40 hours/week**
- Create a **Contract**:
- Set **Working hours** to **Standard 40 hours/week**
- Ensure the XML ID is `resource.resource_calendar_std`
3. Open the **Calendar** app.
4. Create a **new Event**.
5. Add both employees as **attendees**.
## Current Behavior
The system raises a `KeyError` and does not allow the event to be saved.
## Expected Behavior
The event is saved successfully with both attendees.
### Task
OPW-[4699028](https://www.odoo.com/odoo/my-tasks/4699028)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206993
Forward-Port-Of: odoo/odoo#205266Prior to this commit, refreshing the PoS caused the category order to default to ID-based sorting from IndexedDB. This commit fixes the issue by sorting categories based on their sequence. opw-4725408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206226
Original PR description
Prior to this commit, refreshing the PoS caused the category order to default to ID-based sorting from IndexedDB. This commit fixes the issue by sorting categories based on their sequence. opw-4725408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206226
Before this commit, validating an order that belonged to a different PoS configuration could result in an error if the selected payment method was not available in the current configuration. This prevented the order from being successfully validated. opw-4687658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204809
Original PR description
Before this commit, validating an order that belonged to a different PoS configuration could result in an error if the selected payment method was not available in the current configuration. This prevented the order from being successfully validated. opw-4687658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204809
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses. This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed. To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields link
Original PR description
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added…
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses. This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed. To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields linked to customers. In the case of the above models, we don't want to send a message to all the attendees (they were stored in partner_ids which is the default field read). Thus by returning an empty list we block the computation of suggested_recipients and default_recipients. Letting full control to the user sending the email which people to notify. task-4736015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206958 Forward-Port-Of: odoo/odoo#206474
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for
Original PR description
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for searching by Name. Task - 4574162 Forward-Port-Of: odoo/odoo#207033 Forward-Port-Of: odoo/odoo#198461
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. Thi
Original PR description
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. This fix makes sure that it is sent as "cancellation" (Storno) in that case. task - 4707254 Forward-Port-Of: odoo/odoo#205390
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the
Original PR description
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details:…
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report. The issue lies in the multiple cross report references from modelo 303 to modelo 390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong. A future PR for master will fix the report by splitting all the tags used for the two reports. In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification. Forward-Port-Of: odoo/odoo#205860
Currently we block the push propagation when a move reach its final location. However it causes issue on some cases and it's not really helpful. E.g.of blocked flow - Special location in customer zone. - PO (set the final loc to stock). Arrived in stock don't push to wanted location Forward-Port-Of: odoo/odoo#206826
Original PR description
Currently we block the push propagation when a move reach its final location. However it causes issue on some cases and it's not really helpful. E.g.of blocked flow - Special location in customer zone. - PO (set the final loc to stock). Arrived in stock don't push to wanted location Forward-Port-Of: odoo/odoo#206826
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties
Original PR description
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties values again. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3#diff-89ec9296feb48614f91829b8b732dca614359831967fa65a2126d6fe68c84450 Forward-Port-Of: odoo/odoo#207061 Forward-Port-Of: odoo/odoo#206824