Daily updates from Odoo
Navigate
Branch
Tuesday, November 4, 2025
202 changes
10 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
14 changes
Enhancements to existing features
This change prevents the built-in Public User from being deleted, which could previously break the login page in databases without the Website module. It helps keep public access working reliably and avoids an internal server error for users trying to sign in.
Original PR description
Steps to Reproduce:
1. Create a database without installing the Website module.
2. Navigate to archived users and delete the "Public User."
3. Attempt to log in to the database from another browser or incognito
mode.
4. An internal server error occurs because the public user does not
exist, making the login page inaccessible.
Issue:
Previously, it was possible to delete the public user, leading to an
internal server error due to its absence, which prevented public access
to the login page.
Solution:
- Implemented a restriction to prevent the deletion of the public user,
similar to portal and default users.
- Added a test case to validate this functionality and ensure the
public user cannot be deleted.
task-4423568
Forward-Port-Of: odoo/odoo#196918This update refreshes the QR-code URLs sent to Avalara for Brazilian NFC-e invoices. It fixes errors caused by outdated state-specific links, helping invoice issuance continue to work correctly.
Original PR description
In This PR:
- Several states have updated their NFC-e QR-code URLs, which caused errors when issuing invoices due to invalid or outdated links. This commit updates the 'nfceQrCode' parameter in Avalara requests ('calculate-tax' and 'submit-invoice-goods') to ensure the correct QR-code links are used.
task- 5115845
Forward-Port-Of: odoo/enterprise#95726Resolved 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-51378287 changes
Enhancements to existing features
This update refreshes the NFC-e QR-code URLs sent to Avalara so they match the latest links used by the states. It helps prevent invoice errors caused by outdated or invalid QR-code addresses during tax calculation and invoice submission.
Original PR description
In This PR:
- Several states have updated their NFC-e QR-code URLs, which caused errors when issuing invoices due to invalid or outdated links. This commit updates the 'nfceQrCode' parameter in Avalara requests ('calculate-tax' and 'submit-invoice-goods') to ensure the correct QR-code links are used.
task- 5115845
Forward-Port-Of: odoo/enterprise#95726Resolved 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#9674629 changes
Enhancements to existing features
This update improves how employee benefits, such as Belgian eco vouchers, are handled across contracts, salary offers, and payslips. It helps payroll teams avoid unwanted automatic copying of benefit values while making salary rule settings more flexible and reliable.
Brazilian invoices, sales orders, and point-of-sale orders for foreign customers now include the required export details when sent to Avalara and EDI services. This helps ensure export-of-goods transactions are correctly identified and processed for Brazilian localization compliance.
Original PR description
Purpose: By allowing the user to add a foreign partner as a customer on an invoice, we will need to include the export of goods information in the requests sent to Avalara and EDI. The required information under goods to be sent for export invoices are: - header.goods.idDest = 3 (indicates export operation) - header.goods.exportInfo.shippingState (indicates the state the products will ship from) - header.goods.exportInfo.place (incoterm_location) - header.locations.entity.address.neighborhood = "EXTERIOR" - header.locations.entity.address.zipcode = "99999999" - header.locations.entity.address.cityCode = "9999999" - header.locations.entity.address.cityName = "EXTERIOR" - header.locations.entity.address.state = "EX" - header.locations.entity.federalTaxId = "9999999999" task-4802462
Warehouse teams can now print Starshipit shipping labels in batches, reducing repetitive work when processing multiple deliveries. Labels also include the sales order reference in the order number, making it easier to match each label to the correct customer order.
Original PR description
Adds two improvements to the usability of the module by supporting printing starshipit labels in batch, and also adding the SO reference to the order number to more easily match the label with it. task-4821727 Forward-Port-Of: odoo/enterprise#91405
Account lists now show the current applicable fiscal rate and fiscal category, making review work easier. Fiscal report warnings about multiple rates are more accurate because they only consider accounts used in the selected period, and Belgian chart data was corrected to remove a duplicate rate assignment.
Original PR description
[IMP] account_fiscal_categories: enhance list view of account_account ====================================================== With this commit, we add a new field `current_rate` in `account.account`.…
[IMP] account_fiscal_categories: enhance list view of account_account ====================================================== With this commit, we add a new field `current_rate` in `account.account`. This `current_rate` is a non-stored compute field, used to compute the current applicable rate on the given account. This `current_rate` and `fiscal_category_id` has been introduced in the list view of `account.account`. [IMP] account_fiscal_categories: enhance multiple rate warning in fiscal report =========================================================== Before this commit, the "multiple rate" warning was shown even when no entries for accounts with multiple rates existed in the selected period. This happened because all accounts were considered for multiple rates, regardless of journal entries in that period. After this commit, only accounts with entries in the selected period are considered for the "multiple rates" warning. The warning is now clickable, redirecting the user to the accounts having multiple rates. [FIX] l10n_be_fiscal_categories: remove redundant rate on CoA ================================================= This commit removes the redundant fiscal rate on account-613311. Both fiscal categories 1206 and 1073 were assigned to this account, resulting in two rates. Only 1073 should be there. ref-https://github.com/odoo/enterprise/commit/f2579a80833ac129b2f21613b93c4e3203646a1b **task**-5163392 ----------------------- Forward-Port-Of: odoo/enterprise#97324
Appraisal forms now include an expand button for employee and manager feedback fields. This opens a larger pop-up editor, making it easier to review and update longer feedback during performance appraisals.
Original PR description
Add the expand button to the employee feedback and manager feedback fields on the appraisal form, click on it, it will open a pop up to update the employee or manager feedback. task-4852953
The Belgian POS blackbox integration now prompts users to update their IoT device so it can support an upcoming queued communication flow. This prepares retailers for a more reliable connection between POS terminals and the fiscal blackbox in the next update.
Original PR description
This commit is the first of two which will introduce a queue mechanism in the communication between the POS and the blackbox. This commit adds an action to the iot and invites users to update their iot to be prepared for the next commit which will effectively add the queue mechanism and use the new action. Second part: https://github.com/odoo/enterprise/pull/90747 Forward-Port-Of: odoo/enterprise#96904 Forward-Port-Of: odoo/enterprise#96639
The Barcode app now shows a more descriptive unpack icon by combining existing icon elements into a custom visual. This helps warehouse users better recognize the unpack action and reduces confusion during barcode workflows.
Original PR description
In barcode the unpack icon isn't descriptive enough. Since font-awesome doesn't provide any icons to convey the proper meaning, this PR stacks 2 fa icons to create a new one. task-5051649 Forward-Port-Of: odoo/enterprise#95749
The bike tax deduction field was removed from the vehicle model information because it is now managed under engine specifications. This avoids showing the same information in two places and helps keep payroll fleet data clearer for users.
Original PR description
for bike, removed tax deduction field from model info since it's now handled under engine specs. task-4653379
The Discuss app now uses a shared synchronization approach for related channel, member, and category information. This reduces duplicate logic behind the scenes, making future maintenance safer while preserving the user experience.
Original PR description
Currently, Discuss Channel, Discuss Channel Member, Discuss Category, have certain fields that need to stay synchronized when updated. This is currently done with a custom implementation of _sync_field_names on each model and orm (write) overrides. Since the synchronization logic is mostly similar across these models, we want to introduce a way to generalize this solution. task-5221092 https://github.com/odoo/odoo/pull/233654
All IoT-related code has been brought together into the Enterprise IoT module, simplifying where these capabilities are maintained. This should make future improvements and support for connected devices, point of sale hardware, and self-ordering integrations more consistent.
Original PR description
As it was decided to move all IoT related code to Enterprise, this commit merges back `iot_base` into `iot`. odoo/odoo#231746
This update makes the small buttons in the top menu bar show clearer visual states, such as hover, active, and dropdown behavior. It creates a more consistent experience across apps, light and dark themes, and enterprise navigation areas.
Original PR description
*: documents, hr_contract_salary, hr_payroll, industry_fsm_stock, mail_enterprise, mrp_workorder, stock_barcode, test_l10n_be_hr_payroll, voip, web_studio, website_enterprise This PR improves the…
*: documents, hr_contract_salary, hr_payroll, industry_fsm_stock, mail_enterprise, mrp_workorder, stock_barcode, test_l10n_be_hr_payroll, voip, web_studio, website_enterprise This PR improves the different button states within the `.o_menu_systray element` - requires https://github.com/odoo/odoo/pull/227858 | ///////// | Master | This PR | |--------|--------|--------| | AppSwitcher (**Light**) | <img width="489" height="43" alt="image" src="https://github.com/user-attachments/assets/39638af5-3bf4-4489-bd28-d409e74130a7" /> | <img width="493" height="49" alt="image" src="https://github.com/user-attachments/assets/0ae1a53f-457d-408e-847c-e4cbe187b6d1" /> | | AppSwitcher (**Dark**) | <img width="487" height="40" alt="image" src="https://github.com/user-attachments/assets/926c499f-18a0-4e8b-b71c-50ff0dd2d73a" /> | <img width="493" height="47" alt="image" src="https://github.com/user-attachments/assets/3983d593-2cdc-4184-a325-36a4bda4dd03" /> | | In App (**Light**) | <img width="494" height="47" alt="image" src="https://github.com/user-attachments/assets/c82bd674-00c3-47e6-9fd6-7b8abb29c873" /> | <img width="475" height="46" alt="image" src="https://github.com/user-attachments/assets/7d3829ae-17cf-42b0-940f-5b3eb7b57209" /> | | In App (**Dark**) | <img width="490" height="44" alt="image" src="https://github.com/user-attachments/assets/e1583d60-1ec9-4954-b63a-d6adcf55c070" /> | <img width="482" height="45" alt="image" src="https://github.com/user-attachments/assets/fd64aba7-921b-4d4e-97f5-c5e36de5ebf3" /> | | Front-end (**Light**) | <img width="487" height="48" alt="image" src="https://github.com/user-attachments/assets/b7421589-cb20-447c-9b81-80dcb4f00b66" /> | <img width="507" height="48" alt="image" src="https://github.com/user-attachments/assets/a7bdc284-e949-481c-a20d-849221cebee7" /> | | Front-end (**Dark**) | <img width="502" height="47" alt="image" src="https://github.com/user-attachments/assets/aefb1260-6a0a-4c69-a4db-d30865427b91" /> | <img width="505" height="49" alt="image" src="https://github.com/user-attachments/assets/0411a78f-807f-42bb-b88c-3fb4b65fb67f" /> | --------- Currently, these buttons are either: - `<button>` elements with only the .btn class, which does not provide a complete set of CSS properties. - `.dropdown-toggle` elements with an inherited background-color, which ends up being the transparent background set on the `<nav>` element. This commit harmonizes these approaches into a single one, aligned with the implementation used in .o_menu_sections. This increases consistency and also improves the accessibility of these items. task-5098241
This update adds a dedicated PDF version of Mexican payroll CFDI documents, making it easier for companies to generate and share compliant payroll receipts. It improves payroll reporting and presentation for employees and administrators using Mexico payroll localization.
Original PR description
Forward-Port-Of: odoo/enterprise#94551
Brazilian point-of-sale invoicing now uses updated NFC-e QR code links required by several states. This helps prevent invoice issuing errors caused by outdated links when sending tax and goods invoice requests through Avalara.
Original PR description
In This PR:
- Several states have updated their NFC-e QR-code URLs, which caused errors when issuing invoices due to invalid or outdated links. This commit updates the 'nfceQrCode' parameter in Avalara requests ('calculate-tax' and 'submit-invoice-goods') to ensure the correct QR-code links are used.
task- 5115845
Forward-Port-Of: odoo/enterprise#95726Salary adjustments can now be linked to a beneficiary bank account, ensuring payments are directed to the correct account in payment reports. The beneficiary details are also shown on payslips, giving employees and payroll teams clearer payment information.
Original PR description
This commit introduces the concept of a beneficiary for salary adjustments. A bank account can now be linked to an adjustment, so that the adjustment payment is directed to it in the payment report and also displayed on the payslip. Task: 5040786
Hong Kong payroll declaration forms now include chatter, making it easier for users to follow discussions and track activity directly on the reports. This improves collaboration and visibility for teams managing local payroll declarations based on user feedback.
Original PR description
Based on HK feedback, chatter is added on their declaration forms task:5067386
Contract salary template version fields now open using the correct form view configuration. This helps HR users reach the intended contract template screen more reliably and reduces navigation confusion.
Original PR description
The contract template form view is now written on the formview_action directly. task-5082709
Accounting reports can now include multiple text-based columns, making it easier to present items such as tax box numbers. This improves clarity for VAT reports in countries like Germany, South Africa, and North Macedonia without changing core reporting workflows.
Original PR description
Add a simple text engine to reports to be able to add multiple text columns. This is useful for reports that have box numbers eg. DE/ZA/MK VAT Reports
Odoo now uses one consistent way to keep internal dictionary data read-only, reducing the chance of inconsistent behavior. This improves reliability and performance for internal processes without changing day-to-day user workflows.
Original PR description
Before this commit, Odoo had two implementations for creating an immutable dictionary. These two implementations have different behaviors and coexist for backward compatibility reasons. The purpose of this commit is to leave only one implementation for the immutable dictionary, called `frozendict`. This implementation makes it truly impossible to modify the mapping. In addition, by default, we don't override internal methods of the dictionary which improves performance (despite the cost during creation). Note 1: Classes `LangData` and `LangDataDict` are adapted as `Mapping` subclasses instead of `ReadonlyDict`. This simplifies their implementation, which is not performance-critical. Note 2: This change is possible because the `MappingProxyType` class implements fallback on the `__hash__` method since version 3.12 (thanks to d357125). task-4808836
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
Features or functions removed from Odoo
Odoo no longer includes the separate OnSIP VoIP add-on because its extra authorization username setting is not required when OnSIP is configured with matching usernames. This simplifies VoIP configuration and maintenance while keeping core VoIP support available.
Original PR description
With OnSIP, you can define an authorizationUsername that differs from your contact username. To enable this feature in Odoo, the voip_onsip module was introduced, simply adding an extra field for the authorizationUsername. However, if OnSIP is configured with a username identical to the authorizationUsername, it is possible to work around this field. As it is now known that the extra config is not strictly needed, this commit removes the voip_onsip module. [Task-5176220](https://www.odoo.com/odoo/project/5778/tasks/5176220). Upgrade: https://github.com/odoo/upgrade/pull/8679 Documentation: https://github.com/odoo/documentation/pull/14978
Code cleanup and technical improvements
This draft reorganizes shared Point of Sale test logic so multiple country and device-specific features can rely on the same foundations. The change is mainly internal and helps reduce duplicated test setup, making future updates safer and easier to maintain.
Original PR description
Task: 4467373
25 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
Code cleanup and technical improvements
The way product revaluation values are prepared has been moved into a separate method. This does not change the user experience, but it makes the stock accounting process easier for custom extensions to adapt safely.
Original PR description
This allows to make it hookable by custom addons This was split from https://github.com/odoo/odoo/pull/160527 cc @pfertyk @sys-odoo @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232739 Forward-Port-Of: odoo/odoo#228204
11 changes
Enhancements to existing features
This update refreshes the QR-code links used for Brazilian NFC-e invoices so they match the latest URLs required by several states. It helps prevent invoice submission errors caused by outdated or invalid links.
Original PR description
In This PR:
- Several states have updated their NFC-e QR-code URLs, which caused errors when issuing invoices due to invalid or outdated links. This commit updates the 'nfceQrCode' parameter in Avalara requests ('calculate-tax' and 'submit-invoice-goods') to ensure the correct QR-code links are used.
task- 5115845This change prevents the built-in public user from being deleted, which could previously break the login page for anonymous visitors. It also ensures that existing databases missing this user can recover correctly when the Website module is installed, avoiding an internal server error and restoring access.
Original PR description
Steps to Reproduce: 1. Create a database without installing the Website module. 2. Navigate to archived users and delete the "Public User." 3. Attempt to log in to the database from another browser or incognito mode. 4. An internal server error occurs because the public user does not exist, making the login page inaccessible. Issue: Previously, it was possible to delete the public user, leading to an internal server error due to its absence, which prevented public access to the login page. Solution: - Implemented a restriction to prevent the deletion of the public user, similar to portal and default users. - Introduced a **pre_init_hook** to verify the existence of the public user in existing databases. If missing, the user is recreated during the Website module installation. - Added a test case to validate this functionality and ensure the public user cannot be deleted. task-4423568 Forward-Port-Of: odoo/odoo#196918
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
4 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