Daily updates from Odoo
Tuesday, November 4, 2025
155 changes
17 changes
Resolved issues and error corrections
This fix makes GST Treatment more accurate when creating or fetching vendor bills through QR scan or IRN import. Instead of defaulting to "regular", Odoo now uses the GST Treatment returned by Partner Autocomplete, which helps reduce manual corrections and improves tax handling consistency.
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 update fixes the way Chilean states are identified in customer addresses. It replaces non-standard numeric codes with the official ISO codes, which helps ensure address data is displayed and handled correctly 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
Withholding invoices now include the VAT percentage correctly in the tax totals. This ensures the VAT amount is shown properly in Nilvera PDFs, avoiding missing or incomplete tax information on customer documents.
Original PR description
Before this commit: For withholding invoices, the VAT percentage was not included inside the <cac:TaxTotals> node, due to this, the VAT amount was not displayed in the PDF in Nilvera. After this commit: The VAT amount is shown correctly in the <cbc:Percent> node inside the <cac:TaxTotals> node and percent amount appears correctly in the PDF. task-5225600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233929
This update improves how ribbons and status bars look in modal forms. It prevents the ribbon from blending into the status bar and keeps the form layout visually cleaner when users scroll inside a pop-up window.
Original PR description
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See…
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See commit: https://github.com/odoo/odoo/commit/1ac2ff5b7dd64ccfe1bfb9c3fb7bb8a758e887d7 However, when a statusbar is present, this rule caused the ribbon to merge into the statusbar, making its display worse. In addition, on scrolling in a modal, the statusbar and the form contents were getting merged. This commit refines : - the selector so that `position: static` is only applied when a modal form has a ribbon but no statusbar. When a statusbar exists, the ribbon remains visually separated from the statusbar. - the statusbar background-color logic so that inside modals it uses the proper `$o-view-background-color`, ensuring a clean separation even on scrolling. task-4873636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232315 Forward-Port-Of: odoo/odoo#226074
This update improves how Swedish bank accounts are identified during export so that several valid account formats are now correctly recognized. As a result, partner bank details are less likely to be mislabeled, which helps avoid errors in payment-related exports.
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 prevents the appointment information page from showing a 404 error when a staff member is set to limit appointments to work hours but uses flexible hours. It improves reliability for customers and staff by ensuring availability is handled correctly in this case.
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 fix ensures upgrade steps are processed in a consistent order every time. It prevents rare cases where the same upgrade could be applied differently depending on how Python happened to store the list, improving reliability during migrations.
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 change fixes an issue in the web test framework where some default field values could be lost when a model was extended. As a result, date-related fields such as creation and update timestamps now behave correctly in 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
This change ensures that emission currency and unit values update correctly when an emission factor is changed. It prevents reports from showing outdated values, improving the accuracy of ESG emissions data.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values. Forward-Port-Of: odoo/enterprise#98724
This update prevents a ringtone from being restarted after it has been stopped, even if a user presses the play/pause key on their headset or keyboard. It helps avoid confusion after calls end by making sure stopped ringtones stay stopped.
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
When users prepare a document for signing, placeholder text for selection fields will now appear correctly. This makes the signing form clearer and helps signers understand what should be entered or selected.
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 fix ensures that when a barcode is scanned in the product view, Odoo uses the complete barcode instead of only part of it. It prevents incorrect search results and makes barcode-based product lookup more reliable for users.
Original PR description
Issue ----- When scanning a barcode in the product view, the search is made using only part of the barcode. Steps to reproduce ----- - Open the product view - Scan a barcode (eg 1234567890) > The search might only contain 12345678, 123456 or actually the full barcode Cause ----- When scanning a barcode, we receive all of the barcode characters followed by newline. When we receive the newline, we select the first item in the dropdown. The problem is that the search input changed but it hasn't been reflected yet in the items (a rendering is scheduled but hasn't been applied to the DOM yet). ----- Ticket: opw-4874425 Forward-Port-Of: odoo/odoo#233245 Forward-Port-Of: odoo/odoo#232270
This update ensures that component lines removed in the subcontracting wizard are fully deleted, instead of staying behind as hidden records. It prevents confusing leftover inventory entries and keeps production and reporting data 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
The website loading progress bar now uses the brand primary color instead of black. This makes it easier to see in dark mode and keeps the interface more consistent with the rest of the website design.
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 change stops users from typing into or moving around decorative page elements like background shapes, filters, and parallax effects. It helps keep page layouts stable and avoids odd visual glitches when editing website content.
Original PR description
WIP
This update fixes an issue where removing a main product image could appear to succeed before the change was fully saved, causing test failures and unreliable behavior. It also simplifies how the test image is loaded, making the process more stable and less prone to delays.
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 update adjusts the order of steps in the website wishlist test so the wishlist count has time to refresh before the tour continues. It helps prevent random test failures and makes the automated checks more stable.
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
20 changes
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
6 changes
Resolved issues and error corrections
The appointment information page will now load correctly when a staff member uses flexible working hours. This prevents a 404 error for “Limit to Work Hours” appointments and ensures customers can view the appointment details without interruption.
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 improves how Odoo identifies certain Swedish bank account numbers when exporting partner bank details. It now correctly recognizes additional valid account formats, helping avoid incorrect bank type classifications in exports.
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 corrects how website sale pages send visitors to another URL after certain actions. It helps ensure customers are taken to the intended page reliably, improving the shopping experience and avoiding broken or inconsistent redirects.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/233842 Forward-Port-Of: odoo/enterprise#98599 Forward-Port-Of: odoo/enterprise#98492
This fix prevents a stopped ringtone from starting again if someone presses the play/pause key on their headset or keyboard after the call has ended. It improves call handling by making sure the ringtone fully stops and does not resume unexpectedly.
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 corrects how overtime one-time payments are handled in Swiss payroll transmission. It helps ensure employees’ overtime compensation is reported and processed accurately, reducing payroll mistakes and follow-up corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#98670
Users with Recruitment Administrator access can now send referral campaigns without needing Employee permissions. This removes an access error that blocked a normal recruitment workflow and makes the feature work as expected for the intended role.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344
Forward-Port-Of: odoo/enterprise#967469 changes
Resolved issues and error corrections
Authorized payroll users can now resend payslips by email without being blocked when the system prepares the secure document link. This ensures employees receive the correct payslip email link while keeping the button limited to users with the proper role.
Original PR description
Hr Payroll users that are meant to be able to use the Resend Payslip by email button do not have enough access right to get the documents token to put into the email "Your Payslip" button. Add a sudo on the payslip to get the document access url after the check of user role has been done. If have the right to use the button, sudo the rest. Task-5049444 Forward-Port-Of: odoo/enterprise#98510 Forward-Port-Of: odoo/enterprise#93420
This fix updates an automated website sale rental test so it matches the pricing produced by the latest default rental dates. It helps keep quality checks reliable and reduces false alerts in the release process, with no expected impact on customers.
Original PR description
runbot-233276 Forward-Port-Of: odoo/enterprise#98591
Fixes a crash that could happen when several project tasks were blocked by the same task and its deadline was changed. Dependency warnings are now calculated per task, helping teams update schedules without interruption.
Original PR description
Currently, an error occurs when computing the dependency warning for tasks. **Error:** ```Expected singleton: project.task(8, 7).``` After [this commit] if task1 depends on task2, if task1's task…
Currently, an error occurs when computing the dependency warning for tasks.
**Error:**
```Expected singleton: project.task(8, 7).```
After [this commit] if task1 depends on task2, if task1's task dependency is False, then the dependency warning for task1 should also be False.
However, when task dependency is enabled and two or more tasks are blocked by a single task, changing the Deadline of the blocking task triggers the computation of the dependency warning for those dependent tasks. During this process, the system attempts to check the task dependency across multiple records, which raises the error at [1].
This commit ensures that, since self may contain multiple tasks, the dependency warning is computed safely for each specific task.
[this commit]: https://github.com/odoo/enterprise/commit/50768627accb9d9767514fda7c6975bf4d8227d3#diff-b4bb763881453b0d69cae371c4c5034f6e199dfaf3a3056aba3381cf64dbf3dc
[1]- https://github.com/odoo/enterprise/blob/769201e22618b6683863f0839d7ad80bea0927cf/project_enterprise/models/project_task.py#L350
sentry-6914184933
Forward-Port-Of: odoo/enterprise#98532When an app icon is customized in Studio using a Font Awesome icon, it now appears correctly in the top navigation bar and mobile sidebar. This improves visual consistency and makes customized apps easier for users to recognize across desktop and mobile.
Original PR description
**Purpose:** Previously, when a user edited an app's icon in Studio and selected a Font Awesome icon instead of an image, the icon was not displayed in the navbar or mobile sidebar. This commit ensures the icon now displays correctly in both locations. task-5085482 Community : https://github.com/odoo/odoo/pull/228966
Odoo now correctly identifies several valid Swedish bank account formats that were previously rejected or misclassified. This helps businesses using Swedish localization avoid incorrect bank type exports and improves payment data accuracy.
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
The French FEC import now uses a valid debit account for rounding entries after the previous account code became an account group. This prevents import issues and helps French accounting data load correctly.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
Appointment pages that limit booking to work hours now load correctly when assigned staff have flexible hours. This prevents customers or users from seeing a 404 error and keeps booking availability accessible for those staff members.
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
Selection fields in Sign documents now correctly show their placeholder text before a signer makes a choice. This helps signers understand what information is expected and avoids confusion during document completion.
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
Marketing automation email templates now include version information for their mailing design blocks. This lets users with older templates update those blocks in the email builder until a fuller upgrade path is available.
Original PR description
Add a `vxml` (xml version) for every `mass_mailing` snippet, so that users with templates using old version of it can choose to update their snippet using the builder. It's the bare minimum in lieu of a proper upgrade (which will come later). task-5134263 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Thomas Josse <thjo@odoo.com> Forward-Port-Of: odoo/enterprise#96082
29 changes
Resolved issues and error corrections
When bills are created from QR vendor scans or IRN invoice fetching, Odoo now uses the GST treatment coming from partner autocomplete instead of defaulting to “regular.” This helps ensure the tax setup matches the partner’s actual status and reduces manual corrections.
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 update corrects how exempt and taxed amounts are placed in Argentina VAT sales CSV files. As a result, taxable operations no longer duplicate values in the exempt column, which helps ensure cleaner reports and successful file uploads.
Original PR description
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the…
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the corresponding handling of exempt and non-exempt balances in the query result processing. These change fixes an issue we encountered when checking the sales CSVs ('Débito' and 'Restitución de débito'). Before this change, the column "Monto Neto Exento o No Gravado" was always filled, even when the operation was not exempt, and in that case it repeated the value of "Monto Neto Gravado".
Here is an example:
<img width="1654" height="187" alt="image" src="https://github.com/user-attachments/assets/578fa197-ab72-4801-b714-9c40ddff4b01" />
The correct behavior should be that for taxed operations, only "Monto Neto Gravado" is filled with the 'balance' value, and for exempt operations only "Monto Neto Exento o No Gravado" should have values.
Here is a screenshot of the 'Debito' CSV after the change:
<img width="1614" height="196" alt="image" src="https://github.com/user-attachments/assets/0a18cbe9-d878-4e37-9bb7-21dc8b5cda72" />
**Summary**
* Changed the column mapping for "Monto Neto Exento o No Gravado" from `balance` to `exempt_balance` in the `columns_map` dictionary in `_vat_simple_build_sale_query`.
* Updated the logic for populating values: added handling for `exempt_balance` and `balance` columns so that only exempt balances are shown in `exempt_balance` and non-exempt balances in `balance`, based on the `is_exempt` flag in the row.
Note: the files created were tested on ARCA environment and they could be uploaded without errors.The label for the company and partner address field used in Saudi e-invoicing has been updated from “Street 2” to “District.” This makes the field’s purpose clearer for users and helps prevent incorrect address entry that could affect invoice compliance.
Original PR description
## Before this commit The `street2` field on `res.company` and `res.partner` was mapped to `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CitySubdivisionName`, but its placeholder displayed `Street 2…`. This caused confusion among users, as they assumed it referred to `cbc:AdditionalStreetName`, leading to incorrect data entry and potential non-compliance. ## After this commit The placeholder of the `street2` field has been changed from `Street 2…` to `District…`, clarifying that this field represents the city subdivision (district or borough) of the Seller/Customer, in line with the Saudi Arabia e-invoicing specification. > Task-4951545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231923 Forward-Port-Of: odoo/odoo#231160
This update improves how ribbons and status bars are displayed in pop-up forms. It prevents the ribbon from blending into the status bar and keeps the form layout cleaner when users scroll inside a modal window.
Original PR description
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See…
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See commit: https://github.com/odoo/odoo/commit/1ac2ff5b7dd64ccfe1bfb9c3fb7bb8a758e887d7 However, when a statusbar is present, this rule caused the ribbon to merge into the statusbar, making its display worse. In addition, on scrolling in a modal, the statusbar and the form contents were getting merged. This commit refines : - the selector so that `position: static` is only applied when a modal form has a ribbon but no statusbar. When a statusbar exists, the ribbon remains visually separated from the statusbar. - the statusbar background-color logic so that inside modals it uses the proper `$o-view-background-color`, ensuring a clean separation even on scrolling. task-4873636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232315 Forward-Port-Of: odoo/odoo#226074
This change prevents a front-end error that could appear when editing a website page while a payment form is present. It makes tooltip cleanup safer so the same element is not processed twice, avoiding interruptions for users working in the website editor.
Original PR description
Following commits odoo/odoo@d37d90891c15b188c2bcb01a51e2ce85cefe287c and odoo/enterprise@901b8eac67324d392ed88997aa9fd1be12dc3752, the tooltip cleanup logic disposes elements in…
Following commits odoo/odoo@d37d90891c15b188c2bcb01a51e2ce85cefe287c and odoo/enterprise@901b8eac67324d392ed88997aa9fd1be12dc3752, the tooltip cleanup logic disposes elements in `website_sale_renting`, and when the same logic runs again
in `payment`, it tries to dispose them a second time, causing
a null element error.
Steps to reproduce:
1. Install `website_sale_renting`
2. Install a demo payment method
3. Go to the shop, add any product to the cart, proceed to payment
4. Click the "Edit" button on the website → observe the error
```js
web.assets_frontend_lazy.min.js:3912 TypeError: Cannot read properties of null (reading 'closest')
at Tooltip.dispose (web.assets_frontend_lazy.min.js:2710:70)
at PaymentForm.<anonymous> (web.assets_frontend_…zy.min.js:8282:1450)
at Colibri.destroyInteraction (web.assets_frontend_lazy.min.js:6472:68)
at Colibri.destroy (web.assets_frontend_lazy.min.js:6524:55)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6584:162)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6625:907)
at stop (website.assets_insid…rame.min.js:137:290)
at HTMLDocument.<anonymous> (website.assets_insid…rame.min.js:153:450)
at WebsiteBuilderClientAction.onEditPage (web.assets_web.min.js:22215:55)
```
This fix ensures tooltip cleanup is performed safely without re-disposing already disposed elements.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change fixes a crash that could happen when users group analytic accounts by plan in Accounting. It ensures the totals are calculated safely, so the page loads normally instead of showing an error.
Original PR description
**Steps to reproduce:** 1. Install `accountant` 2. Go to settings and enable `Analytic Accounting` 3. Navigate to Accounting > Configuration > Analytic Accounts 4. Apply Group by plan. **Isuue:** -…
**Steps to reproduce:** 1. Install `accountant` 2. Go to settings and enable `Analytic Accounting` 3. Navigate to Accounting > Configuration > Analytic Accounts 4. Apply Group by plan. **Isuue:** - Traceback `ValueError: Cannot convert account.analytic.account.debit to SQL because it is not stored` **Cause:** - By this commit https://github.com/odoo/odoo/commit/98f746269bdec23e184e9efa83dc30057a458718 a new aggregator function sum_currency was introduced. https://github.com/odoo/odoo/blob/e6928b68bfb2b07e20d9fa49d30a70af0890bd75/addons/web/static/tests/_framework/mock_server/mock_model.js#L1342 in the case of account.analytic.account the non-stored computed fields debit, credit, and balance now receive extra aggregate requests (debit:sum_currency, credit:sum_currency, balance:sum_currency) during web_read_group. **Solution:** - Bypass SQL aggregation for the non-stored fields (debit, credit, balance). Instead of aggregating them in SQL, return the recordsets (id:recordset) for these fields and compute their sums in Python. opw-5101209
This update fixes how Chilean states are identified in customer addresses. It replaces placeholder numeric codes with the official standard codes, so addresses display and validate correctly.
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 fixes an error that could show up on the appointment information page when an appointment was limited to work hours and linked to a staff member with flexible hours. The page now handles this case correctly, so customers can view appointment details without running into a 404 error.
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 change adds an automated test to verify that invoice PDFs show both the product name and the added description correctly. It helps prevent a recurring display issue from affecting customer invoices and ensures future updates do not reintroduce it.
Original PR description
Issue: If a description is added on a product line, the printed invoice PDF only shows the description without the product name. Purpose of this PR: To add a test to ensure that the product description is correctly reflected on invoice PDF. Original issue was fixed by this PR: https://github.com/odoo/odoo/pull/222589 opw-4985815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221612
The website editor now avoids showing the same text highlight twice when a new highlight overlaps an existing one. This keeps highlighted text cleaner and prevents confusing visual duplication for editors and visitors.
Original PR description
Problem: When a text highlight is applied on a node that has an ancestor with the same text highlighted, both highlights remain. The ancestor's highlight should be removed before applying the new one. Cause: When applying highlight, it is done on the text node (leaf node). However, one of the ancestors might already have the highlight applied. This is not removed, leading to duplicate highlights. Solution: When applying the highlight, check if an ancestor has the same text and highlight style applied. If so, remove it before applying the new highlight. Steps to reproduce: 1. Add text "ABC". 2. Apply text highlight on "B". 3. Apply animation on "B". 4. Apply text highlight on "ABC". 5. In the DOM, "B" has two highlights (visually noticeable). opw-5014674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222862
This change fixes an issue where upgrades could be processed in a different order from one run to another. By keeping the version list ordered, Odoo now applies migration steps predictably, reducing the risk of inconsistent upgrade behavior.
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 improves how Swedish bank account numbers are identified when exporting partner bank details. It ensures several valid account formats are correctly recognized as Swedish, reducing export errors and avoiding manual cleanup.
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 change adjusts the order of steps in the wishlist test so the wishlist count has time to update properly. It helps prevent random test failures and makes the website shop testing more stable.
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 salary simulation for new offers now calculates gross pay correctly even when a contract template has no working hours defined. This prevents the preview from incorrectly showing zero salary and makes offer estimates more reliable for HR users.
Original PR description
Reproduce: In debug mode go to Payroll > Employees > Offers > Create a new offer with a contract template that has no working hours. The gross salary shown in the Salary Simulation Preview is 0. Issue: If the version has no resource calendar, its working hours are 0. This sets the `work_time_rate` to 0, and when multiplied by the wage the gross becomes 0 as well. Fix: Prioritize the version’s resource calendar when available, otherwise fallback to the offer’s calendar, and finally to the company’s. task-5051509
This update fixes the list of work entry types shown when adding multiple work entries from the planning view. It ensures the right options appear depending on whether the user is working in a single company or across multiple companies, preventing missing choices during creation.
Original PR description
Reproduce step: 1. Go to work entries 2. Select some work entries to add using the multiselection in the gantt view. 3. Work entry types doesn't include the ones related to the country. Reason: The country_id is set to False, so the old domain will retrieve only the work entries which are not related to any country. Fix: Add a dynamic domain which depends on the situation, if we are going to create work entries in the gantt views in multi company situation, we will display the work entries types without a specific country only to avoid issues, since it is possible to select employees from different companies at the same time. In the other case (single company) we filter the work entry types based on the self.env.company.id Related task: 5155691. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a failing language-related test so it behaves consistently when only one app is installed. It ensures the test uses the user-defined default language instead of assuming the first language in alphabetical order, preventing false failures in setups that activate Arabic during installation.
Original PR description
Description of the issue/feature this PR addresses: test_lang_computation_form_view fails since l10n_gcc_invoice activated the arabic language during post_init since the default language expected…
Description of the issue/feature this PR addresses: test_lang_computation_form_view fails since l10n_gcc_invoice activated the arabic language during post_init since the default language expected becomes arabic instead of English even though the created partner's language is in English. to reproduce: - install l10n_gcc_invoice - run the test test_lang_computation_form_view. - will fail since it expects the partner default lang to be arabic but it is in english. Current behavior before PR: before this commit, test_lang_computation_form_view failed on l10n_gcc_invoice or any of the depending modules. because activating arabic makes the test expect arabic as the default language when it is english. Desired behavior after PR is merged: with this commit the test is passed as we install the arabic language only during the activation of dual language in the company settings rather than during the post_init. runbot:231711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The inventory settings page now makes it clearer that users can assign accounts to inventory loss and production locations. A direct link and short help text were added so businesses can find the right configuration more easily and avoid setup confusion.
This update fixes a stock test that had incorrectly passed even though it contained conflicts, helping ensure the test suite catches real issues before changes are merged. It also updates the test to match a recent refactoring, keeping the codebase consistent and reducing the risk of future regressions.
Original PR description
Due to an issue in the runbot, the test associated with the PR: odoo#230199 passed despite underlying conflicts and the PR was merged. This PR addresses and resolves those issues to ensure the test functions correctly. We also align the PR with the refactoring done in odoo#212679 and replace `procurement.group` with `stock.rule` Impacted versions: - 19.0 - master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the currency and unit shown on emissions are refreshed when the underlying emission factor changes. It prevents outdated values from appearing in ESG reports, improving the accuracy of reporting data.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values. Forward-Port-Of: odoo/enterprise#98724
Selection fields in signed documents now correctly display their placeholder text before a choice is made. This makes the signing experience clearer and helps signers understand what value is expected.
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
The Journal Report now keeps the Global Tax Summary in sync when users change the rounding unit. This fixes a mismatch where the main report updated correctly, but the tax summary still showed old formatting and amounts.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98641 Forward-Port-Of: odoo/enterprise#94660
This fix ensures that default values in mock fields are preserved when a model is extended in tests. As a result, timestamps and similar automatically filled values are applied correctly again, making test behavior 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
This change updates a few HTML Builder tests to use the correct base option component. It helps keep the test suite aligned with the current implementation and prevents avoidable test issues during development.
Original PR description
In PR https://github.com/odoo/odoo/pull/220746, we forgot to replace the use of Component with BaseOptionComponent in few tests. This commit fixes that. 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#234153
The website loading progress bar now uses the primary brand color instead of black. This makes it easier to see in dark mode and keeps the site’s look more consistent.
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 change makes replenishment tests reliable when demo data is used in different time zones. It prevents the system from creating an extra purchase order line by ensuring date checks are compared consistently, so existing orders are reused as expected.
Original PR description
The `test_replenish` test was failing with demo data because replenishment created an extra Purchase Order line. The `_run_buy` search domain included `date_planned_mps` with an equality check on a datetime stored in `UTC`. With demo data loaded in a non-UTC timezone (e.g. Europe/Brussels), the forecast date was converted to `2025-07-31 22:00:00 UTC`, which did not match the existing PO at `2025-08-01 00:00:00 UTC`. As a result, no PO was found and a duplicate was created. Changes: Set the test user timezone to `UTC` so that `date_planned_mps` comparisons are stable when using demo data. This ensures replenishment reuses the existing PO instead of creating a duplicate. [runbot-230425](https://runbot.odoo.com/odoo/error/230425)
This fix corrects how available stock is calculated when a customer orders both individual units and a package of the same product. Previously, the system could count too much quantity as reserved, causing an item to appear out of stock even when enough was available for pickup.
Original PR description
Steps to reproduce: 1. Add a packaging to the storable product (ex. pack of 6) 2. Uncheck continue selling 3. Update qty of the product in the wh to 20 4. Add 4 units to the cart 5. Add 1 pack 6. Choose pickup in store and go to the checkout The product is not in stock even though there is enough quantity.
This change prevents an error that could occur when users add a project update in projects using budget features. It ensures the update form opens correctly instead of failing during display, improving reliability for project teams.
Original PR description
Currently an issue is generated when the project user tries to add a project update. Steps to produce an error: - Install the 'project_account_budget' module with demo data. - Log in with the demo…
Currently an issue is generated when the project user tries to add a project update.
Steps to produce an error:
- Install the 'project_account_budget' module with demo data.
- Log in with the demo user
- Go to Project and open the dashboard of the Home Construction project
- Click new »> error occurs
Error
```
QWebError
Error while rendering the template:
KeyError: 'revenues'
Template: project.project_update_default_description
```
This issue occurs due to:
- The reference commit [1] enhances the project update form description by enabling the display of profitability even without the sale timesheet.
- With commit [1], code was added to set the `profitability_values` to an `empty dictionary ({})` and `show_profitability` to `False` (see [2]) , since the demo user does not belong to the `project.group_project_manager` group (see [3]).
- In the `project_account_budget` module, the value of `show_profitability` is updated and set to True because the total_budget_amount is present in the project (see [4]).
- In the template `project_update_default_description` rendering, the `profitability` is accessed when `show_profitability` is `True`. However, since `profitability` is an empty dictionary, attempting to access the key will result in an error (see [4]).
This commit fixes the above issue by preventing the recalculation of `show_profitability`, as it is already set based on whether `profitability` data is available or not.
[1]: https://github.com/odoo/odoo/commit/e81af984aabe61defa0932b7890ab373fe3c8e2a
[2]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_update.py#L114-L126
[3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_project.py#L1111-L1112
[4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/views/project_update_templates.xml#L26-L31
Sentry-6915109069,6981931420This update fixes how Odoo handles missing skill-matching data for job applicants. When no matching score is available, the system now falls back to 0 instead of 100, keeping results consistent with earlier versions and avoiding misleadingly high match scores.
Original PR description
- The [PR] added a fallback value for matching score as `100`, whereas in the versions `saas-18.4` and before... we had the fallback value as `0` [source]. - Therefore, to maintain consistency this commit changes the fallback value for `matching_score` to 0. - Also added a testcase for the same. [PR]: https://github.com/odoo/odoo/pull/230323 [source]: https://github.com/odoo/odoo/blob/d13ea53ef64d0281387ad0daf66c90163dded63b/addons/hr_recruitment_skills/models/hr_applicant.py#L47-L51 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents stopped call ringtones from being restarted with the Play/Pause key after a call has ended. It improves call handling behavior and avoids confusing audio playback for users.
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
14 changes
Resolved issues and error corrections
Fixed an issue where the image toolbar would not appear if the editor had lost focus first. The editor now correctly checks both the current focus and the text selection, making image editing more reliable for users.
Original PR description
Description of the issue: - The image toolbar failed to open when the editable had lost focus. - Previously, `focusEditable()` exited early if the active element was inside the editable, even when the actual document selection wasn’t. Solution: - Updated the condition in `focusEditable()` to also check whether the document selection is inside the editable. - Now it only returns early when both the active element and the selection are within the editable. task-5117272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change brings back the Lot/SN column in Detailed Operations. It makes it easier for users to open the related lot or serial number record directly instead of seeing only plain text in the Pick From field.
Original PR description
The Lot/SN column was removed from the Detailed Operations tree view because it was considered redundant with the "Pick From" column in #199630. However, the lot or SN number displayed in the "Pick From" column is plain text and cannot be clicked to navigate to the corresponding `stock.lot` form view, which can be inconvenient. This PR brings back the Lot/SN column to restore direct navigation to the lot or serial number records. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents invoices from being assigned the wrong invoice type when they are linked to a purchase order. It ensures that special cases like refunds keep their original classification, avoiding accounting errors and incorrect document handling.
Original PR description
### Case This PR fixes the case of creating an invoice with a specific move_type(for example in_refund), than this invoice is linked to a purchase order. I discovered the bug while importing an XML Invoice of an in_refund. Importing this Invoice, the move_type become move_type because it is overwritten from the prepare_invoice data ### Before this PR The move_type is overwritten, so the in_refund become in_invoice and it is wrong. ### After this PR: The move_type is preserved. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a stock test that previously appeared to pass because of a runbot issue, even though there were underlying conflicts. It helps ensure the test now properly detects problems, reducing the risk of unnoticed regressions in stock-related updates.
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
This change fixes an issue where upgrade steps could run in a different order from one execution to another. By keeping the order consistent, it reduces the risk of unpredictable migration behavior during upgrades.
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 change prevents a browser error that could appear when a user saves a pop-up form after interacting with a related list. It makes the interface more reliable by stopping background actions from running on screens that are already closed.
Original PR description
Steps to Reproduce: - Open a Repair Order form view in Odoo 17 or 18. - Navigate to the Parts tab. - In the list view of parts, click the Smart Button on any part line. - A pop-up form view opens…
Steps to Reproduce:
- Open a Repair Order form view in Odoo 17 or 18.
- Navigate to the Parts tab.
- In the list view of parts, click the Smart Button on any part line.
- A pop-up form view opens showing detailed operations.
- Click the “Pick From” field value, but don't change its value.
- Click the Save button in the pop-up.
- Observe the browser console for the error: TypeError: Cannot read properties of null (reading 'querySelector') at ListRenderer.focusCell
Traceback:
```py
TypeError: Cannot read properties of null (reading 'querySelector')
at ListRenderer.focusCell (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9519:80)
at ListRenderer.<anonymous> (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9477:272)
```
Root Cause:
- Asynchronous patching in OWL (onPatched with await Promise.resolve()) continues execution after the next tick, even if the component is destroyed.
- When the component is destroyed, OWL sets status(this) = 3 (DESTROYED).
- focusCell() accesses DOM using querySelector, which fails if the component is destroyed.
- The code did not check the component status before calling focusCell().
Fix:
- Added `if (status(this) === destroyed) return;` to stop focusCell() execution on destroyed components.
- Ensured async patching is handled safely with await Promise.resolve().
- Added `onWillDestroy` to clean up dialog callbacks, preventing memory leaks.
OPW - [5154694](https://www.odoo.com/odoo/project/70/tasks/5154694)
[PAD](https://pad.odoo.com/p/issue_5154694_shku)
Localhost issue reproduction [steps](https://drive.google.com/file/d/1wkglUosOveUseU0mBePZcQAFB_ZWr3uM/view)
17:https://github.com/odoo/odoo/blob/f9726cfe93e8850a38d9de06acfa5d78473b50b0/addons/web/static/src/views/list/list_renderer.js#L223
18:https://github.com/odoo/odoo/blob/1cac54db8634267a780b4011291f1e8a80ac5f5b/addons/web/static/src/views/list/list_renderer.js#L213
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#232097This update corrects how overtime one-time payments are processed in the Swiss payroll transmission flow. It helps ensure overtime amounts are sent with the right values, reducing the risk of payroll reporting errors.
Original PR description
Forward-Port-Of: odoo/enterprise#98670
The website now only shows the language selector placeholder when there is more than one language available. This prevents an empty header item from appearing and removes the extra border or blank space it created.
Original PR description
This PR calls the language selector placeholder only when multiple languages exist, avoiding an empty header list item that creates an unnecessary border or empty space. task-5150808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231256
This fix ensures that once a ringtone is stopped, it cannot be restarted accidentally by media keys on a headset or keyboard. It prevents users from hearing old call alerts after the call has already ended, improving the overall calling experience.
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 prevents products added through a sales combo from being incorrectly merged into a separate product selection. As a result, the system now creates the correct sales lines and keeps combo extra prices from affecting separately added items.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes Chinese Yuan (CNY) from the currencies PayPal can use in Odoo when the PayPal account is not eligible for it. As a result, customers will no longer reach a payment flow that fails or behaves unexpectedly for CNY invoices, making checkout clearer and more reliable.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893This change prevents expense report PDFs from showing the title twice when using the DIN5008 German document format. It does this by providing the correct report title for DIN5008 headers, resulting in cleaner and more professional printed expense reports.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a value `din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to extend the expense sheet report and set the `din5008_document_title` to `Expenses Report`. opw-4314414
This update corrects the test data used for passkey authentication demos by setting the admin user’s time zone. It helps prevent test failures in automated checks and keeps the demo authentication flow reliable.
Original PR description
We need to define timezone of the admin user for no demo tests, similar to how it is done in [saas-18.3](https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/addons/auth_passkey/tests/test_passkey_demo.py#L456): [Runbot error - 229872](https://runbot.odoo.com/odoo/error/229872) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a mail template is duplicated, its attachments are now copied too instead of being shared between templates. This prevents edits to one template from unintentionally affecting others and helps avoid access issues in future setups with custom rules.
Original PR description
Copying tmeplates should copy their attachments. Otherwise they are
shared, which means
* wrong res_id: ACL check on attachments relies on a specific
template, as res_model / res_id is used in access check;
* propagated changes: changing one attachment changes it on all
duplicated templates;
If custom rules on templates are implemented, this means notably
ACL issues when accessing attachments. It is not the case in standard
Odoo 17 as everyone can read templates but this notably changes in
future versions of Odoo.
While being there, also fix 'default' usage in copy override. User
given values should not be erased by default computation of name.
Task-5128863
Forward-Port-Of: odoo/odoo#2328775 changes
Resolved issues and error corrections
This change fixes an issue where some upgrade steps could run in a different order from one execution to another. By keeping the migration order stable, it helps ensure upgrades behave predictably and reduces the risk of inconsistent results during updates.
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 fix ensures each dropdown option on website forms is translated and saved independently. As a result, changing one option no longer causes the other translated options to reset when switching languages.
Original PR description
__Current behavior before commit:__ [This PR] made the `<select>` field translatable by adding `select` and `option` to `TRANSLATED_ELEMENTS` and implementing a temporary element to handle the…
__Current behavior before commit:__ [This PR] made the `<select>` field translatable by adding `select` and `option` to `TRANSLATED_ELEMENTS` and implementing a temporary element to handle the frontend translation. Consequently the method `translate_xml_node` considers the `<select>` field translatable as a whole. Editing the text of one option therefore resets the translation of all the other options as well. __Description of the fix:__ - Remove `select` and `option` from `TRANSLATED_ELEMENTS` so each option is considered as an independant translatable term. - Adapt the temporary element hack consequently as well as its CSS. - Remove the now useless `SelectTranslateDialog`. __Steps to reproduce:__ 1. Add a form snippet to a website page. 2. Add a selection field to the form. 3. Translate the options in another language. 4. Leave Translation mode and go back to Edit mode. 5. Edit one of the option. 6. Change the website back to the second language. => All the options of the select field are reset. [This PR]: https://github.com/odoo/odoo/pull/117519 task-5116823
This fix ensures the system returns the correct copied email template instead of reusing the wrong one. It prevents unexpected template content from showing up when users duplicate mail templates.
Original PR description
Fix reused variable name
When a sales order’s pricelist is updated, optional product prices are now recalculated correctly. This prevents optional items from keeping an outdated price or incorrectly staying at zero, so pricing shown to customers stays accurate.
Original PR description
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist -…
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist - Click on 'Update Prices' - Notice the optional product price won't change ### Cause: When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation. If sale_subscription is installed we will set the product's prices to 0 https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 so the price of the 'Optional product' SOL will change but will be equal to 0 ### Fix: An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed opw-5058609
When a deferred start date is entered without an end date, the system now automatically uses the same date for both values. This prevents invalid accounting periods and makes the setup flow smoother for users in stable versions.
Original PR description
Previously, specifying a Deferred Start Date without an End Date would result in an invalid period. This commit updates the logic to default the End Date to the value of the Start Date if the End Date is not provided. This streamlines the flow in stable versions until a more comprehensive solution is implemented in master. Task-5207293