Tuesday, November 4, 2025
32 changes · saas-18.3
Resolved issues and error corrections
This change updates Indian tax handling so the GST Treatment is taken from Partner Autocomplete data instead of defaulting to Regular in vendor bill scans and IRN bill fetching. This helps ensure incoming bills are classified more accurately with less manual correction.
Original PR description
Before this commit: We used to set `regular` treatment when using QR Vendor Scan or Fetching bill with IRN After this commit: We use the GST Treatment received from Partner Autocomplete to set the GST Treatment task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234136
This change helps the system notice broken browser connections much sooner when the network is slow or unstable. As a result, users are less likely to wait silently for updates that will never arrive, improving reliability of live communication.
Original PR description
When a TCP connection is not closed cleanly, it can take minutes to detect a closed WebSocket connection. During this time, no messages are received. This can happen in slow or unstable network conditions. Browsers do not expose WebSocket ping/pong mechanisms. To detect dead connections quickly, periodic application level messages are sent if no messages were either sent or received within a minute. This approach ensures quicker detection compared to relying on the OS TCP timeout, which is typically set to a high value. X-original-commit: d043e12 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how Chilean states are identified in customer addresses. The state codes now follow the official ISO standard, which helps ensure addresses display correctly and stay consistent across the system.
Original PR description
**Steps to reproduce:** 1. Go to Sales > Create and edit a new customer. 2. Select Chile as the country and choose a state. **Issue:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Cause**: - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. <img width="601" height="146" alt="image" src="https://github.com/user-attachments/assets/a941c200-467b-4ad5-8f79-ca9e8a92d7b4" /> <img width="443" height="131" alt="image" src="https://github.com/user-attachments/assets/dc1df1b0-2267-499f-ad1d-bb5c9381cd66" /> **Solution**: - Updated all state codes to match the official ISO 3166-2:IQ codes (Reference: https://www.iso.org/obp/ui/#iso:code:3166:CL) **opw-5148562** Forward-Port-Of: odoo/odoo#230963
This change helps the system notice lost browser connections much sooner when the network is slow or unstable. As a result, users are less likely to experience long periods where messages stop arriving without warning.
Original PR description
When a TCP connection is not closed cleanly, it can take minutes to detect a closed WebSocket connection. During this time, no messages are received. This can happen in slow or unstable network conditions. Browsers do not expose WebSocket ping/pong mechanisms. To detect dead connections quickly, periodic application level messages are sent if no messages were either sent or received within a minute. This approach ensures quicker detection compared to relying on the OS TCP timeout, which is typically set to a high value. X-original-commit: d043e12 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how Swedish bank account numbers are identified during export. It fixes several valid account formats that were previously rejected, helping businesses avoid incorrect bank type labels and export issues.
Original PR description
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the…
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the 'Accounting' page create a new bank account 1- 62074-0 2- 678653833066 3- 99603406872188 - In the partner list view select this new partner - Click Actions > Export, select "Banks" and "Bank Type" - Check the file 1- 62074-0 not recognized as Plusgiro 2- 678653833066 not recognized as BBAN 3- 99603406872188 not recognized as BBAN ### Cause: These numbers are not recognized by the checks of Odoo but are valid numbers: 1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers 2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers 3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969 ### Sources: 1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15 opw-5099867 Forward-Port-Of: odoo/enterprise#98147
This update fixes an error that could appear on the information page of appointments limited to work hours when the assigned staff member uses flexible hours. It ensures the system no longer treats flexible-hours staff as if their availability should be calculated from a fixed work schedule, preventing confusing 404 pages for users.
Original PR description
This PR fixes the 404 error displayed on the info page of a "Limit to Work Hours" appointment linked to a staff user with flexible hours. The availability of the staff user must not be computed from its work schedules as it has flexible hours. Task-5046134 Forward-Port-Of: odoo/enterprise#95336
This update ensures that when a component line is removed in the subcontracting wizard, it is fully deleted instead of დარჩing behind as an invisible record. This prevents confusing leftover entries in inventory reports and keeps stock records accurate.
Original PR description
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add…
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add one of each component in subcontractor's stock - Create a PO for the finished product and confirm it - Go to the production - Open the "Record components" wizard - Set quantity then remove the second line - Confirm production (don't update consumption) - Go to Inventory > Reporting > Moves History and remove the "Done" filter > There is a pending move in the report Cause ----- When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46 The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do `move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])` we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db. https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322 We cannot change the field to `ondelete='cascade'` as such a change would not be stable. Solution ----- Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated. ----- Ticket: opw-4817397 Forward-Port-Of: odoo/odoo#233626 Forward-Port-Of: odoo/odoo#229310
This change fixes a bug that could cause upgrade steps to run in different orders from one run to another. By keeping the order consistent, it reduces the risk of unpredictable upgrade behavior when multiple version-specific scripts are present.
Original PR description
When we list the versions to upgrade we go over the values in `self.migrations[pkg.name]`. This object is a mapping of mappings `{script_location: {version: scripts_list}}`. The location could be `module` or `module_upgrades` for local scripts, or `upgrade` for scripts in any of the extra upgrade paths.
The problem is that if we have a minor version that matches a major one in different locations the order is non-deterministic. For example if we have a local upgrade script in `1.2`, and an extra upgrade script in `16.0.1.2`. Both `version` keys (`1.2` and `16.0.1.2`) will resolve to `16.0.1.2` when ordering. But the order they _actually_ appear in the set of versions is non-deterministic --due to the `set` implementation in Python.
The solution is to use a container that keeps the order, in this case a `dict`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234124This update corrects how overtime one-time payments are handled in the Swiss payroll transmission flow. It helps ensure these payments are reported properly, reducing the risk of payroll data errors and follow-up corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#98670
When users adjust a production step after a partial manufacturing order creates a backorder, the system now shows the correct quantity for that specific step. This avoids confusion and helps shop floor users register the right amount of work on each operation.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#97983 Forward-Port-Of: odoo/enterprise#93599
This change ensures default values for mocked fields are kept when test models are extended. As a result, timestamps like creation and update dates are applied correctly in automated tests, making them more reliable.
Original PR description
Before this commit, default values in mock fields defined by functions would be lost when extending a model, because by doing so the fields were JSON-copied and the default functions were lost. To fix this, this commit introduces another way to copy field definitions that preserves functions, allowing default values (typically for the 'create_date' and 'write_date' fields) to be applied correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234106
Datetime fields now show the proper AM/PM marker in Arabic, so afternoon and evening times are no longer displayed ambiguously. This prevents saved times from being read back incorrectly and changing from PM to AM when users edit them again.
Original PR description
When the database language is set to Arabic, all datetime fields across the system incorrectly displayed PM (afternoon/evening) times without the Arabic meridiem marker (م), causing times to appear…
When the database language is set to Arabic, all datetime fields across
the system incorrectly displayed PM (afternoon/evening) times without
the Arabic meridiem marker (م), causing times to appear ambiguous and
be parsed incorrectly as AM times when re-read from the input.
Issue:
------
- Switch to Arabic Language
- Enter 11:00 PM in any datetime field (attendance, calendar, etc.)
- System correctly stores it as 23:00 (hour 23 in 24-hour format)
- When displaying back to the user, the formatter uses shortTimeFormat
which is configured as "hh:mm" (without the 'a' meridiem token)
- Display shows: "١١:٠٠" (11:00 with no م marker)
- When the field loses focus, parseDateTime tries to parse using format
"hh:mm:ss a" (expects meridiem marker)
- Since no marker is present, Luxon defaults to AM
- Time gets changed from 23:00 (11 PM) to 11:00 (11 AM)
Root Cause:
-----------
The formatDateTime function uses different time formats depending on
whether seconds should be displayed:
- When showSeconds = false: uses localization.shortTimeFormat ("hh:mm")
- When showSeconds = true: uses localization.dateTimeFormat (...hh:mm:ss a)
The shortTimeFormat is missing the 'a' token for meridiem marker, but
the parser always expects it when timeFormat includes 'a'. This creates
a mismatch between formatting and parsing.
Solution:
---------
Modified formatDateTime() to detect when shortTimeFormat uses 12-hour
format (h/hh tokens) but is missing the meridiem marker ('a' token).
In such cases, append ' a' to the format string before formatting.
This ensures 12-hour times include the meridiem marker which Luxon
correctly outputs for each locale (م for PM in Arabic, PM in English),
making times unambiguous and allowing them to be parsed correctly.
The fix only affects 12-hour formats missing the meridiem marker, and
does not modify 24-hour formats (H/HH tokens), preserving existing
behavior for formats that intentionally use 24-hour display.
opw-5137828Datetime fields now display the Arabic meridiem marker for afternoon and evening times when needed. This prevents 11 PM values from being shown as plain 11:00 and then being misread as 11 AM when edited again.
Original PR description
When the database language is set to Arabic, all datetime fields across the system incorrectly displayed PM (afternoon/evening) times without the Arabic meridiem marker (م), causing times to appear…
When the database language is set to Arabic, all datetime fields across the system incorrectly displayed PM (afternoon/evening) times without the Arabic meridiem marker (م), causing times to appear ambiguous and be parsed incorrectly as AM times when re-read from the input.
Issue:
------
- Switch to Arabic Language
- Enter 11:00 PM in any datetime field (attendance, calendar, etc.)
- System correctly stores it as 23:00 (hour 23 in 24-hour format)
- When displaying back to the user, the formatter uses shortTimeFormat which is configured as "hh:mm" (without the 'a' meridiem token)
- Display shows: "١١:٠٠" (11:00 with no م marker)
- When the field loses focus, parseDateTime tries to parse using format "hh:mm:ss a" (expects meridiem marker)
- Since no marker is present, Luxon defaults to AM
- Time gets changed from 23:00 (11 PM) to 11:00 (11 AM)
Root Cause:
-----------
The formatDateTime function uses different time formats depending on whether seconds should be displayed:
- When showSeconds = false: uses localization.shortTimeFormat ("hh:mm")
- When showSeconds = true: uses localization.dateTimeFormat (...hh:mm:ss a)
The shortTimeFormat is missing the 'a' token for meridiem marker, but the parser always expects it when timeFormat includes 'a'. This creates a mismatch between formatting and parsing.
Solution:
---------
Modified formatDateTime() to detect when shortTimeFormat uses 12-hour format (h/hh tokens) but is missing the meridiem marker ('a' token). In such cases, append ' a' to the format string before formatting.
This ensures 12-hour times include the meridiem marker which Luxon correctly outputs for each locale (م for PM in Arabic, PM in English), making times unambiguous and allowing them to be parsed correctly.
The fix only affects 12-hour formats missing the meridiem marker, and does not modify 24-hour formats (H/HH tokens), preserving existing behavior for formats that intentionally use 24-hour display.
opw-5137828This update fixes a failing rental test that depended on demo accounting and stock settings. It now runs correctly in clean environments, which helps keep automated testing reliable and prevents false failures during builds.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#97935 Forward-Port-Of: odoo/enterprise#92292
This fix makes placeholder text visible again when users open a document to sign and a selection field has been configured. It improves clarity for signers and helps prevent confusion when completing documents.
Original PR description
To reproduce: ============= - upload a document to sign and add a selection field on it - set a placeholder for the selection field - open the document to sign -> the placeholder is not displayed Problem: ======== the placeholder is not displayed because there is no option holding the placeholder value. Solution: ========= Add an option at the beginning of the select options to hold the placeholder value. opw-5140676 Forward-Port-Of: odoo/enterprise#97887
This update prevents a stopped ringtone from starting again when someone presses the play/pause key on their headset or keyboard. It helps avoid unexpected sound after a call has already ended, improving the user experience and preventing confusion.
Original PR description
Before this commit, users can resume "stopped" ringtones by pressing the Media Play/Pause key of their keyboard/headphones, even after the call has ended. After this commit, stopping the ringtone clears the audio source, effectively preventing it from being resumed. Task-5222704 opw-5186087 Forward-Port-Of: odoo/enterprise#98660
This update makes the website shop tests more reliable when removing a product’s main image. It ensures the test waits until the image save is fully complete, preventing occasional false failures, and simplifies how test images are loaded to avoid slow redirects.
Original PR description
Versions -------- 18.0+ Issue ----- The `test_website_sale_add_and_remove_main_product_image_no_variant` and `test_website_sale_remove_main_product_image_with_variant` tours fail because the main…
Versions -------- 18.0+ Issue ----- The `test_website_sale_add_and_remove_main_product_image_no_variant` and `test_website_sale_remove_main_product_image_with_variant` tours fail because the main product image is not removed as expected after the tour completes. Cause ----- Both tours assume that once the product `<img>` element is removed from the DOM, the action is fully completed. The tour then ends, and the remaining Python code verifies the result. However, this assumption can lead to issues. If the save request takes longer than expected, the Python code may execute prematurely and fail. Solution -------- Add a step at the end of both tours to wait for the `<img>` element to be fully saved and updated in the preview DOM. Additionally, during debugging, it was observed that using an alias URL (i.e., a redirect) to an `ir.attachment` could introduce further issues or slow down the test due to the server fetching the image with a remote call. To address this, this commit replaces the alias URL with a simple binary attachment. opw-5159593 runbot-163025 runbot-163615 Forward-Port-Of: odoo/odoo#233978
This change ensures delivery fees on subscription invoices are not reduced when a prorated invoice is created. It matters because shipping charges should remain a fixed cost, even when the rest of the subscription amount is adjusted for the billing period.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188 Forward-Port-Of: odoo/enterprise#98622 Forward-Port-Of: odoo/enterprise#91133
The website loading progress bar now uses the primary brand color instead of black. This makes it easier to see in dark mode and creates a more consistent look across the website.
Original PR description
This commits changes the website loader progress bar color, from black to `$primary`. This provides a better contrast in dark mode as well as better consistency. task-5170115 | Before | After | |--------|--------| | <img width="1920" height="1186" alt="image" src="https://github.com/user-attachments/assets/cd9525cf-b9d6-40dd-9ffb-ed0027020ab5" /> | <img width="1920" height="1172" alt="image" src="https://github.com/user-attachments/assets/3f7d9a4b-4a3e-4fbd-a1be-826c898466cd" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232875
This update makes the wishlist test flow more reliable by adjusting the order of steps so the wishlist count has time to refresh. It also ensures the wishlist starts empty before the tour continues, reducing random test failures without changing customer-facing features.
Original PR description
Modify the steps order to make sure the wishlist quanity has enough time to get updated runbot-229616 Forward-Port-Of: odoo/odoo#233998
The website now uses the standard redirect utility when sending users to a URL after a rental search action. This makes navigation more reliable and reduces the chance of redirect issues on rental-related pages.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/233842 Forward-Port-Of: odoo/enterprise#98686 Forward-Port-Of: odoo/enterprise#98492
Customers can no longer cancel a self-order once it has been sent to the kitchen display. This avoids mismatches between the backend and the kitchen screen and ensures cancellations follow the proper in-store process.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Community: https://github.com/odoo/odoo/pull/229039 Forward-Port-Of: odoo/enterprise#95770
This update fixes how customers are sent to the correct page after certain webshop actions, such as cart updates, product options, wishlist actions, and reorder flows. It helps ensure users consistently land on the intended URL instead of seeing broken or unexpected navigation.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/98492 Forward-Port-Of: odoo/odoo#234164 Forward-Port-Of: odoo/odoo#233842
Customers can no longer cancel a self-order once it has been sent to the kitchen display. This avoids situations where the order is removed in the system but the kitchen is never informed, helping staff keep orders consistent and reducing confusion.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Enterprise: https://github.com/odoo/enterprise/pull/95770 Forward-Port-Of: odoo/odoo#229039
When a user changes the product on a scrap order, the related Bill of Materials is now refreshed automatically. This prevents the scrap quantity from being reset incorrectly and avoids mismatches between what users see and what is actually processed.
Original PR description
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the…
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency. Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM. Steps to Reproduce on Runbot: 1. Create a scrap order for a product that has a kit type BoM and set the kit field. 2. Change the product to a product without a kit type BoM. 3. Validate the scrap order. 4. Observe the quantity field is set to 0, but there are product moves for the correct quantity. opw-5122880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234050 Forward-Port-Of: odoo/odoo#231937
This fix prevents the system from trying to clean reservations for kit products in situations where that can trigger an error. As a result, users can open and manage inventory quantities normally without being blocked by this issue.
Original PR description
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on…
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”. However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant. Solution: For kits, we can skip cleaning their quant to avoid unnecessary errors. This is a manual forward-port of #200595 opw-4625002 opw-4624008 opw-4621175 opw-4625465 opw-4621504 opw-4623523 opw-4621508 opw-4623329 opw-4629386 opw-5179369
The chat bubbles on mobile now stay in place when tapped instead of briefly moving down. This makes the chat experience smoother and avoids a distracting visual jump in Discuss and on website pages.
Original PR description
**Description of the issue/feature this PR addresses:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily **Current behavior before PR:** when clicking on chat…
**Description of the issue/feature this PR addresses:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily **Current behavior before PR:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily. this happens because in some contexts, the chat hub bubbles are lift up, like in discuss app and at bottom of website page. This was done with a `transform: translateY()` but when the button was being clicked the chat bubble temporarily resets its unlifted position, as if no `transform: translateY()` was in effect. **Desired behavior after PR is merged:** This fixes the issue by using `bottom` CSS style rule. Chat hub bubbles part has a bottom value, the lift up is now designed to combine with the static bottom value, thus bubbles part stay at the desired position even when being clicked. Backport of #225757 task-[4914438](https://www.odoo.com/odoo/project/1519/tasks/4914438) Before  After  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures customers receive the expected email when an order status update comes back from Gelato. It helps keep buyers informed automatically and reduces missed notifications in the order process.
Original PR description
Fix not sending the email to customer, when order status update was received from Gelato. opw-4962878 Forward-Port-Of: odoo/odoo#233587
This fixes a stock issue where items with a lot or serial number could be incorrectly balanced against an untracked quantity instead of the correct lot. As a result, inventory remained inconsistent after barcode deliveries and later receipts; the correction keeps stock levels tied to the proper lot, which improves traceability and prevents stock mismatches.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C 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#231853
We fixed an issue where checkout could get stuck loading if an external tax check failed during order summary updates. Instead of freezing, the problem is now captured and surfaced so the customer can continue and see a clear message in the next checkout step.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
This change fixes an error in hardware driver certificate checks when comparing certificate expiration dates. It ensures the system uses matching date formats, preventing crashes during certificate validation and keeping connected hardware services working reliably.
Original PR description
Before this commit, datetime.now() was compared to cert.not_valid_after_utc, leading to an error because we compare offset-naive and offset-aware datetimes After this commit, we set an offset-aware datetime.now() if we use not_valid_after_utc Issue introduced in #234005 opw-5237595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an automated stock test that had been passing incorrectly due to a runbot issue, despite underlying code conflicts. Fixing the test helps ensure future changes in stock management are validated properly and reduces the risk of unnoticed regressions.
Original PR description
Due to an issue in the runbot, the test associated with the PR: odoo#229958 passed despite underlying conflicts and the PR was merged. This PR addresses and resolves those issues to ensure the test functions correctly. Impacted versions: - 18.0 - saas-18.2 - saas-18.3 - saas-18.4 19.0 and master are addressed in odoo#230685 to replace `procurement.group` with `stock.rule` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230687