Daily updates from Odoo
Tuesday, October 28, 2025
163 changes
19 changes
Resolved issues and error corrections
This fix prevents users from adding tax tags to journal items dated before the tax lock date. It helps ensure locked tax reports cannot be changed unintentionally after a reporting period is closed.
Original PR description
Despite the tax lock date, users are able to modify the tax report by adding tags.
**Steps to reproduce:**
Ensure the tax lock date is set
1. Journal Items list view
2. Edit one/many lines that
- have a date before the tax lock date,
- don't have a tax,
- nor tax tags,
- and is not a tax line.
3. Add a new tax tag
**Issue:**
The tax tags are added and might impact a tax report, when you should have received a user error.
**Cause:**
The `write` function calls the `_check_tax_lock_date` which in turn only checks the existing line instead of the values given in the `write` parameters. Since the line has no existing tax tags the check does not fail.
**Solution:**
Call the tax lock check both before and after writing the move line.
Task-5169152
Forward-Port-Of: odoo/odoo#233032
Forward-Port-Of: odoo/odoo#232380Fixed a point of sale issue where selecting details within an order line could make the numpad open and immediately close. Cashiers can now use the numpad reliably when working with order line details such as eWallet balances.
Original PR description
Steps to reproduce: =================== - Click on an orderline - Then click on a detail inside it (e.g., eWallet Balance line) - The numpad first opens and then closes right away Issue: ====== - Clicking on a detail inside the orderline makes the numpad open and close at the same time - This makes it impossible to use the numpad properly Cause: ====== - The click from the child element also reaches the main orderline click - Because of this, the numpad gets two clicks (open and close) Fix: ==== - Added `stopPropagation` in the click handler to block event bubbling - Now the numpad only reacts once and stays open as expected Task: 5000327 Forward-Port-Of: odoo/odoo#232197 Forward-Port-Of: odoo/odoo#227675
This update removes duplicate validation rules for mail link previews that could interfere with database restores between PostgreSQL versions. It helps prevent restore issues for future databases while keeping the existing mail behavior unchanged.
Original PR description
Same as #229274 these constraints are redundant with `required=True` and cause issues when restoring a dump from pg17 to pg18. And much like #229274 this only fixes databases going forward, on existing databases the constraints have to be dropped on the source. Forward-Port-Of: odoo/odoo#233186
Creating invoices from multiple sales orders now keeps orders with different fiscal positions on separate draft invoices. This prevents incorrect tax or account calculations caused by combining orders that must follow different fiscal rules.
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
Repair service products that are published for sale now show up correctly in the website shop. This fixes a visibility issue that prevented customers from finding and buying services configured to create repair orders.
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#232154 Forward-Port-Of: odoo/odoo#231000
This fixes an issue where some browser pages could make Odoo mistakenly think the signed-in user had changed, causing real-time notification channels to be cleared. Users should now keep receiving their own presence updates reliably, including when sessions are opened or closed in other browser windows.
Original PR description
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing…
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing the worker to incorrectly mark the user as changed. This clears previous channels, which may never be added back. This is particularly noticeable with presence channels: the user's own channel can be lost, preventing them from receiving their own presence updates (e.g. when another browser closes, the user cannot see they are disconnected and cannot correct the value). The user's own presence channel should be added server-side, so the first subscription immediately returns the user presence and the DB should not be taken into account if ommited. task-5096212 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#233182 Forward-Port-Of: odoo/odoo#232984
This update prevents an accounting process from failing when it encounters an empty value where a number is expected. It improves reliability by avoiding an unnecessary error for users working with accounting entries.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232965
Bank reconciliation models now correctly apply label rules that exclude specific text, even when some transaction details are empty. This helps accounting teams rely on automated matching rules more consistently and reduces missed reconciliation matches.
Original PR description
Currently bank reconciliation model match only the label type “Contains” The “not contain” type is not working Steps to reproduce: - Open Accounting Dashboard - Access Bank journal reconciliation models (3dots > Models) - Open a [Model] and set: - Label "Not Contains" "Test" - Add a Bank Statement with any label Issue: [Model] won't match Analysis: This occurs because in case the payment_ref or transaction_details contains a NULL value the ILIKE operations will evaluate to NULL, not TRUE or FALSE. Any other comparison involving NULL value will result in NULL and the whole condition will fail opw-5065006 [Task link](https://www.odoo.com/odoo/project/49/tasks/5065006) Forward-Port-Of: odoo/enterprise#97745
Sale orders that use only fixed taxes can now be read through XML-RPC without serialization errors. This prevents integrations and external tools from failing when accessing orders or invoices with this tax setup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232955 Forward-Port-Of: odoo/odoo#232517
Draft sales orders now keep product lines editable when users return to an order. This prevents clicks on a product line from unexpectedly opening the product record, making it easier to change products or add descriptions.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a sales order; 2. add a product that doesn't have an extra description; 3. save & exit view; 4. go back to view; 5. add a description or change the product on the line. Issue ----- Clicking on the product field opens the product record instead of edit mode. Cause ----- It opens the product record because the `canOpen` property is set to `true`. As this is the default value, and isn't getting changed anywhere, the line will always open the product record outside of edit mode. Solution -------- Instead of using OR, check `props.canOpen` AND additional checks. opw-5172115 Forward-Port-Of: odoo/odoo#232861
Creating a new warehouse could accidentally generate many duplicate replenishment routes when an existing global route had been renamed. This fix ensures Odoo reuses the intended route instead, keeping route lists clean and avoiding confusion for inventory teams.
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
Batch invoice sending now alerts users when the required scheduled process is turned off, instead of failing silently. Administrators are guided to the relevant configuration so they can re-enable it, helping prevent missed invoice deliveries.
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
Quality checks could fail in setups where manufacturing quality is installed without work orders. This change avoids checking a work-order-specific field unless the related module is available, preventing errors when creating or validating quality points.
Original PR description
**Issue:** The attribute operation_id for quality.point is defined in the mrp_workorder module. However, quality_mrp module does not list mrp_workorder in its dependencies. As a result in a system where quality_mrp is installed but mrp_workorder is not, the following error is raised when evaluating the constrain for quality points mesured on Operations. `"'quality.point' object has no attribute 'operation_id'"` **Proposed solution:** Override the constraint in quality_mrp_workorder to include conditions related to operation_id, ensuring that it is only evaluated when the field is available. Forward-Port-Of: odoo/enterprise#97801 Forward-Port-Of: odoo/enterprise#97338
RFQs created from approvals now use the currency configured on the product's vendor instead of defaulting to the company's currency. This keeps purchase requests consistent with other RFQ creation flows and helps avoid pricing or currency mismatches when working with vendors.
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 update fixes an intermittent automated test failure in the barcode module by ensuring the screen has finished updating before checks run. It improves confidence in release validation without changing any customer-facing barcode behavior.
Original PR description
This commit fixes a test that sometimes failed, because we didn't wait for an animationFrame after the macro was complete. As a consequence, there was no guarantee that the form view had been updated before the check. runbot error~226829 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#233153
Contacts can no longer be deleted when they are already connected to point-of-sale orders. This preserves customer information on past sales records and prevents accidental loss of order history links.
Original PR description
Before this commit, it was possible to delete a contact record even if it was linked to PoS orders, which would cause it to be unlinked from those orders. opw-5164368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231812 Forward-Port-Of: odoo/odoo#231442
UPS shipping labels could fail to generate in production when the sender or shipper did not have a VAT number set. This fix avoids sending an empty tax ID to UPS, so label creation can continue normally for affected shipments.
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
This update adds a safeguard to ensure changes to a company's phone number do not unintentionally alter employee information. It helps keep employee contact details stable and prevents confusion when company-level contact data is updated.
Original PR description
Added a test to complement the fix made in this PR: https://github.com/odoo/odoo/pull/229010 opw-5072108
The Documents details panel now consistently shows the email alias management section in list view when an alias is configured. This fixes a regression that could hide alias information and improves stability by ensuring the panel always receives the fields it needs.
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 Forward-Port-Of: odoo/enterprise#93401
14 changes
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 update prevents an accounting screen from showing an error when an expected number field is left empty. It helps users continue their workflow without being blocked by a technical message.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232965
Task times in the Field Service map sidebar now stay on one line and use the proper short time format. This makes scheduled task times easier to read at a glance without changing the existing map layout.
Original PR description
### Steps to Reproduce 1. Open Field Service app 2. Navigate to My Tasks -> Map 3. Observe task pins in the left sidebar list 4. Notice time displays like "10:00" break across multiple lines ### Issue The formatted time display in FSM task map pin list items wraps to multiple lines. ### Current Behaviour Time displays like "10:00" break into separate lines. ### Expected Behaviour Time should display on a single line as one readable unit ### Fix Add text-nowrap class to the time display span in FsmTaskMapRenderer template. This prevents line breaks while preserving the existing layout structure. Task - 5079360
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
Companies marked with a non-applicable VAT value can now connect to CodaBox using their company registry number instead. This prevents connection issues for Belgian companies that are not subject to VAT and aligns the behavior with companies that leave the VAT field empty.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155 Forward-Port-Of: odoo/enterprise#98025
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
This fix prevents an error when Quality for Manufacturing is used without the Work Orders feature installed. Quality checks can now be configured without the system looking for a field that is only available in another module, improving reliability for affected setups.
Original PR description
**Issue:** The attribute operation_id for quality.point is defined in the mrp_workorder module. However, quality_mrp module does not list mrp_workorder in its dependencies. As a result in a system where quality_mrp is installed but mrp_workorder is not, the following error is raised when evaluating the constrain for quality points mesured on Operations. `"'quality.point' object has no attribute 'operation_id'"` **Proposed solution:** Override the constraint in quality_mrp_workorder to include conditions related to operation_id, ensuring that it is only evaluated when the field is available. Forward-Port-Of: odoo/enterprise#97801 Forward-Port-Of: odoo/enterprise#97338
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 update fixes an intermittent automated test failure in the Barcodes app by ensuring the screen has finished updating before the test verifies results. It helps keep quality checks stable and reduces false failures during development and release validation.
Original PR description
This commit fixes a test that sometimes failed, because we didn't wait for an animationFrame after the macro was complete. As a consequence, there was no guarantee that the form view had been updated before the check. runbot error~226829 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#233153
Fixed an issue where website form fields could disappear when their visibility depended on another field whose name included the "|" character. This makes conditional form behavior more reliable and allows businesses to use any characters in form field labels without breaking the form.
Original PR description
Before this commit, after selecting a field containing the char "|" for conditional display, the field on which the condition is set will never appear again. This commit enable the use of any characters in form fields Steps to reproduce the bug: - Add a form - Add two fields (A and B) - Rename the field A with a string that contains "|" - Set the field B visibility to "Visible only if" - Set the field A as the visibility condition for field B (field B visible only if field A contains 'hello', for example) - Save the changes - Complete the field A according to the visibility condition (The second field does not appear) task-3893749 Forward-Port-Of: odoo/odoo#181275
4 changes
Resolved issues and error corrections
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 clear and stable for users who reload the page.
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
RFQs created from approvals now use the currency configured for the product's vendor instead of defaulting to the company currency. This keeps purchasing documents consistent with other RFQ creation flows and helps avoid currency and price mismatches.
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 Lithuanian payroll calculations so employees enrolled in pension accumulation are not charged the pension contribution twice. Payslips will now reflect the expected social security contribution, helping avoid payroll over-deductions and correction work.
Original PR description
**Issue**
When generating a payslip for an employee with the `l10n_lt_pension` setting enabled on the contract ("Participate to pension accumulation system"):
- the SSC is raised from 19.5% to 22.5%
- a 3% pension contribution ("Pension Scheme") is added This effectively doubles the expected contribution.
Various sources (e.g. https://taxsummaries.pwc.com/lithuania/individual/other-taxes) seem to show this is not correct.
opw-5067664
Forward-Port-Of: odoo/enterprise#95880This fix prevents UPS label generation from failing when sender or shipper VAT details are not provided. It avoids sending blank tax ID values that UPS rejects in production, helping deliveries continue without unnecessary errors.
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
18 changes
Resolved issues and error corrections
This fix ensures Brazilian AvaTax users see the custom product list views needed to correct tax-related product data. It restores access to key Brazilian fields, inline editing, and product navigation, avoiding an unsuitable standard product list.
Original PR description
The actionable_errors widget was changed to ignore views if a view_mode key is present in the action [1]. It caused the standard product.product list view to pop up, which doesn't work in this case. The custom views have the relevant Brazilian fields (SPED type etc), can be edited inline, and have a "View" button allowing the user to go to the product form view. The standard view has none of these. [1] odoo/odoo@3bd833c73ea654d8558e3d9701ad41e4d75ddd6 opw-5154766 Forward-Port-Of: odoo/enterprise#98012
The checkout address test now waits until the relevant page interaction is ready before moving to the billing step. This prevents false failures in automated checks and helps keep the online sales workflow validation stable.
Original PR description
This commit add wait for intreaction to be ready before moving to billing step which render billing container conditionally depending on toggle from interaction. runbot-231718 Forward-Port-Of: odoo/enterprise#98142
Invoices paid with a partial amount from the invoice payment widget will now stay marked as partially paid instead of being automatically closed with a write-off. This helps users keep control of small remaining balances and avoid unintended accounting adjustments.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Bank reconciliation models now correctly match statement lines when a label rule is set to “Not Contains,” even if some transaction text fields are empty. This helps accounting teams rely on exclusion-based matching rules and reduces manual reconciliation work.
Original PR description
Currently bank reconciliation model match only the label type “Contains” The “not contain” type is not working Steps to reproduce: - Open Accounting Dashboard - Access Bank journal reconciliation models (3dots > Models) - Open a [Model] and set: - Label "Not Contains" "Test" - Add a Bank Statement with any label Issue: [Model] won't match Analysis: This occurs because in case the payment_ref or transaction_details contains a NULL value the ILIKE operations will evaluate to NULL, not TRUE or FALSE. Any other comparison involving NULL value will result in NULL and the whole condition will fail opw-5065006 [Task link](https://www.odoo.com/odoo/project/49/tasks/5065006) Forward-Port-Of: odoo/enterprise#97745
This update fixes issues in Colombian electronic invoicing where new vendor bills could miss their commercial status, repeated event submissions could block the process, and issuer acceptance events could be rejected by DIAN. This helps accounting teams process vendor bills and compliance events more reliably.
Original PR description
this commit solves following issues: - the commercial status was missing on newly created vendor bills - the flow got stuck when an event had already been sent and we tried to send it again - The accept by issuer event generated errors on DIAN's side task: 5064534 Forward-Port-Of: odoo/enterprise#95444
This fixes an error that could occur when setting up quality checks for manufacturing operations in systems without the work order feature installed. The change keeps quality management usable in those configurations by only applying operation-specific checks when the related feature is available.
Original PR description
**Issue:** The attribute operation_id for quality.point is defined in the mrp_workorder module. However, quality_mrp module does not list mrp_workorder in its dependencies. As a result in a system where quality_mrp is installed but mrp_workorder is not, the following error is raised when evaluating the constrain for quality points mesured on Operations. `"'quality.point' object has no attribute 'operation_id'"` **Proposed solution:** Override the constraint in quality_mrp_workorder to include conditions related to operation_id, ensuring that it is only evaluated when the field is available. Forward-Port-Of: odoo/enterprise#97801 Forward-Port-Of: odoo/enterprise#97338
Fixed an issue where partially paid subscription upsell orders could show a down payment invoice amount of zero instead of the actual paid amount. This ensures customers and businesses see accurate invoiced amounts for partial online payments on upsell orders.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97571 Forward-Port-Of: odoo/enterprise#96719
UPS shipping labels could fail to generate in production when a sender or shipper VAT number was not entered. This change avoids sending an empty tax ID to UPS, allowing labels to be created when VAT information is unavailable.
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
Belgian point of sale configurations no longer show the tip product setting. This prevents businesses in Belgium from seeing or configuring an option that is not applicable to their local compliance flow.
Original PR description
- Hide `tip_product` field in `pos_config` form view when country is Belgium. task-id: 5011427 community PR: https://github.com/odoo/odoo/pull/233162
Studio no longer allows users to set default values on fields that are defined as readonly. This prevents configuration choices that could cause inconsistent behavior or errors in business records where those defaults are not properly supported.
Original PR description
Before this commit, it was possible to set via Studio a default value for readonly fields. Functionally, this opened the floor for a variety of issues when the user set a default value that way on models that did not handle that (by providing a default in the Action or some other way) Decision has been made to remove that feature for fields defined in python as readonly. Task-5172619
The AI document sorting wizard now uses option formatting that is consistent with the rest of the system. This helps prevent invalid option handling and reduces the chance of errors when users configure AI document sorting.
Original PR description
Purpose ======= PyJs can parse dictionaries, even if each element does not end with `,`. We didn't use them in ai documents, but for consistency, we now added them. Forward-Port-Of: odoo/enterprise#98166
Opening the invoicing dashboard no longer fails when Stripe card issuing is enabled but the company only has currencies unsupported by Stripe active. The system now avoids creating or selecting Stripe issuing journals unless a valid supported currency is available, improving reliability for localized company setups.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to replicate:** * Install `account` without demo * Set Company currency to INR and deactivate USD in currencies. * Install `hr_expense_stripe` > Open Invoicing you will get the error. `ValueError: Expected singleton: res.currency()` **RootCause:** * When `hr_expense_stripe` is installed, the compute method [1] checks for supported currencies and defaults to USD if none are found. But since USD is often inactive by default in localized online databases, `stripe_currency_id` ends up empty . * Which causes [2] to pass an empty `stripe_currency_id` to [3], which expects at least one record, leading to the error. **Solution:** * Avoid creation of stripe issuance journal during installation when currency is not supported. * Add a constraint to check if stripe currency is valid for creating stripe issuance journal. * prevent creation and selection of journal for stripe issuing from settings. * [Reference Images](https://www.notion.so/Changes-in-Stripe-issuing-unsupported-vs-supported-2856722d865e803e8da1ece29cce7582?source=copy_link) for before and after functionality [1]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/res_company.py#L72 [2]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/account_journal.py#L52 [3]: https://github.com/odoo/odoo/blob/98bae80f57733162c67593539ef47dfd0c6d8797/odoo/addons/base/models/res_currency.py#L205 sentry-6916946380 Forward-Port-Of: odoo/enterprise#96271
Fixes an error that occurred when HR signed an offer for an employee who requested extra time off while automatic allocation was enabled. This helps HR teams complete salary package offers reliably without manual workarounds.
Original PR description
- When the employee requested extra time off, and the automatic allocation setting was turned on, signing the offer as the responsible HR caused an error. Task-5022631 Forward-Port-Of: odoo/enterprise#98209 Forward-Port-Of: odoo/enterprise#92663
This update prevents users from directly modifying the database users list in a way that should not be allowed. It helps keep database project records consistent and avoids unintended changes through the user interface.
Original PR description
This commit is the counter part of odoo/odoo#231902 which allows to disable the write action on x2many fields. See [1] for details. [1] https://github.com/odoo/enterprise/pull/94207#discussion_r2378129896 Task~5160367 Forward-Port-Of: odoo/enterprise#97371
Changing rental dates in the online cart now keeps the cart layout stable and preserves interactive quantity controls. This prevents shoppers from getting stuck when adjusting rental periods, improving checkout reliability.
Original PR description
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and…
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and quantity buttons become unclickable. Cause: ====== Two separate issues caused this behavior: 1. **Layout shift:** When updating the date range, `cart_quantity` can be undefined. The logic that determines whether to toggle the `col-lg-7` class relies on this value. When undefined, it incorrectly assumes the cart is empty and shifts the layout to the left. 2. **Unclickable buttons:** The following line replaces the entire `.js_cart_lines` element: https://github.com/odoo/odoo/blob/abf9bc083c5a219a0b6fc0346dcd2a2cb503e081/addons/website_sale/static/src/js/website_sale_utils.js#L88 This removes all old elements (and their event listeners) and inserts new ones from the server. As a result, interactive buttons (e.g., quantity update) lose their functionality. Older versions didn't face this issue because they used jQuery event delegation, which automatically handled dynamic elements. Solution: ========= 1. provide the cart_quantity value via the controller, 2. Restart the cart interaction after re-rendering to restore event bindings for clickable buttons. opw-5167866 Forward-Port-Of: odoo/enterprise#97715
This fixes a settings issue where users could be blocked from saving inventory shipping settings after turning off text confirmation. The WhatsApp template is now only required when WhatsApp text confirmation is actually enabled, preventing unnecessary validation errors.
Original PR description
Due to this [commit](https://github.com/odoo/enterprise/commit/fd1799dd8e3e190e894914d0c28d77d709e29eb6), The field ```stock_confirmation_wa_template_id``` is visible only when…
Due to this [commit](https://github.com/odoo/enterprise/commit/fd1799dd8e3e190e894914d0c28d77d709e29eb6), The field ```stock_confirmation_wa_template_id``` is visible only when ```stock_confirmation_type``` is set to whatsapp and ```tock_text_confirmation``` is set to True. However, the field ```stock_confirmation_wa_template_id``` is marked as required whenever ```stock_confirmation_type``` is set to whatsapp, regardless of whether ```stock_text_confirmation``` is enabled. As a result, when saving the record with ```stock_text_confirmation``` unchecked, the required field ```stock_confirmation_wa_template_id``` remains invisible and unset — which causes a missing required field error during record save. Steps to reproduce: [Video](https://drive.google.com/file/d/1XVV4mJjSX_8acDDbv83VtWrbZtYz6Kqg/view) 1. go to settings - inventory - shipping 2. check Text Confirmation , set stock_confirmation_type = whatsapp 3. uncheck Text confirmation 4. save the changes To fix this issue, need to just add condition of ```stock_text_confirmation``` Forward-Port-Of: odoo/enterprise#97200
The Field Service map task list now keeps appointment times such as 10:00 on a single line. This makes the sidebar easier to read and avoids confusing broken time displays for users planning field work.
Original PR description
### Steps to Reproduce 1. Open Field Service app 2. Navigate to My Tasks -> Map 3. Observe task pins in the left sidebar list 4. Notice time displays like "10:00" break across multiple lines ### Issue The formatted time display in FSM task map pin list items wraps to multiple lines. ### Current Behaviour Time displays like "10:00" break into separate lines. ### Expected Behaviour Time should display on a single line as one readable unit ### Fix Add text-nowrap class to the time display span in FsmTaskMapRenderer template. This prevents line breaks while preserving the existing layout structure. Task - 5079360 Forward-Port-Of: odoo/enterprise#94778
The Approvals test setup was adjusted so it no longer creates duplicate approvers when demo data is installed. This keeps automated quality checks stable across environments and helps prevent avoidable test failures during releases.
Original PR description
When running with demo data, the tests `test_compute_request_status` and `test_compute_request_status_with_required` fail with the error: `UniqueViolation: duplicate key value violates unique constraint "approval_approver_unique_request_user"` This happens because the category "Business Trip" (`approvals.approval_category_data_business_trip`) already injects approvers into the approval request. The two failing tests were creating additional approvers for the same users, leading to a UNIQUE constraint violation on (request_id, user_id). This commit resets the request approvers (`record.approver_ids = []`) before adding the test-specific approvers, ensuring the test passes both with and without demo data. [RB-230935](https://runbot.odoo.com/odoo/error/230935) Forward-Port-Of: odoo/enterprise#95897
28 changes
Resolved issues and error corrections
This fixes the Brazilian AvaTax product error workflow so users are shown the tailored product list again instead of a generic product list. The restored view includes Brazil-specific tax fields, inline editing, and an easy path to open product details, helping users resolve tax setup issues correctly.
Original PR description
The actionable_errors widget was changed to ignore views if a view_mode key is present in the action [1]. It caused the standard product.product list view to pop up, which doesn't work in this case. The custom views have the relevant Brazilian fields (SPED type etc), can be edited inline, and have a "View" button allowing the user to go to the product form view. The standard view has none of these. [1] odoo/odoo@3bd833c73ea654d8558e3d9701ad41e4d75ddd6 opw-5154766 Forward-Port-Of: odoo/enterprise#98012
Down payment invoices for subscription upsell orders now show the amount actually paid instead of incorrectly displaying zero. This helps customers and staff see accurate billing information when partial online payments are used.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97571 Forward-Port-Of: odoo/enterprise#96719
This fixes an issue where validating a partial barcode transfer into another package could incorrectly fail with a missing lot or serial number error. Businesses using lot-valued inventory can now split packaged quantities more reliably without being blocked during warehouse validation.
Original PR description
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to…
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to reproduce:** - Create product tracked by lot and valued by lot/SN. - Set on on hand quantity of 100 in stock with a package that you create and a lot that you create. - Create an internal transfer for 100 of this product. - Mark it as to do. - Open it in barcode. - Scan stock. - Scan the package. - Edit the line to quantity of 50. - Scan any other empty package already existing to set it as the delivery package. - Validate. - On the incomplete transfer widget, also click on validate. **Current behavior:** An error 'Lot/Serial number is mandatory for product valuated by lot' is triggered even though there is a lot on the line. **Cause of the issue:** When _assignEmptyPackage() is called to assign the new package, it calls shouldsplitline() which returns true because line.qty_done is smaller thant line.reserved_uom_qty https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/stock_barcode/static/src/models/barcode_picking_model.js#L949-52 Therefore, splitLine() is called and a new line is created with no package and no lot. Then, when we validate, _action_done() is called on the move which calls _action_done() on the move lines. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock/models/stock_move.py#L2065 In the stock_account override, the error is raised for the line newly created because it has no lot_id and no lot_name. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock_account/models/stock_move_line.py#L90-L91 opw-5028008 Forward-Port-Of: odoo/odoo#233129 Forward-Port-Of: odoo/odoo#231482
Users can now open an AI chat from the AI app even when several chats with the same AI agent are already open. This prevents an error that interrupted the workflow and makes the AI app behavior consistent with opening chats from the system tray.
Original PR description
Currently an error occurs when user tries to open an ai chat through the ai app while having a few ai chats open from the same ai agent. **Steps to replicate:** - Install `ai_app` and open AI app. -…
Currently an error occurs when user tries to open an ai chat through the ai app while having a few ai chats open from the same ai agent. **Steps to replicate:** - Install `ai_app` and open AI app. - Click on the AI icon in the system tray, open two chat windows. - Click on the `Ask AI` kanban card, the error will occur. **Error:** `ValueError: Expected singleton: discuss.channel(69, 70)` **Cause:** - Error occurs because there are already a few discuss channels active that are linked to the same ai agent, and the search query [1] returns multiple ids and ultimately multiple ids will be received at the the line [2] and cause the singleton error. **Solution:** - Ensure that only the first matching discuss channel is returned for a given AI agent when multiple channels exist. - Changed the method `action_ask_ai()` to always open a new ai chat, similar to when we click the ai icon in systray to maintain consistency. [1]: https://github.com/odoo/enterprise/blob/6b1c54d8a1c3b27e72a17d9984e632cc4afd8b64/ai/models/ai_agent.py#L686-L689 [2]: https://github.com/odoo/enterprise/blob/6b1c54d8a1c3b27e72a17d9984e632cc4afd8b64/ai/models/ai_agent.py#L432 **sentry-6849936794**
The point of sale iMin cashbox now uses the correct connection status before opening. This restores cash drawer opening for businesses using iMin hardware and prevents failed cashbox actions at checkout.
Original PR description
Explanation: openCashbox() is calling this.connected to check if iMin is connected. However the variable is changed to isConnected in the previous PR. Therefore it will always return null.
This change removes redundant validation rules in the mail module that could block database restores between PostgreSQL versions. It helps reduce upgrade and recovery issues for future databases, while existing databases may still need a manual cleanup before restoring.
Original PR description
Same as #229274 these constraints are redundant with `required=True` and cause issues when restoring a dump from pg17 to pg18. And much like #229274 this only fixes databases going forward, on existing databases the constraints have to be dropped on the source. Forward-Port-Of: odoo/odoo#233186
Creating invoices from multiple sales orders now keeps orders with different fiscal positions on separate draft invoices. This prevents incorrect tax or account calculations when orders require different fiscal treatment.
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 Odoo's automatic invoice sending could stop when a Spanish VeriFactu credit note was linked to an invoice without VeriFactu data. The process now skips affected records and reports them properly, so other invoices can still be sent automatically.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#232763 Forward-Port-Of: odoo/odoo#230762
This fix prevents an accounting screen or process from failing when it encounters an empty value where a number is expected. It helps users continue their accounting work without seeing an unexpected error message.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232965
Generating the pricelist report no longer crashes when no pricelist exists. Instead, users are told to configure at least one pricelist first, making the issue clear and easier to resolve.
Original PR description
Current behavior before PR: Generating the Pricelist Report raises a JavaScript error — Cannot read properties of undefined (reading 'id') — when there is no pricelist in the database. Desired behavior after PR is merged: Instead of crashing, the system now validates the presence of at least one pricelist. If none is found, it raises a clear UserError message: “Please configure at least one Pricelist before generating the report.” This prevents the crash and guides the user to properly configure pricelists before running the report. Issue : https://github.com/odoo/odoo/issues/233393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Generating the pricelist report now checks whether at least one pricelist exists before continuing. If none is configured, users see a clear message explaining what needs to be set up instead of encountering a confusing crash.
Original PR description
Current behavior before PR: Generating the Pricelist Report raises a JavaScript error — Cannot read properties of undefined (reading 'id') — when there is no pricelist in the database. Desired behavior after PR is merged: Instead of crashing, the system now validates the presence of at least one pricelist. If none is found, it raises a clear UserError message: “Please configure at least one Pricelist before generating the report.” This prevents the crash and guides the user to properly configure pricelists before running the report. Issue : https://github.com/odoo/odoo/issues/233393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes event registrations where Google's verification could expire if someone took more than two minutes to complete a long form. Attendees can now finish longer sign-up forms without being blocked by an expired verification check.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to fix the timeout issue coming up for google recaptcha when the event registration form filing exceeds 2 mins(timeout value for google recaptcha tokens) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes inventory valuation for average-cost products when stock is scrapped using a packaging unit such as a pack of 6. Reports now subtract the correct quantity and value, helping businesses avoid overstated inventory values and inaccurate stock accounting.
Original PR description
**Steps to reproduce:** - Create a storable product. - Set the category as avco. - Set the cost to 10 - Set an on hand quantity of 10 - In the Sales tab, add 'pack of 6' to the packagings - Create a new scrap - Scrap 1 pack of 6 of this product - Open reporting/stock and search your product **Current behavior:** The value is 90 **Expected behavior:** It should be 40 **Cause of the issue:** get_valued_qty does not take into account the uom opw-5160608
Opening the invoicing dashboard no longer fails when Stripe expense card issuing is enabled but the company only has unsupported currencies active. The system now avoids creating or selecting Stripe issuing journals unless a valid supported currency is available, reducing setup disruptions for localized companies.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to replicate:** * Install `account` without demo * Set Company currency to INR and deactivate USD in currencies. * Install `hr_expense_stripe` > Open Invoicing you will get the error. `ValueError: Expected singleton: res.currency()` **RootCause:** * When `hr_expense_stripe` is installed, the compute method [1] checks for supported currencies and defaults to USD if none are found. But since USD is often inactive by default in localized online databases, `stripe_currency_id` ends up empty . * Which causes [2] to pass an empty `stripe_currency_id` to [3], which expects at least one record, leading to the error. **Solution:** * Avoid creation of stripe issuance journal during installation when currency is not supported. * Add a constraint to check if stripe currency is valid for creating stripe issuance journal. * prevent creation and selection of journal for stripe issuing from settings. * [Reference Images](https://www.notion.so/Changes-in-Stripe-issuing-unsupported-vs-supported-2856722d865e803e8da1ece29cce7582?source=copy_link) for before and after functionality [1]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/res_company.py#L72 [2]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/account_journal.py#L52 [3]: https://github.com/odoo/odoo/blob/98bae80f57733162c67593539ef47dfd0c6d8797/odoo/addons/base/models/res_currency.py#L205 sentry-6916946380
This fix ensures certain maintenance commands run without starting or configuring the web server. It prevents unnecessary warning messages, making command-line operations quieter and clearer for administrators.
Original PR description
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 fix ensures certain service transactions involving customers in the Canary Islands are assigned the correct Spanish tax reporting key. It helps businesses produce more accurate TicketBAI electronic tax records and reduces the risk of reporting errors.
Original PR description
We check that if the partner is from Canary Islands and we put a no sujeto por reglas de localizacion tax (so for services) we put the 08 key. opw-5099749 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
The AI document sorting wizard was updated so its options are formatted consistently and can be parsed correctly. This helps prevent errors when users configure AI-based document sorting, with no expected change to normal workflows.
Original PR description
Purpose ======= PyJs can parse dictionaries, even if each element does not end with `,`. We didn't use them in ai documents, but for consistency, we now added them.
This fixes a settings issue where users could not save inventory shipping settings after turning off text confirmation for WhatsApp. The WhatsApp template is now only required when text confirmation is enabled, preventing an unnecessary validation error.
Original PR description
Due to this [commit](https://github.com/odoo/enterprise/commit/fd1799dd8e3e190e894914d0c28d77d709e29eb6), The field ```stock_confirmation_wa_template_id``` is visible only when…
Due to this [commit](https://github.com/odoo/enterprise/commit/fd1799dd8e3e190e894914d0c28d77d709e29eb6), The field ```stock_confirmation_wa_template_id``` is visible only when ```stock_confirmation_type``` is set to whatsapp and ```tock_text_confirmation``` is set to True. However, the field ```stock_confirmation_wa_template_id``` is marked as required whenever ```stock_confirmation_type``` is set to whatsapp, regardless of whether ```stock_text_confirmation``` is enabled. As a result, when saving the record with ```stock_text_confirmation``` unchecked, the required field ```stock_confirmation_wa_template_id``` remains invisible and unset — which causes a missing required field error during record save. Steps to reproduce: [Video](https://drive.google.com/file/d/1XVV4mJjSX_8acDDbv83VtWrbZtYz6Kqg/view) 1. go to settings - inventory - shipping 2. check Text Confirmation , set stock_confirmation_type = whatsapp 3. uncheck Text confirmation 4. save the changes To fix this issue, need to just add condition of ```stock_text_confirmation```
This fix prevents users from directly editing linked database users in the database project view. It helps keep database user information controlled through the intended workflow and reduces the risk of accidental changes.
Original PR description
This commit is the counter part of odoo/odoo#231902 which allows to disable the write action on x2many fields. See [1] for details. [1] https://github.com/odoo/enterprise/pull/94207#discussion_r2378129896 Task~5160367
Website builder sections using the "Repeat pattern" background option now show the image repeatedly as intended. This prevents visual layout issues on websites and email designs that rely on patterned backgrounds.
Original PR description
__Current behavior before commit:__ When setting the background image position to "Repeat pattern" in the website builder, the background image does not repeat as expected. This is due to conflicting…
__Current behavior before commit:__ When setting the background image position to "Repeat pattern" in the website builder, the background image does not repeat as expected. This is due to conflicting CSS rules where `background-repeat: no-repeat` from [`html_builder/static/src/scss/background.scss`][1] overrides the intended `background-repeat: repeat` from `html_editor.common.scss`. __Description of the fix:__ 1. Added `!important` to `background-repeat: repeat` to ensure the repeat pattern takes precedence over other styles 2. Removed duplicate and conflicting background styles from `mass_mailing/theme_default.scss` since these are already properly defined in `html_editor.common.scss` 3. Updated the test in `parallax_option.test.js` to verify `background-repeat: repeat` style is actually applied __Steps to reproduce:__ 1. Open website builder 2. Add a section with a background image 3. Change image position to "Repeat pattern" 4. Bug: background doesn't repeat [1]: https://github.com/odoo/odoo/blob/f0a34badefd432e9c2ab36acaf018d20d0e342fe/addons/html_builder/static/src/scss/background.scss#L25 task-5145343
This fixes cases where edit or write restrictions on related record fields were ignored, allowing users to modify data when the field configuration intended to block it. Businesses can rely more consistently on form settings to prevent unintended changes in related lists.
Original PR description
Before this commit, specifying the `edit` or `write` crud options on an x2many field didn't work. The `edit` action was overruled by the view mode (true iff the record datapoint is in edition), and the `write` action wasn't correctly honored in x2many. This commit ensures the `write` action is taken into account. In master, we'll rationalize this to merge `edit` and `write` in a single action. Task~5160367 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
Bank reconciliation rules using “Not Contains” on labels now match correctly even when some transaction text fields are empty. This helps accounting teams rely on automated reconciliation rules more consistently and reduces missed matches.
Original PR description
Currently bank reconciliation model match only the label type “Contains” The “not contain” type is not working Steps to reproduce: - Open Accounting Dashboard - Access Bank journal reconciliation models (3dots > Models) - Open a [Model] and set: - Label "Not Contains" "Test" - Add a Bank Statement with any label Issue: [Model] won't match Analysis: This occurs because in case the payment_ref or transaction_details contains a NULL value the ILIKE operations will evaluate to NULL, not TRUE or FALSE. Any other comparison involving NULL value will result in NULL and the whole condition will fail opw-5065006 [Task link](https://www.odoo.com/odoo/project/49/tasks/5065006) Forward-Port-Of: odoo/enterprise#97745
Sales teams can now click product lines on draft sales orders to edit the product or description instead of being taken to the product record. This removes an unnecessary interruption and makes order adjustments faster before confirmation.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a sales order; 2. add a product that doesn't have an extra description; 3. save & exit view; 4. go back to view; 5. add a description or change the product on the line. Issue ----- Clicking on the product field opens the product record instead of edit mode. Cause ----- It opens the product record because the `canOpen` property is set to `true`. As this is the default value, and isn't getting changed anywhere, the line will always open the product record outside of edit mode. Solution -------- Instead of using OR, check `props.canOpen` AND additional checks. opw-5172115 Forward-Port-Of: odoo/odoo#232861
Repair service products that are published for sale are now correctly shown in the website shop. This prevents customers from missing eligible repair-related services when browsing or searching online.
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#232154 Forward-Port-Of: odoo/odoo#231000
This fix prevents Odoo from creating many duplicate stock routes when a new warehouse is added after an existing global route has been renamed. It keeps warehouse setup cleaner and avoids confusion or extra maintenance for inventory teams.
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
This fix prevents a manufacturing planning test from creating a duplicate purchase order line when demo data is used in different time zones. It makes the automated check more reliable, helping avoid false test failures without changing normal business behavior.
Original PR description
The `test_replenish` test was failing with demo data because replenishment created an extra Purchase Order line. The `_run_buy` search domain included `date_planned_mps` with an equality check on a datetime stored in UTC. With demo data loaded in a non-UTC timezone (e.g. Europe/Brussels), the forecast date was converted to 2025-07-31 22:00:00 UTC, which did not match the existing PO at 2025-08-01 00:00:00 UTC. As a result, no PO was found and a duplicate was created. Changes: Set the test user timezone to UTC so that `date_planned_mps` comparisons are stable when using demo data. This ensures replenishment reuses the existing PO instead of creating a duplicate. runbot-230425
This fixes a timezone-related issue that could cause a manufacturing planning test to create a duplicate purchase order line when demo data was loaded. The change makes the test environment consistent, helping ensure reliable validation without affecting day-to-day business workflows.
Original PR description
The `test_replenish` test was failing with demo data because replenishment created an extra Purchase Order line. The `_run_buy` search domain included `date_planned_mps` with an equality check on a datetime stored in `UTC`. With demo data loaded in a non-UTC timezone (e.g. Europe/Brussels), the forecast date was converted to `2025-07-31 22:00:00 UTC`, which did not match the existing PO at `2025-08-01 00:00:00 UTC`. As a result, no PO was found and a duplicate was created. Changes: Set the test user timezone to UTC so that `date_planned_mps` comparisons are stable when using demo data. This ensures replenishment reuses the existing PO instead of creating a duplicate. [runbot-230425](https://runbot.odoo.com/odoo/error/230425)
This fix prevents an error when users change the linked sales order from a delivery order. It ensures delivery records stay correctly connected to sales orders, avoiding interruptions during order fulfillment workflows.
Original PR description
Currently, an error occurs when user updates the sale order in the delivery picking. Steps to Reproduce: - Install the `sale_stock` and `sale_management` modules. - Create a `sale order` and…
Currently, an error occurs when user updates the sale order in the delivery picking. Steps to Reproduce: - Install the `sale_stock` and `sale_management` modules. - Create a `sale order` and `confirm` it. - Click the `Delivery button` on top of the order. - In the `Additional Info` tab of the sale order, select any order in `sale order` field and `save`. `psycopg2.ProgrammingError: can't adapt type 'sale.order'` `KeyError: <Command.LINK: 4>` This error occur after [this commit] where, after creating sale order, navigating to its delivery picking, and selecting the same or a different order, an invalid link caused the error[1]. This commit ensures that the sale order is linked correctly to the delivery picking. [this commit]: https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a#diff-2b9de2e50ff5e1dc0362b825bac2b07623770fb3275b3257ef972f255f3ccb8bR172-R173 [1]- https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/addons/sale_stock/models/stock.py#L173 sentry-6921046230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
13 changes
Resolved issues and error corrections
This fix improves the mobile website preview by keeping the temporary loading view visually consistent during page navigation. It prevents mismatched or overlapping scrollbars, making the preview experience cleaner for website editors.
Original PR description
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's…
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's document. This did not copied the attributes on the `html` node, which somtimes impacted the appearance. With this commit, the whole document is copied to the fallback iframe. Steps to reproduce: - Activate "Mobile preview" when viewing the website - Go to a page that is long enough for a scrollbar to appear - Navigate to another page - Bug: During the transition, the fallback is shown, and its scrollbar is wider than the one of the page that was shown just before task-5212287 ### [FIX] website: remove content of fallback iframe after load Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback iframe is shown behind the website preview to avoid flicker on navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the preview for mobile has some transparency on its scrollbar. Thus the part of the fallback iframe behind the scrollbar when previewing mobile was slightly visible. This commit fixes it by removing the fallback iframe's content after the website has loaded (and the fallback is not needed anymore). Steps to reproduce: - On website, activate "Mobile preview" - Navigate to a page long enough to have a scrollbar - Navigate to another page long enough to have a scrollbar - Scroll a bit - Bug: The scrollbar of the fallback is slightly visible task-5212287
This fix restores the correct account used for rounding differences in the French accounting localization. It corrects accounts that had been changed by mistake and ensures rounding entries are classified consistently with the intended accounting setup.
Original PR description
These accounts were changed by mistake. Even more, they're of the wrong type. Re-add account to be consistent with 758 opw-5180702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where accrued leave days expiring after carryover could be undercounted when an allocation started before the carryover date. Employees and HR teams should now see the correct number of expiring leave days, improving accuracy in time off balances.
Original PR description
To reproduce: ============= - Create an accrual plan: - Carryover date: allocation - One level: - Accrues 2 days. - Accrual date: monthly on 1st of each month - Starts immediately on allocation start…
To reproduce:
=============
- Create an accrual plan:
- Carryover date: allocation
- One level:
- Accrues 2 days.
- Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
- Starts on 01/07/2024
we should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.
Problem:
========
we loop on each month in the allocation period to compute the accrued days when we reach the carryover date (01/07/2025) we set the expiring_carryover_days to the number of days accrued until that date which is 22 as we didn't yet add the days for June 2025, it's done after.
Solution:
=========
add additional accrued days when setting expiring_carryover_days on carryover date.
opw-4963163
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where exporting records could fail when property fields relied on a computed company-related definition. Users can now export affected data normally, reducing disruption for teams using customized property fields.
Original PR description
**Description of the issue/feature this PR addresses:** Setup a model with a computed definition record field, like so: ```py properties_company_id = fields.Many2one(…
**Description of the issue/feature this PR addresses:**
Setup a model with a computed definition record field, like so:
```py
properties_company_id = fields.Many2one(
compute="_compute_properties_company_id",
comodel_name="res.company",
)
@api.depends("company_id")
@api.depends_context("company")
def _compute_properties_company_id(self):
for item in self:
item.properties_company_id = item.company_id or self.env.company
```
Use this in a `Properties` definition:
```py
properties = fields.Properties(
definition="properties_company_id.properties_definition",
)
```
Then simply try to export the model.
**Current behavior before PR:**
```python-traceback
Traceback (most recent call last):
File "/odoo/src/odoo/odoo/http.py", line 2166, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/odoo/src/odoo/odoo/http.py", line 2133, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/http.py", line 2381, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/addons/web/controllers/export.py", line 400, in get_fields
exportable_fields.update(self._get_property_fields(fields, model, domain=domain))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/addons/web/controllers/export.py", line 321, in _get_property_fields
field_to_get = Model._field_to_sql(Model._table, definition_record, self_subquery)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/models.py", line 2973, in _field_to_sql
return model._field_to_sql(alias, field.name, query)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/models.py", line 2976, in _field_to_sql
raise ValueError(f"Cannot convert {field} to SQL because it is not stored")
```
**Desired behavior after PR is merged:**
Should not fail.
With this commit, the code fallbacks to export all properties defined, even those that are not used among the exported records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures Safari users can apply or dismiss links in the HTML editor without the popover closing too early. It also restores reliable use of the link type selector, helping users edit email templates and other rich text content without failed or incomplete link changes.
Original PR description
## Issue: On Safari, the Apply and Dismiss buttons of the LinkPopover did not trigger their actions In some cases, it seemed to work only because a temporary link was not properly cleared The Link…
## Issue: On Safari, the Apply and Dismiss buttons of the LinkPopover did not trigger their actions In some cases, it seemed to work only because a temporary link was not properly cleared The Link Type Selection was also broken by the same bug ## Cause: Safari triggers a `pointerdown` event through the `LinkPopover`, which changes the `selection` and calls the `handleSelectionChange()` method https://github.com/odoo/odoo/blob/e43135e94bf22bc2f7a115c37e8a082f96871ed0/addons/html_editor/static/src/main/link/link_plugin.js#L672-L678 At that point, `documentSelection` is `null`, causing the overlay to close before the `onClickApply()` on the Apply button It's the same issue with the Dismiss button and the Link Type Selection ## Steps to reproduce: - Install mail to get access to an html_editor - Enable debug mode - Go in Email Templates and open one of them - Select a text and open link tools - Add Odoo.com and click on Apply - The link may seems to be created (if it's the case, there is no preview) - You can confirm that with the link type selector that closed the popover before the fix opw-5115887
Module updates now avoid reactivating or disabling existing website assets based only on their original configuration. This prevents older website snippets still used on live pages from losing required assets after an update, helping keep existing website content displayed correctly.
Original PR description
Before this commit when a module was updated all ir.asset records were reset to their defined `active` state, if defined. This causes assets related to old snippet versions to be made inactive even…
Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.
It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].
This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).
Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
def _load_records_write(self, values):
values.pop('active', None)
super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.
[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
task-2963840
(Follow-up of https://github.com/odoo/upgrade/pull/3829)
Forward-Port-Of: odoo/odoo#104836This fix updates how website appointment and rental snippets load their supporting assets, aligning them with the newer platform mechanism. It helps keep these website components compatible and reliable after platform changes, without changing their visible behavior for users.
Original PR description
See https://github.com/odoo/odoo/pull/104836 task-2963840 Forward-Port-Of: odoo/enterprise#35153
This change adjusts rental-related automated tests to investigate and address a failure seen in the shared runbot environment but not locally. It helps improve confidence that rental workflows can be validated consistently before releases.
This update prevents duplicate partner identification values from being sent in Colombian and Peruvian electronic invoice files. It helps avoid validation errors from tax authority rule sets that only accept one party identification per partner.
Original PR description
odoo/odoo#206655 added the partner ref in the party identification nodes, but most rule sets don't accept multiple ids for a single partner party identification. Commit 4e22e6b already fixed the issue for malaysian edi. so instead of calling super and extending, we do full overriding with no delegation for `_get_partner_party_identification_vals_list`. community pr: https://github.com/odoo/odoo/pull/213530 no-task
UPS label generation could fail in production when sender or shipper VAT details were left blank. This fix avoids sending empty tax ID values to UPS, helping businesses create shipping labels successfully 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. opw-5214709
This fixes an issue where the Point of Sale navigation bar no longer showed the connection status for hardware devices using a proxy. Store staff can again see whether connected devices such as printers or other PoS hardware are available, helping them spot setup or connectivity problems sooner.
Original PR description
Description of the issue/feature this PR addresses: The presence of proxy status of hardware devices depends conditionally on pos.config.use_proxy in template of NavBar. However, use_proxy was removed in [PR 51000](https://github.com/odoo/enterprise/pull/51000) and [PR 142566](https://github.com/odoo/odoo/pull/142566). As a consequence, the proxy status is never shown in the NavBar of odoo 18.0. It's already fixed in odoo 19.0 Current behavior before PR: ProxyStatus is not displayed in PoS NavBar even if proxy is used for hardware devices. Desired behavior after PR is merged: ProxyStatus is displayed in PoS NavBar depending on proxy configuration (useProxy() of pos_store.js). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Improves inventory performance when warehouses have many transfers with quality checks. The change reduces memory usage significantly, helping prevent worker crashes when users open the To Receive view.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162
This update restores the Swedish POS rule that limits receipt reprints to one time, helping businesses stay compliant and avoid duplicate receipt handling issues. It also improves blackbox error handling so disconnected devices or unexpected errors no longer leave the interface stuck loading.
Original PR description
Before this commit, the receipt reprint check logic (which only allows a receipt to be reprinted once) was not working. There were two issues preventing it from working: - The name of the function had changed but not been updated in this module, so the override was not applied. - The ID being used to check the order was incorrect. A few smaller issues were also fixed: - A logging issue in the IoT driver, which prevented the error severity from being printed. - An infinite loading UI if the blackbox was disconnected. - The blackbox error handler swallowing up some errors due to only expecting one specific format. Forward-Port-Of: odoo/enterprise#98076
4 changes
Resolved issues and error corrections
Updating the quantity to produce for subcontracted manufacturing orders no longer creates extra component lines without lot or serial numbers when stock is already reserved. This reduces manual corrections and helps users validate receipts without avoidable lot/serial errors.
Original PR description
,*=mrp_subcontracting_purchase Issue Before This Commit: ======================= When a user updates `qty_producing` in a subcontracting MO, it creates new move lines with empty lots or serials, even…
,*=mrp_subcontracting_purchase Issue Before This Commit: ======================= When a user updates `qty_producing` in a subcontracting MO, it creates new move lines with empty lots or serials, even though the required quantity is already available in existing reserved move lines. This requires the user to manually reassign lots/serials; otherwise, validating the picking raises a UserError of `missing Lot/Serial numbers`. Steps to Reproduce: ======================= - Install the `mrp_subcontracting_purchase` module. - Create product1 with Vendor1. Create product2 with lot tracking and set it `Resupply Subcontractor on order` in Inventory. - Create a BOM for product1, with product2 as a component (quantity 10) and subcontractor Vendor1. - Create and confirm a purchase order for product1 (quantity 10) with Vendor1. - Go to Resupply → Supply Product2, deliver 100 units of Product2 to Vendor1 using lot-01, then validate the picking. - Go to the source PO → Receipt → Record Component. Observe that the move line is created with 100 units from lot-01 - Set qty_producing to 5 → the current component line updates to 50 quantity. - Increase qty_producing to 10 → a new line is created with empty lot and quantity 50, even though the existing line already has 100 of the same lot. Cause of the issue: ======================= When `qty_producing` is updated in the subcontracting MO wizard, the `_set_quantity_done_prepare_vals` method recalculates quantities based on the already modified move line quantity instead of referencing its original `reserved quantity`.This causes incorrect comparisons on subsequent updates, leading to the creation of new move lines with empty lots even when sufficient quantity already exists in the existing move line. With This Commit: ======================= `_set_quantity_done_prepare_vals` method now uses `ml._origin.quantity or ml.quantity`. ` _origin.quantity` ensures the reserved quantity of existing move lines is counted, while `ml.quantity` handles newly created lines without an origin. This prevents unnecessary move lines with empty lots when sufficient quantity already exists in existing reserved lines, eliminating manual reassignment and avoiding UserError on picking validation.
The Generate Pricelist Report action no longer crashes when no pricelist has been created. Instead, users see a clear error message explaining that a pricelist is needed, helping them resolve the setup issue without technical support.
Original PR description
Description of the issue/feature this PR addresses: When triggering the “Generate Pricelist Report” server action, an OwlError occurred if no pricelist record was defined in the database. This happened because the code attempted to access ctx.selectedPricelist.id while the pricelist context was undefined. Current behavior before PR: The system raises an OwlError when clicking “Generate Pricelist Report” if no pricelist exists. The user cannot open the report without manually creating a pricelist first. Desired behavior after PR is merged: A check ensures that a valid pricelist exists before generating the report. If no pricelist is found, a user-friendly error message is shown instead of a crash. Prevents the undefined context error on the client side. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sales pricelist report now checks whether a pricelist exists before opening. If none is available, users see a clear message instead of a system error, helping them understand what setup is needed.
Original PR description
Description of the issue/feature this PR addresses: When triggering the “Generate Pricelist Report” server action, an OwlError occurred if no pricelist record was defined in the database. This happened because the code attempted to access ctx.selectedPricelist.id while the pricelist context was undefined. Current behavior before PR: The system raises an OwlError when clicking “Generate Pricelist Report” if no pricelist exists. The user cannot open the report without manually creating a pricelist first. Desired behavior after PR is merged: A check ensures that a valid pricelist exists before generating the report. If no pricelist is found, a user-friendly error message is shown instead of a crash. Prevents the undefined context error on the client side. https://github.com/odoo/odoo/issues/180247 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A minor test setup issue was fixed in the Project Timesheets Holidays module. This helps ensure time off and public holiday calculations are validated using the right user context, reducing the risk of future regressions.
Original PR description
In the 'test_timesheet_time_off_including_public_holiday' test case, 'employee' was mistakenly passed to 'with_user'. This commit replaces 'employee' with 'user' for consistency. task-4809916