Tuesday, October 28, 2025
14 changes · saas-18.3
Enhancements to existing features
VoIP searches now better match phone numbers even when they include spaces, hyphens, parentheses, or other formatting characters. This makes it easier for users to find contacts and call history entries using only the digits they remember.
Original PR description
Introduces the `matchPhoneNumber` function, a new utility designed to match search terms against fully formatted phone numbers. The function converts a digit string like "123" into a flexible regex (e.g., /1\D*2\D*3/i) that matches digits regardless of any non-digit characters (spaces, hyphens, parentheses) between them. **Example:** * **SearchTerms**: "123" * **Target**: "+1 (2)-345" * **Match**: "1 (2)-3" Task-5160296
This update makes the bank reconciliation interface more consistent across versions and improves how key action buttons are displayed. It also prevents users from choosing accounts that would create ineffective reconciliation rules and removes duplicate partner information in certain transaction views.
Original PR description
[IMP] account_accountant: css backport To have a consistent css across all version of the new bank rec widget, we decided to backport few changes. backport of:…
[IMP] account_accountant: css backport To have a consistent css across all version of the new bank rec widget, we decided to backport few changes. backport of: https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667 https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e [FIX] account_accountant: restrict some account in the set_account Before this commit, we could select the liquidity account or bank suspense account which could create a reco model for it that would do nothing. [FIX] account_accountant: partner_name Before this commit, when a transaction had no partner_name and some lines with the same partner. When unfolded, we had the info of the partner on the statement line and on the line itself which was a duplicate of information. This commit will change when the line is unfolded so that the partner is visible on the statement line only when there is a partner_name [FIX] account_accountant: payable and receivable button Before this commit, the payable and receivable buttons where on the top line only when the reconcile button was not there anymore. Now We decided to always have them present in secondary next to the reconcile button. no task-id
Resolved issues and error corrections
Repair service products that are configured for online sale are now shown in the website shop and search results. This ensures customers can find and buy repair-related services online as intended, improving storefront accuracy and sales availability.
Original PR description
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product…
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product is ordered 4. Publish the product from the Sales tab 5. Open the website without being signed in 6. Search for that product Observation: ------------------------- The product is not visible on the website shop. Issue: ------------------------- The method `_get_saleable_tracking_types(self)` is used to determine which product service tracking types are considered saleable on the website. However, this method was not defined for repair products, causing them to be excluded from the domain used to fetch saleable products. https://github.com/odoo/odoo/blob/b0203ae02d472bd7522bc21971f0e659766eaffe/addons/website_sale/models/website.py#L301-L308 Solution: ------------------------- Define the `_get_saleable_tracking_types(self)` method for repair products so they are properly included in website listings. opw-5102204 Forward-Port-Of: odoo/odoo#231000
The Documents details panel now reliably shows the email alias management section in list view when an alias is configured. This restores access to folder email alias settings and prevents missing information caused by a previous update.
Original PR description
Steps to Reproduce =================== 1. Set an alias in settings. 2. Go to a folder in Documents. 3. Open document right panel in list view. -> The email alias section in the document detail panel is missing in the list view. Issue ======= The commit [1] unintentionally change few lines of code in forward-port conflict. It removes `mail_alias_domain_count` from the view and we get undefined in JS. After this commit ================== Added required fields for the details panel to the controller mixin in JS to make it stable friendly and simplify usage regardless of view arch. Adapt selectors of `documents kanban: select a range with SHIFT key` test as we always pass `type` from js which groups documents into folder and file. [1] https://github.com/odoo/enterprise/commit/d278f9013113c6de4b3425fecad5d54a9d4d22b9 Task-5045288
Refreshing a signature document no longer hides the Sign Now and Cancel buttons or replaces the document name with “unnamed.” This keeps the signing flow clearer and more reliable for users who reload the page while reviewing a document.
Original PR description
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel…
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs - The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error. - Breadcrumbs were not getting set properly on reload. After: - Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context. - Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`. Impact: - Buttons remain visible after refresh. - Correct document name is shown in breadcrumbs. - Ensures a smoother and more stable user experience when viewing documents. task-4805166 Forward-Port-Of: odoo/enterprise#93589
Creating invoices from multiple sales orders now keeps orders with different fiscal positions on separate draft invoices. This prevents tax and account calculations from being applied using the wrong fiscal setup, improving billing accuracy.
Original PR description
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft…
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft invoice. An invoice can only have one fiscal position. This merging causes unexpected behavior, as the accounts and taxes are computed based on the single (and potentially incorrect) fiscal position of the final invoice, rather than the respective fiscal positions of the originating SOs. Solution: This commit modifies the 'Create Invoices' action to group the selected sale orders by their `fiscal_position_id`. It will now create as many separate draft invoices as there are unique fiscal positions among the selected orders. task: 5188965 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#233119 Forward-Port-Of: odoo/odoo#232821
This fixes a problem where some company accounting setup or upgrade processes could fail when a bank account code prefix was left unset. The system now treats the missing prefix safely, helping affected databases complete accounting migrations without errors.
Original PR description
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False. ```traceback…
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False.
```traceback
module l10n_co: Running migration [$1.0] end-migrate_update_taxes
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/18.0/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/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/18.0/addons/l10n_co/migrations/1.0/end-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('co', company)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
return self._load(template_code, company, install_demo, force_create)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
self._setup_utility_bank_accounts(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 845, in _setup_utility_bank_accounts
accounts = self.env['account.account']._load_records([
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5526, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5430, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-208>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 997, in create
start_code = prefix.ljust(digits - 1, '0') + '1' if len(prefix) < digits else prefix
TypeError: object of type 'bool' has no len()
```
Databases affected by this traceback error:
https://upgrade.odoo.com/odoo/request/3191023/tbg/2150
task-5167397
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232169Warehouse creation no longer creates many duplicate global replenishment routes when an existing route has been renamed for a company. This keeps inventory configuration cleaner and prevents confusing duplicate route records for users managing multiple warehouses or companies.
Original PR description
In _find_or_create_global_route, use the asked 'route_name' instead of the potentially modified name of `data_route`. This ensures that if '_find_or_create_global_route' is called with the exact same values a new route will not be re-created. https://github.com/user-attachments/assets/815adf60-aa2d-4699-a79d-f9ad9607cbea ## How to reproduce (in runbot 17.0): - Enable "Multi-steps Routes" - Unarchive route "Replenish on Order (MTO)", change the name, set company to "My company (San Francisco)" - Go to "My Company (Chicago)" - Create new Warehouse => Check all the routes: ~100 MTO routes with the modified name have been created. OPW-5149842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232829 Forward-Port-Of: odoo/odoo#232613
Users now receive a clear warning when trying to send batch invoices while the required scheduled process is disabled. This prevents silent failures and helps administrators quickly enable the needed setting so invoices can be sent as expected.
Original PR description
This commit raises a RedirectWarning to the cron configuration to inform the user that the batch invoice cron must be enabled. Batch invoices cannot be sent if cron is disabled. task-5122707 Current behavior before PR: If batch invoice send is called and cron is disabled, then it will silently fail and not send. Desired behavior after PR is merged: If batch invoice send is called and cron is disabled, then it will raise a RedirectWarning to the cron configuration. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229318
Purchase requests created from approvals now use the currency configured for the product's vendor instead of defaulting to the company's currency. This keeps RFQs consistent with other purchasing flows and helps avoid currency mismatches or incorrect purchase order updates.
Original PR description
Issue: When creating an RFQ from an approval, the created purchase order does not use the currency set on the vendor of the product. Rather, it uses the currency of the company, with the value converted based on the vendor's currency to get the price. This is not consistent with other ways we create RFQs, which all respect the vendor currency. Solution: Pass the vendor's currency into the values sent when creating the purchase order. In the case of modifying an existing purchase order, only modify purchase orders matching vendor's currency. opw-4549937 Forward-Port-Of: odoo/enterprise#97069
This fixes a UPS shipping label issue where missing sender or shipper VAT details could block label creation in production. The change avoids sending an empty tax ID value that UPS rejects, helping businesses generate labels reliably even when VAT information is not available.
Original PR description
Only in production mode, if the sender or the shipper's VAT was not set, the UPS answer would be an error, preventing the label generation altogether. This is because we send an empty string if the VAT was not set, and UPS couldn't process it. Forward-Port-Of: odoo/enterprise#98227
Saudi e-invoicing checks now also run when a company has no country set, catching setup issues before documents are processed. This helps avoid errors that could stop scheduled EDI web service operations from running for affected companies.
Original PR description
ZATCA invoice misconfigurations are only checked for if the company has Saudi Arabia set as its country. However, ZATCA EDIs can be generated without Saudi Arabia set as the country. Thus, companies without a company set can create EDI documents for misconfigured invoices. This may cause traceback errors which prevent the "EDI : Perform web services operations" cron from running at all. This commit ensures that configuration checks are run on companies without countries set (and adds a relevant unit test). opw-5057792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233078 Forward-Port-Of: odoo/odoo#231255
This fix improves work entry generation for employees who have different types of working schedules, including fully flexible schedules without a calendar. It helps ensure payroll and attendance-related entries are created using the right schedule and timezone, reducing incorrect or missing work entries.
Original PR description
- fix work entries generation for employees with different working schedules types - made work entries generation check for employee timezone in case the employee is fully flexible and doesn't have a calendar - added method `_get_calendar_at` to get the calendar of the resource at a given date - added `test_work_entry_different_calendars` for work entries generation for employees with contracts with different calendar types task-id: 5065160 Forward-Port-Of: odoo/odoo#232828 Forward-Port-Of: odoo/odoo#226641
Bank synchronization now avoids importing transactions on a company's accounting lock date, preventing entries and opening balances from being created with incorrect dates. This helps keep financial records consistent with locked-period rules and reduces reconciliation issues.
Original PR description
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing…
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date. As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date). Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction. The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created. To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day. Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes. opw-4890538 Forward-Port-Of: odoo/enterprise#94648 Forward-Port-Of: odoo/enterprise#93543