Daily updates from Odoo
Friday, April 25, 2025
104 changes
1 change
Miscellaneous changes
This pull request prepares the Enterprise codebase for the SaaS 18.3 release. It appears to be a release housekeeping change rather than a specific business feature, helping align the branch with the new version milestone.
49 changes
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
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
24 changes
Enhancements to existing features
The bank reconciliation selection and creation dialog is now displayed in a larger size. This gives users more room to review search results and related details, making reconciliation workflows easier to navigate.
Original PR description
This commit will increase the size of the BankRecSelectCreateDialog to xl. no task id
Several apps have been reassigned to more appropriate categories so they are easier to find in the Apps search experience. This improves browsing and discovery without changing the underlying app features or workflows.
Original PR description
Clean-up the Apps search bar by setting the modules in the right categories. Task-4592952
The Documents app will no longer create email aliases for individual binary or request documents, since aliases are only needed on folders. This reduces unnecessary setup and keeps document management simpler without changing normal folder-based workflows.
Original PR description
We only need them on folders. Task-4750330
The VoIP app no longer shows a notification when a call is being initiated. This removes a redundant alert, making the calling experience cleaner and less distracting for users.
Original PR description
This commit removes the "calling" notification that appears when a call is initiated. It turns out that it's useless and not needed anymore.
Resolved issues and error corrections
Updated internal tests so fleet-related expense checks run with the right permissions. This helps prevent false test failures and keeps accounting and fleet expense features reliable during development.
Original PR description
Creating fleet objects requires being a fleet administrator or sudo. However because copying fleet objects (specifically vehicles) as well as posting moves *also* requires those rights, using sudo requires about 20 changes throughout the setup and tests. Maybe fleet will eventually want some more specificity in their test ACL management, but just setting the current user as fleet admin seems to do a good job while avoiding most of the mess. https://runbot.odoo.com/odoo/error/163135 https://runbot.odoo.com/odoo/error/181531
The Documents accounting action now uses the correct label, "Create Vendor Credit Note," instead of "Create Vendor Refund." This avoids customer confusion and keeps the wording consistent with the accounting form that opens from the button.
Original PR description
TLDR: reword "Create Vendor Refund" => "Create Vendor Credit Note" During the refactoring in https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e The enum value of "account.move.in_refund" was used to name the button "Create Vendor Refund" instead of its string "Vendor Credit Note" when converting the action into the new documents actions scheme. This is confusing for customers (since it is not always a refund) and is inconsistent with the rest of the user facing wording (i.e. the form view that opens when the button is clicked on). Reported/noticed during: opw-4488038
Fixed how pivot table date formulas are generated in spreadsheets by removing unnecessary spaces before the day and month values. This helps dates display and calculate consistently when users work with spreadsheet pivots.
Original PR description
Removed extra spaces in front of the day and month in DATE function. Task: 4725023
The Planning list view now keeps planned date fields more compact when edited, preventing the arrow between start and end times from appearing out of line. This improves visual consistency and makes the schedule easier to read for users working in list view.
Original PR description
With this commit ============= In the Planning module, the Planned Date field in the list view was visually misaligned when edited. The arrow (->) between the start and end times would appear off-center compared to other rows. Previously, the field had a width of 425px. This commit reduces the width to 325px to keep the input field more compact and ensure the arrow and date values remain visually aligned across all rows in both view and edit modes. Steps to Reproduce: 1. Go to Planning. 2. Switch to list view. 3. Click to edit the Planned Date field. 4. Observe that the arrow is vertically misaligned due to the input's size. This fix improves visual consistency in the list view by constraining the field's width. Task: 4607249
Code cleanup and technical improvements
Device handling for Point of Sale hardware is being moved from the enterprise-only IoT area into the main Point of Sale application. This makes the underlying capability available more broadly now that the required communication feature is no longer limited to enterprise users.
Original PR description
The `deviceController` object was only defined in the `pos_iot` module, as longpolling was only available for enterprise users. Now that it is available to everyone, we moved it to the PoS module. Community PR: [https://github.com/odoo/odoo/pull/207203](https://github.com/odoo/odoo/pull/207203) Task: 4394403
Miscellaneous changes
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
**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the
Original PR description
**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem…
**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the source location will be WH/stock and the client will not be able to change that because the field does not appear. **Steps to reproduce:** - From the inventory app dashboard select "internal transfer" - Create a new internal transfer - Enter a storable product - Set a demand quantity - Click on "Mark as Todo" - Open the barcode app - Click on operations - Select "Internal Operations" - Select the transfer you just created - Click on the gear icon on the top right and select "scrap" **Current Behavior:** The source location field is not visible **Expected Behavior:** The source location field should be visible and editable **Cause of the issue:** The source location field is not in the view https://github.com/odoo/enterprise/blob/a9334bb551606d0151d8fc7a8f3393c3a6e312b9/stock_barcode/views/stock_scrap_views.xml#L68 **Fix:** I added the source location field in the view opw-4489401 Forward-Port-Of: odoo/enterprise#83546 Forward-Port-Of: odoo/enterprise#82174
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
**Before this PR:** The Share panel is not accessible to portal users, but the Share button is still visible to them. **After this PR:** The Share button will no longer be visible in the portal view. Task-4717553 Forward-Port-Of: odoo/enterprise#83306
Original PR description
**Before this PR:** The Share panel is not accessible to portal users, but the Share button is still visible to them. **After this PR:** The Share button will no longer be visible in the portal view. Task-4717553 Forward-Port-Of: odoo/enterprise#83306
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#83459 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#83459 Forward-Port-Of: odoo/enterprise#83112
### 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
- 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#83946 Forward-Port-Of: odoo/enterprise#80201
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
…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
In this commit: === - Replaced all occurrences of `TicketScreen.nthRowContains()` with `UrbanPiper.orderHasText()` in test tours. task-4712861 runbot-115061 Forward-Port-Of: odoo/enterprise#83213
Original PR description
In this commit: === - Replaced all occurrences of `TicketScreen.nthRowContains()` with `UrbanPiper.orderHasText()` in test tours. task-4712861 runbot-115061 Forward-Port-Of: odoo/enterprise#83213
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#83638 Forward-Port-Of: odoo/enterprise#83141
Currently, an exception is generated when the system tries to find the 'Out of Contract' work_entry_type after it has been deleted. Steps to Reproduce: 1 - Install hr_payroll module without demo data 2 - Navigate to hr payroll -> configuration -> work entry types 3 - delete the 'Out of contract' work entry type 4 - Navigate to hr payroll -> Contracts -> Contract 5 - Create a contract with an end date previous to the current. 6 - Navigate to hr payroll -> payslips -> To pay 7 - T
Original PR description
Currently, an exception is generated when the system tries to find the 'Out of Contract' work_entry_type after it has been deleted. Steps to Reproduce: 1 - Install hr_payroll module without demo data…
Currently, an exception is generated when the system tries to find the 'Out of Contract' work_entry_type after it has been deleted. Steps to Reproduce: 1 - Install hr_payroll module without demo data 2 - Navigate to hr payroll -> configuration -> work entry types 3 - delete the 'Out of contract' work entry type 4 - Navigate to hr payroll -> Contracts -> Contract 5 - Create a contract with an end date previous to the current. 6 - Navigate to hr payroll -> payslips -> To pay 7 - Try to create Payslips To Pay for created contract 8 - an error occurs Error: ```ValueError External ID not found in the system: hr_payroll.hr_work_entry_type_out_of_contract ``` This issue[1] occurs because when the system tries to reference the missing 'Out of Contract' work entry type it results in a ValueError due to a missing required record. The same issue [2] occurs in the `l10n_hk_hr_payroll` module. [1] - https://github.com/odoo/enterprise/blob/265177dfd281f3aa1d61db6587ddfa37790570fe/hr_payroll/models/hr_payslip.py#L597 [2] -https://github.com/odoo/enterprise/blob/31e56779f8e0011ddc5c1a2821f68c8f041efbe4/l10n_hk_hr_payroll/models/hr_payslip.py#L180 This fix resolves the issue by ensuring that if the `Out of Contract` work entry type is missing, it returns a false value. A similar fix has been applied in `l10n_hk_hr_payroll`. Additionally, code has been added to prevent the deletion of any work entry type using @api.ondelete. sentry-6277939517 Forward-Port-Of: odoo/enterprise#82659 Forward-Port-Of: odoo/enterprise#79053
When the operations type task was merged, the latest translations change was not properly committed. So commit 32e0364 is missing the correct translations for the last minute changes that occured. This commit corrects that issue. task-4569548
Original PR description
When the operations type task was merged, the latest translations change was not properly committed. So commit 32e0364 is missing the correct translations for the last minute changes that occured. This commit corrects that issue. task-4569548
When opening settings as a user with only access to settings results in a crash because the user does not have access to 'Journal'. Covered by `test_settings_access` in base when installing "test_full_discuss". The solution is simply to query for the default journal using sudo. Forward-Port-Of: odoo/enterprise#83715
Original PR description
When opening settings as a user with only access to settings results in a crash because the user does not have access to 'Journal'. Covered by `test_settings_access` in base when installing "test_full_discuss". The solution is simply to query for the default journal using sudo. Forward-Port-Of: odoo/enterprise#83715
26 changes
Enhancements to existing features
This update adds clearer guidance for developers working with certificate and key records, making future maintenance easier. It also adds extra checks to make certificate handling more robust and less prone to errors.
Original PR description
The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods. Furthermore, a few more checks and robustness were added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes the displayed image for the Cofidis payment method. It ensures customers and staff see the correct branding during payment setup or checkout, avoiding confusion from an incorrect logo.
Original PR description
It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes automated checks for the restaurant point-of-sale wait until the floor plan is fully loaded before continuing. It helps prevent false test failures and supports more stable quality validation without changing day-to-day user workflows.
Original PR description
- SaveLastPreparationChangesTour To fix the error, add the three last steps to ensure floor plan is well rendered before close the browser. runbot-error-id~114344 - FinishResidualOrder Wait the screen floor is completely loaded before clicking on table 5 or the order can sometimes not be well loaded. runbot-error-id~161595 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
The HTML editor now removes unused bold, italic, underline, or strikethrough formatting markers when users move the cursor away. This prevents future text from unexpectedly inheriting formatting, making document editing more predictable.
Original PR description
**Behavior before this PR:** - Create a bold or italic tag using keyboard when selection is collapsed, leave it empty. - Change selection using arrow key. - Put cursor back where format tag was created. Notice that empty element is not removed and text is formatted when writing something. **Behavior after PR is merged:** - This PR makes sure that empty format element gets removed when changing selection. - Tag will not get removed if it's parent block element is empty. task-4240818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes two restaurant point of sale test flows wait until the floor plan and related loading steps are fully ready before continuing. It reduces false test failures and helps keep restaurant POS quality checks stable without changing day-to-day user behavior.
Original PR description
- SaveLastPreparationChangesTour To fix the error, add a step Chrome.waitRequest() to wait the loader that can appears when time to load is too long. runbot-error-id~114344 - FinishResidualOrder Wait the screen floor is completely loaded before clicking on table 5 or the order can sometimes not be well loaded. runbot-error-id~161595 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how tab spacing behaves in the HTML editor when used around text with a background color. Tabs inserted at the start of highlighted text no longer incorrectly inherit the background, while tabs inserted within or after the text still match the surrounding formatting.
Original PR description
**Current behaviour before PR:** When there is a text having background color, inserting a tab at the beginning of text creates a tab with background color. **Desired behaviour after PR is merged:** Now, if there is a text having background color, - Inserting tab at the beginning of text, tab will not have background color. - Inserting tab in the middle of a text, tab will have a background color corresponding to the text. - Inserting tab in the end of text, tab will have a background color corresponding to the text. task-4381135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where very long blog or portal pages with comments could show a grey, unusable comment box over the page content. The hidden helper field used to size the real comment box is now kept fully out of sight, improving the visitor experience.
Original PR description
Scenario: create a long blog page article and enable comments Result: there is a grey unusable textarea with o-mail-Composer-fake over the blog content. Issue: in 7710c3331ebd22f8396870bd0731f8c1152d9c41 the fake textarea used to compute the height of the real textarea, had a position of -10000px, which make sense in the backend to make it hidden. But in 18.0 with 368eb78a9cedfce0802b64fd2782e1c018541e40 we use the backend composer on portal, where a page could be higher than 10000px and the fake textarea can be shown. Fix: hide it better (also to the left, and in case there was a 10000x10000 pixels page with comment at the bottom right, make it invisible). opw-4719975
Fixed an issue where product or picking descriptions could be missing from Chilean electronic delivery guides. The document now uses the line’s picking description, making delivery guide details clearer and preserving expected behavior.
Original PR description
When generating a 'Delivery Guide SII DTE 52 (CL)' the picking description was not always displayed. Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * In Sales app, make a new quotation * Add a product and confirm * Click on the Delivery smart button * Click on the gear icon > Print > Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ We now use the picking description of the line, which inherits from the product's picking description. This improves clarity, makes the line's description more useful, and preserves the original behavior. Enterprise pr: https://github.com/odoo/enterprise/pull/81920 opw-4596901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Chilean electronic delivery guide now reliably shows the product or picking line description when printed. This helps users and customers understand delivered items more clearly while preserving the existing document flow.
Original PR description
When generating a 'Delivery Guide SII DTE 52 (CL)' the picking description was not always displayed. Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * In Sales app, make a new quotation * Add a product and confirm * Click on the Delivery smart button * Click on the gear icon > Print > Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ We now use the picking description of the line, which inherits from the product's picking description. This improves clarity, makes the line's description more useful, and preserves the original behavior. Community pr: https://github.com/odoo/odoo/pull/204764 opw-4596901
Miscellaneous changes
Problem --------- SPV requires the CIUS-RO xml. However, when selecting the "sending to SPV" uniquely in the move send wizard, it fails becuase it's missing the XML. Solution --------- When sending to SPV, generate the XML by default instead of doing nothing if it's not present. task-4720583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207194 Forward-Port-Of: odoo/odoo#206828
Original PR description
Problem --------- SPV requires the CIUS-RO xml. However, when selecting the "sending to SPV" uniquely in the move send wizard, it fails becuase it's missing the XML. Solution --------- When sending to SPV, generate the XML by default instead of doing nothing if it's not present. task-4720583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207194 Forward-Port-Of: odoo/odoo#206828
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#205593
Original PR description
In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#205593
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
Steps to reproduce the bug: - Create a service product “S1” - Create a repair order: - In the parts: - Click on the catalog Problem: You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only: https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48 opw-4687472 Forward-Port-Of: odoo/odoo#204527
Original PR description
Steps to reproduce the bug:
- Create a service product “S1”
- Create a repair order:
- In the parts: - Click on the catalog
Problem:
You can select a service product, whereas the products in the repair parts should be restricted to consumable-type products only:
https://github.com/odoo/odoo/blob/f2923dec56b5ba2436bc244337c1e430a85e7e94/addons/stock/models/stock_move.py#L45-L48
opw-4687472
Forward-Port-Of: odoo/odoo#204527Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.). To works, this domain needs dynamic elements, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/a
Original PR description
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic…
Similar to: https://github.com/odoo/odoo/pull/184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
This commit handles:
- website/model_page.py:
-
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L47-L57
The enterprise commit (https://github.com/odoo/enterprise/pull/82564)
handles two other cases:
- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2
- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`
In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in et la the python server
- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)
- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`
- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
-- context_today()
-- relative_delta()
-- datetime
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
Forward-Port-Of: odoo/odoo#206507
Forward-Port-Of: odoo/odoo#204172When 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
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
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
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
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
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
### 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
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
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
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP. ### Steps to reproduce: - Install UK accounting and select UK's company: the currency will be GBP - Install and set up Fedex Integration - Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type - Create a sale order,
Original PR description
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose…
### Issue: Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP. ### Steps to reproduce: - Install UK accounting and select UK's company: the currency will be GBP - Install and set up Fedex Integration - Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type - Create a sale order, add shipping and get the shipping rate for your set up fedex UK. #### > Fedex request error: `CURRENCY.TYPE.INVALID` ### Cause of the issue: The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error. ### Fix: We should use the currency conversion available between GBP and UKL. opw-4712354 Forward-Port-Of: odoo/enterprise#83388
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.). To works, this domain needs dynamic elements, such as `context_today`, which is defined in `py_builtin.js` and dynamically retrieves the current date. https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py
Original PR description
Similar to: https://github.com/odoo/odoo/pull/184830 We've recently introduced a new operator: “is within” in the domain selector, which can be used to find out whether a date is within a dynamic…
Similar to: https://github.com/odoo/odoo/pull/184830
We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.
https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79
However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s
In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:
`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.
The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50
This commit
handles two other cases:
- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2
- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`
In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:
- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server
- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)
- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`
- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
- context_today()
- relative_delta()
- datetime
- time
opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091
community: https://github.com/odoo/odoo/pull/204172
Forward-Port-Of: odoo/enterprise#83635
Forward-Port-Of: odoo/enterprise#82564Forward-Port-Of: odoo/enterprise#83992
Original PR description
Forward-Port-Of: odoo/enterprise#83992