Daily updates from Odoo
Friday, March 13, 2026
43 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits within the same field could lead to incorrect status indicators. Now, the system reliably tracks changes within the HTML editor, ensuring users receive accurate feedback and can correctly update content.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#253280 Forward-Port-Of: odoo/odoo#252655
This update fixes an issue where social media posts weren't correctly displaying blog post cover images. The change ensures the correct image format is used when generating social media content, resolving a problem caused by a recent code update. This improves the visual consistency of blog posts shared on social media.
Original PR description
Scenario:
- set cover image of a blog post
- post blog post on social media (or check og:image/twitter:image tags)
Result: the social media is a dead image like:
http://site/blog/1/"/web/image/3198-3915f222/cover%20image.webp"
Cause: the code setting social image expected it to be in the
cover_properties background-image in url('{image}') or url({image})
format, but since 1b0852948c070d4d936bd00b3dd1c0e5501a1300 the format is
url("{image}") so it was gotten incorrectly.
Fix: also strip doubles quote and have the code working with
cover_properties background image with:
- no quote: for cover_properties before 18.4
- single quote: not sure in what situation this can happen
- double quote: for cover_properties since 18.4
opw-5471804
Forward-Port-Of: odoo/odoo#253206
Forward-Port-Of: odoo/odoo#252028This update resolves intermittent test failures in the sign-up process by using dedicated, consistent test users instead of the default 'admin' and 'demo' accounts. This ensures test results are reliable and predictable, improving the quality and stability of our sign-up feature.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216 Forward-Port-Of: odoo/enterprise#110454
This update fixes a potential security vulnerability by properly escaping HTML within API request error messages. Previously, unescaped HTML could have been exploited. Additionally, a clipboard button has been added for easy copying of these error messages.
Original PR description
Before this commit: Request errors were unescaped. After this commit: Request errors are properly escaped. A clipboard and a collapse button were added for ease of use. Forward-Port-Of: odoo/odoo#253069 Forward-Port-Of: odoo/odoo#252767
This update corrects a bug where users weren't seeing all their ratings in helpdesk average rating views. The fix ensures that users associated with helpdesk teams, even if not directly listed in the team's member list, accurately reflect their ratings in these views. This improves the accuracy of customer feedback data.
Original PR description
Steps to reproduce: - Configure a helpdesk team to be viewable by the test user - Remove test user from member_ids of helpdesk team - With that team selected, create a helpdesk ticket assigned to test user - Submit a rating for the ticket as the customer - As the test user in the helpdesk app overview, click on today average rating or last 7 days average rating Current behavior: - In both views, the test user won't see ratings for tickets attached to helpdesk teams where they are not listed in member_ids Expected behavior: - In both views, the test user should see all ratings of assigned tickets regardless if they are included in a helpdesk team's member_ids Note: member_ids in helpdesk.team appear to be only used for auto assigning new helpdesk tickets, so checking member_ids doesn't account for all potential users working in a team opw-5949917 Forward-Port-Of: odoo/enterprise#109470 Forward-Port-Of: odoo/enterprise#109136
This update resolves an issue where image shape transformations (rotations and flips) were not being properly cleared when changing image shapes. A new button has been added to manually reset these transformations, ensuring consistent behavior and a better user experience when working with image snippets.
Original PR description
Image shape transformations (flip and rotate) were never reset when changing or removing a shape; the dataset persisted indefinitely. Additionally, there was no way to manually reset a transformation, without undoing each operation manually. This commit ensures the dataset is cleaned when SetImageShapeAction is called and introduces a new button to manually reset transformations. Steps to reproduce: - Drop a snippet with image - Apply `solid_blob_4` shape on image (supports transformation) - Rotate or flip the shape - Change to `solid_blob_2` (does not support transformation) - Switch back to `solid_blob_4`, the first transformation is still there, it should have been reset task-5972945 Forward-Port-Of: odoo/odoo#253279 Forward-Port-Of: odoo/odoo#250875
This update fixes a missing 'Reset' button for specific Spanish informational reports. A recent configuration change made the standard reset button invisible. This fix adds a dedicated reset button that appears when the reports are completed, ensuring data can be cleared correctly.
Original PR description
- The `Reset` button was missing from the dropdown menu for Spanish informational reports (Mod 130, 347, 349, 390). - This occurred because these reports were recently configured with `is_tax_return_type = False` in this [commit](https://github.com/odoo/enterprise/commit/d2b1d29542c0350c267fecffd70d3e288364d8ab). However, the standard reset button (`action_reset_tax_return_common`) is configured to be invisible when `is_tax_return` is false. - This fix adds a reset button specifically for these Spanish reports that appears when the report is completed. task-5214023 Forward-Port-Of: odoo/enterprise#110271 Forward-Port-Of: odoo/enterprise#104739
This update increases the time allowed for payment processing requests, addressing potential issues caused by network delays and device timeouts. Additionally, a unique identifier has been added to transaction logs, providing better traceability and helping us track payments more effectively.
Original PR description
Reason: = - Network Connectivity: Terminal devices send continuous heartbeat checks to the API. Network fluctuations can cause heartbeat failures. - Configuration Discrepancy: Devices have a 60-second processing limit, while the server timeout was set to 30 seconds. In this commit: = - Increased Request timeout from 35s to 60s to prevent premature failures due to device/server timeout mismatch and network delays. - Added SourceID to system logs for improved end-to-end transaction traceability. task-6012679 Forward-Port-Of: odoo/odoo#252420
This update fixes a server error that occurred when merging tables in the restaurant POS system. Specifically, the system now waits for order synchronization before completing the merge process, ensuring a smoother and more reliable experience for restaurant staff. This prevents errors and improves table management functionality.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577 Forward-Port-Of: odoo/odoo#252942 Forward-Port-Of: odoo/odoo#245162
This update fixes a server error that occurred when merging tables in the Point of Sale system, specifically when a table had no associated order. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#110052 Forward-Port-Of: odoo/enterprise#104577
This update ensures accurate subline totals in barcode scanning by requiring the 'stock.group_production_lot' setting to be active. Without this setting, the system fails to group lines correctly, leading to incorrect calculations. This fix was introduced to address an issue originating from a previous version update.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update fixes a technical problem that could prevent the Odoo Enterprise payroll module from being uninstalled correctly. Removing work entries previously caused lingering references, leading to an error. This ensures a smoother and more reliable uninstall process.
Original PR description
Purpose: After work entries removal, some references weren't removed from payroll `uninstall_hook` so a traceback happens when trying to uninstall the module. task-id: 5955553
This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, taxes are calculated using standard product tax rules, ensuring accurate pricing for all orders.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#110166 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue impacting the PnL and Balance Sheet reports specifically for French association companies. The changes address minor data discrepancies within the reports, ensuring accurate financial reporting without requiring a major system overhaul. This improves the reliability of financial data for our French association clients.
Original PR description
The aim of this commit is fixing the Pnl & Balance Sheet report in France for association company. This commit ensures that we don't have any duplicate errors in the PnL & Balance Sheet. We kept some errors in the Balance Sheet (especially about the brut - amort - net) as we can't use aggregation with groupby but the data are not really duplicated. no task id Forward-Port-Of: odoo/enterprise#110163
This update adds a test to ensure the `_prepare_payment_data` method in the account online payment module functions correctly. The previous implementation relied on a field that was removed during a recent update, and this fix prevents potential issues with payment processing. It's a proactive measure to maintain system stability.
Original PR description
This commit safeguards the `_prepare_payment_data` method. Reason: We were using a field that no longer exists due to an oversight during a FW and having no tests to catch it. Fix here https://github.com/odoo/enterprise/pull/110266 No task ID
This update corrects a technical issue that previously caused export errors when working with worksheet templates in Odoo Enterprise. By removing outdated references to fields no longer present in the template, the export process now functions correctly and reliably.
Original PR description
Before this commit when exporting records from the `worksheet.template` model , it raises a traceback regarding the `model_id`, `action_id` which are not present on the `worksheet.template` anymore* In this commit we are updating the export logic by removing the custom logic for the `worksheet.template` model. *https://github.com/odoo/enterprise/pull/104754
A bug was preventing users from loading sample recruitment data. This fix updates the sample data to correctly reference the `recruiter_id` field, resolving a data parsing error. This ensures the recruitment scenario data can be properly loaded and used.
Original PR description
Currently an error occurs when user tries to load scenario data for recruitment. Steps to replicate: - Install `hr_recruitment`. - Open Recruitment and Click `Load sample Data`. Error: ```py…
Currently an error occurs when user tries to load scenario data for recruitment.
Steps to replicate:
- Install `hr_recruitment`.
- Open Recruitment and Click `Load sample Data`.
Error:
```py
ValueError: Invalid field 'user_id' in 'hr.applicant'
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo19/community/addons/hr_recruitment/data/scenarios/hr_recruitment_scenario.xml:72, somewhere inside
<record id='scenario_applicant_macm_helen' model='hr.applicant'>
<field name=email_from>helenlee@exampe.email.com</field>
<field name=partner_name>Helen Lee</field>...
```
Cause:
- The field `user_id` was changed to `recruiter_id` from the [PR].
- But the scenario data still had the field `user_id`, this caused the error.
Solution:
- Replace user_id in the sample data with recruiter_id and use an employee as a value instead of a user. One additional detail is that since this is sample data that can potentially be applied on a db that already has some records. There is a case where creating an employee in the sample file and linking them to the admin user, but that can cause an exception if the admin user is already linked to an employee. To circumvent this, we first check if there is an employee linked to the admin user. If not we create a new one and make the sample data use whichever employee that is linked to the admin user.
Backport for the PR: https://github.com/odoo/odoo/pull/246362
[PR]: https://github.com/odoo/odoo/pull/229665
sentry-7324422905
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where expense reports created from incoming emails weren't being generated due to a company mismatch. The fix ensures the system always uses the employee's company information, regardless of associated users, preventing the 'Incompatible companies' error. This allows expenses to be created seamlessly from email submissions.
Original PR description
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a…
**Steps to reproduce:** - Install Expenses - Activate "Incoming Emails" in the settings - Configure the expense Alias - Configure an "Incoming Mail Server" - Create a Branch for a company - Create a User: * Email Address: [an existing email address] * Allowed Companies: [the parent company + the branch company] * Default Company: [the branch company] * User Types: Internal User - Create an employee for the user in the parent company - From the email address, send a PDF to the expense alias **Issue:** The expense is not created in the database due to a UserError: "Incompatible companies on records". **Cause:** When the email is received and treated, the system tries to create an expense. From the email address, it retrieves an employee that is linked to the expense. For the company of the expense, if a user is linked to the employee, it takes the default company of the user. Otherwise, it takes the company of the employee. In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check. **Solution:** Always use the company of the employee, even if there is a user linked to the employee. opw-5346809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253497 Forward-Port-Of: odoo/odoo#249415
This update optimizes how Odoo tracks user devices, leading to faster performance when viewing user sessions and devices. Previously, a database index couldn't be used effectively, causing slower queries. This change utilizes a more efficient method to deduplicate device information, resulting in a noticeable performance boost.
Original PR description
When a view of `res.users` with the `session/device_ids` field(s) is used, the ORM will translate the `One2Many` relationship by performing a query that uses the `id` column to retrieve the rows. The problem is that before this commit, it is impossible for postgresql to use the index on this column, because the value is retrieved via aggregation. This commit improves the performance of these models by performing deduplication without using the `GROUP BY` clause, but using `NOT EXISTS` instead. Note: It is necessary to perform the missing aggregations in a computed field (for the `first_activity` field). Task-6002927 Forward-Port-Of: odoo/odoo#251921
This update fixes an issue where payment beneficiary accounts were incorrectly assigned after merging inbound and outbound payments. Specifically, when a refund is merged with a payment, the system now correctly identifies the appropriate bank account for the resulting outbound payment. This ensures accurate payment processing and reporting.
Original PR description
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same…
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account. Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient. The `partner_bank_id` can be assigned through different processes: - If the wizard has only one batch: The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`. - If there are multiple batches: Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id']. The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly. I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are. -Previous PR : [242863](https://github.com/odoo/odoo/pull/242863) However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here. Ticket: opw-5401372 Forward-Port-Of: odoo/odoo#249537 Forward-Port-Of: odoo/odoo#246558
This update resolves an issue where users were receiving blank PDF reports when attempting to print the planning report through the standard print menu. The fix ensures the report data is correctly prepared before printing, guiding users to the intended calendar print button for accurate report generation.
Original PR description
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.…
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report. **Steps to reproduce:** 1. Go to Settings app and enable debug mode 2. Navigate to Technical → Reports 3. Search for "slot_report" 4. Click "Add to print menu" button 5. Refresh the browser 6. Go to Planning app and switch to list view 7. Select a few planning.slot records 8. Click Print → Planning **Current behavior:** A blank or invalid PDF is generated. **Expected behavior:** Users should receive a clear error message directing them to use the correct print method from the calendar view. **Cause of the issue:** The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports. **Fix:** Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data. opw-5477184 Forward-Port-Of: odoo/enterprise#105168
This update resolves an issue where VIES validation errors caused system slowdowns and errors. By catching a wider range of exceptions from the VIES service, the system is now more robust and reliable when checking VAT numbers, preventing disruptions to key processes like OCR invoice updates. This improves overall system stability.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#251947 Forward-Port-Of: odoo/odoo#249853
This update fixes an error in how the system maps CPV codes for Romanian VAT invoices. Previously, the system incorrectly used 'CPV' instead of 'STI' for the ItemClassificationCode/listID, which is the correct code according to PEPPOL standards. This ensures accurate VAT processing and compliance.
Original PR description
The value of `ItemClassificationCode/listID` that corresponds to `CPV` classification is `STI` not `CPV`. See https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ task-5416833 Forward-Port-Of: odoo/odoo#251311 Forward-Port-Of: odoo/odoo#250045
The chart template for the 'pl' localization was incorrectly loading all `account.account` records, leading to performance issues. This change restricts the loading to root companies, significantly improving performance and resource usage for PL environments. This resolves a performance bottleneck and ensures efficient chart template loading.
Original PR description
During migration, the `l10n_pl` end-migrate script was loading for every company using the `pl` chart template, including child companies. However, account codes must be…
During migration, the `l10n_pl` end-migrate script was loading
for every company using the `pl` chart template, including child companies.
However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.
To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.
**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors
**Traceback**
```py
Traceback (most recent call last):
File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-196>", line 2, in create
File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
records._ensure_code_is_unique()
File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```
**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.
opw-5932421
upg-3895331
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#250654This update resolves an issue where the font size in the HTML editor toolbar would disappear when navigating within a document. The fix ensures that the editor's state, including font size settings, is preserved across toolbar redraws. This improves the user experience and prevents data loss during document editing.
Original PR description
Since [1], the font size in editor's toolbar is a `button` that contains an `iframe`. An `input` is put within this `iframe` so that when it is focused, the selection in the edited document is not lost. Unfortunately, when an `iframe` is moved in the DOM, it is restarted. In this case, the `iframe` has no source, so it becomes empty, and the content that was added into it `onMounted` is lost. This commit solves this by listening to every `load` events on the `iframe` instead of only the initial one. Steps to reproduce: - Go to a "To Do" note - Create a table with `/table` - Press Enter to confirm the 3x3 size - Select the last two cells of the first column - Move the mouse upwards to the next cell => The font size disappeared [1]: https://github.com/odoo/odoo/commit/a468de9d1099931d8f553c8569359996e7b694f2 task-6003539 Forward-Port-Of: odoo/odoo#252013
This update ensures that the country associated with a phone number (e.g., +1 or +32) always matches the currently selected country in the user interface. Previously, the system incorrectly used a fallback country, leading to inconsistencies. A new test has been added to verify this fix.
Original PR description
When parsing a keypad number, we were formatting the phone number with a fallback country (from the currently selected flag) but still resolving the returned country/flag from the pre-format parsing context (see [1]). This could lead to inconsistencies where the number is normalized as +1... while the UI country remains the previously selected one (e.g. Belgium). This commit recomputes country information from the formatted number before returning countryId/storeData, so the softphone flag matches the normalized phone number. Also adds a controller regression test covering this behavior. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 task-5995387 Forward-Port-Of: odoo/enterprise#109365
This update resolves a technical issue related to XML files used for Swedish payment processing (pain.001.001.09). The fix ensures the correct XML format is used, aligning with industry standards and improving the reliability of payment transactions in Sweden. This change primarily impacts the handling of financial data.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221 Forward-Port-Of: odoo/enterprise#109930
A warning message was appearing unexpectedly when adjusting the B1 field in French tax reports. This fix removes a redundant reference to 'box_B1' within the report's calculation logic, ensuring the system functions correctly without displaying the error. This improves the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001 Forward-Port-Of: odoo/enterprise#110169
This update resolves an issue where the invoice button wasn't correctly triggering invoice creation for orders in the Indian localization. The fix ensures the 'to_invoice' field is properly set when the button is clicked and the order is validated, preventing invoices from being missed. This improves the order processing workflow.
Original PR description
For some unknown reason, with the indian localization, in some tests, when the invoice button was clicked and the order was validated right after, the to_invoice field was not set to true and no invoice was created. This led to problem cause when we click on the button we want it to be taken into account. This commit fix this by checking that the button is unchecked, then clicked and then check that the button changed state. runbot-error: 238505 Community PR: https://github.com/odoo/odoo/pull/253119
This update resolves an issue where the invoice button within the Point of Sale system was not being properly accounted for. The fix involves adding a test method to ensure the button's functionality is correctly recognized. This ensures accurate invoice generation from Point of Sale transactions.
Original PR description
This commit adds a method used in some tests. runbot-error: 238505 Enterprise PR: https://github.com/odoo/enterprise/pull/110171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual issue where empty options were being saved and displayed in dropdown selectors within the BuilderList. The change ensures that empty selections are no longer persisted, improving the user experience and data consistency. This was caused by a previous code adjustment.
Original PR description
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown…
**Description of the problem** Before this commit, the user could entry empty many2one options in a form, and these would be saved and displayed in the website as empty entries in a dropdown selector. **How to reproduce the problem** 1. Drop a form 2. Add a "Selection" field (many2one) 3. Clear the text in one of the options in "Option List" 4. Save 5. The empty option is not removed, and shows up in the dropdown selector **Why the problem happens** Commit [1] introduced some changes to the action `SetFormCustomFieldValueListAction`, as a result, empty many2one options are not dropped anymore on apply. **Solution** The solution is applied on `BuilderList` (not only forms), as required by the task. `BuilderList.handleValueChange` now drops empty text fields before commiting changes, unless this violates `props.forbidLastItemRemoval`. The form action `setFormCustomFieldValueList` is changed such that the last entry is never removed even if its text is empty (unless `props.forbidLastItemRemoval` is false). task-5925171 [1]: https://github.com/odoo/odoo/commit/cb8469e9fe73f5c10b4e49d3462e0b23df2a047d Forward-Port-Of: odoo/odoo#249546
This update ensures Odoo complies with new NACHA regulations regarding payment descriptions. Starting March 2026, all payroll payments must include 'PAYROLL' in the Company Entry Description field to avoid potential payment issues. This change ensures continued smooth and compliant payroll processing.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941 Forward-Port-Of: odoo/enterprise#109460
This update corrects a minor syntax error in the PWA service's CSS selector, which was preventing the application from correctly registering during installation. This fix ensures that the PWA installation process works reliably, resolving a potential issue that could have disrupted the user experience. The change targets a known problem in versions 18.0 and 19.0.
Original PR description
Description of the issue/feature this PR addresses:
Fixes a typo in the manifest selector used by the PWA service.
document.querySelector("link[rel=manifest") was missing the closing ], making the selector invalid.
Current behavior before PR:
Calling getManifest() could throw a DOMException due to an invalid CSS selector, preventing manifest retrieval and potentially breaking PWA install flow.
Desired behavior after PR is merged:
getManifest() correctly queries link[rel=manifest], retrieves the manifest URL, and keeps the existing manifest-fetch behavior intact (including test coverage already present in pwa_service.test.js).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251376This update ensures Odoo invoices sent to the AFIP web service (ARCA) comply with their strict requirements for numeric fields like price and quantity. By limiting these values to a maximum of 3 decimal places, we prevent invoice rejections and maintain accurate accounting data. This change aligns with the AFIP specifications and ensures consistent rounding across all monetary amounts within Odoo.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf) Forward-Port-Of: odoo/enterprise#110218 Forward-Port-Of: odoo/enterprise#106509
This update corrects a recent issue where quotation documents with lines having a zero subtotal amount were being discarded during upload. The fix ensures that all lines, including those with zero subtotal, are correctly processed, maintaining accurate quotation data. This resolves a regression introduced in a previous update.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document…
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#253149 Forward-Port-Of: odoo/odoo#251463
This update fixes a bug that prevented users from seeing subtasks within the Kanban mobile view of tasks. The issue stemmed from a missing configuration element, now resolved. This enhancement improves task management visibility for mobile users.
Original PR description
Example of steps: - Install `industry_fsm` - Create a task with a subtask - Enable mobile view with devtools - Open a task - Navigate to sub-tasks tab - Traceback ``` TypeError: undefined is not an object (evaluating 'ctx['record'].parent_id.raw_value') ``` parent_id was missing from "view_task_kanban" opw-5981990 Forward-Port-Of: odoo/odoo#253623
A bug preventing users from copying their two-factor authentication secret via the portal has been resolved. The update corrected a technical issue related to how the 'Copy' button's functionality was implemented, ensuring users can now reliably access and copy their security codes.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#253314 Forward-Port-Of: odoo/odoo#251429
This update resolves a technical issue preventing correct receipt generation in the l10n_sa_pos module. The fix corrects an incorrect override condition, ensuring receipts are now generated accurately. This improves the user experience for South African POS customers.
Original PR description
With the commit moving receipt template to the backend, an override on the l10n_sa receipt was wrongly modified. This commit fixes the issue by changing the override condition to the correct one. runbot-error: 239134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where contacts without names or email addresses in Odoo's chatter interface were displaying as 'Unnamed'. Now, when a contact lacks this information, the system will automatically show their display name instead, providing a more user-friendly experience. This ensures all contacts are correctly identified within conversations.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#241830 Forward-Port-Of: odoo/odoo#213545
This update resolves an issue where the original product name was incorrectly displayed alongside translated product descriptions on invoices and purchase orders. The fix ensures that only the translated name and description are shown, regardless of the customer's language setting, improving invoice clarity and accuracy. This impacts all users creating invoices and purchase orders.
Original PR description
**Steps to reproduce: 1. Install invoicing app 2. Add French language in the settings 3. Create a customer with language set as French 4. Create a product and define french translations of the name…
**Steps to reproduce: 1. Install invoicing app 2. Add French language in the settings 3. Create a customer with language set as French 4. Create a product and define french translations of the name and the description in Sales tab 5. Create an invoice for that customer and choose the product you created 6. You will find the translated product name and description under the product name 7. Edit the description, save and preview the invoice 8. The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR] **Description of the issue: When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase. **Expected behaviour: User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name. **Why this happens? 1. When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description. 2. After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.] **The fix Added translated_product_name computed field to follow a similar flow as the sale quotation which is already working as intended. Fix is done in Invoice and Purchase. opw-5480494 Forward-Port-Of: odoo/odoo#248401
This update fixes a bug preventing customers from seeing their available payment methods within the customer portal. The issue stemmed from an incorrect configuration that was overlooked. The fix ensures all payment methods are correctly displayed, improving the customer experience and streamlining the payment process.
Original PR description
Versions: --- saas-19.1+ Issue -- Payment methods are not shown in portal page. Cause: --- In #212880 two issues were overlooked: 1. The payment portal entry ID is `payment_methods_portal_entry`, but the `should_show_portal_card` override was using the wrong external ID: `portal_payment_orders`. 2. The payment card should have `is_config_card=True`, which was missed. Because of this, the superclass implementation (which checks `is_config_card`) returns False and hides the card. Setting `is_config_card=True` would normally fix the issue, but it would require updating views for already existing databases. To avoid this, the override is adjusted to not `&` with the parent implementation. In master we can restore the `&` superclass. This change should have no negative impact since the issue only affects versions saas-19.1, saas-19.2 and there should be no custom overrides in saas versions. opw-6013786 Forward-Port-Of: odoo/odoo#253085
This update fixes an issue where 'sandwich leave' calculations involving company-specific public holidays were inaccurate. The fix ensures that all date calculations are properly localized to the company's timezone, guaranteeing the correct leave duration is determined. This improves the reliability of leave requests and reporting.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992 Forward-Port-Of: odoo/odoo#253489 Forward-Port-Of: odoo/odoo#252466
This update ensures accurate calculations for Malaysian e-Invoicing (MyInvois) by setting the prepaid amount to zero for specific document types (credit notes, debit notes, and refunds). This adjustment aligns with MyInvois API requirements, improving compliance and data accuracy for Malaysian transactions.
Original PR description
Currently, the `prepaid_amount` in the UBL export is calculated as `amount_total - amount_residual` for all document types. However, for credit notes, debit notes, and refund notes (both standard and self-billed, corresponding to document type codes 02, 03, 04, 12, 13, and 14), this amount should be 0 to comply with Malaysian e-Invoicing (MyInvois) API requirements. This commit introduces the following fixes: - Sets the `prepaid_amount` to 0 for document types '02', '03', '04', '12', '13', and '14'. - Update the `payable_amount` to the full `invoice.amount_total`. Task-5971843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253321 Forward-Port-Of: odoo/odoo#251915