Daily updates from Odoo
Navigate
Branch
Tuesday, October 28, 2025
207 changes
20 changes
Enhancements to existing features
The Spanish localization now includes more detailed IGIC tax data for the Canary Islands, separating purchase taxes for goods and services and adding DUA-related taxes. This helps businesses apply the right tax mappings depending on the type of purchase and aligns Canary Islands handling more closely with mainland Spanish tax workflows.
Original PR description
We have splitted purchase taxes in goods and services because there are different mappings according to the scope. It has a similar functionality with spanish mainland taxes @jco-odoo There are doubts with the fiscal position `fp_nacional_canary_ns` as it is applied automatically to spanish non canarian partners but it should be similar to non-EU partners IMO. However, I think that the opinion fo some canary people would be nice to clarify it @Christian-RB --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230964 Forward-Port-Of: odoo/odoo#228667
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
Code cleanup and technical improvements
This update simplifies automated test files by removing unnecessary wrapper labels that repeated the file name or could be misleading. It does not change product behavior, but it makes the test suite easier for developers to read and maintain.
Original PR description
This commit removes test files using a single 'describe' call to wrap its tests, with a name being either redundant with the test file itself or is too misleading.
Regular expression used to find isolated suites:
```js
/^\s*import.*(?:\n(?!describe\()(?!test\().*)+\ndescribe\("[\w\s.]+",.*(?:\n(?!describe\().*)+\n\}\);\n(?!\n)/
```
Tip for reviewers: tick **"Hide whitespace"** when reviewing diff
<img width="237" height="205" alt="image" src="https://github.com/user-attachments/assets/373f7cc6-5e0e-4599-968a-39aad8fac2f0" />
Enterprise: https://github.com/odoo/enterprise/pull/98046
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233207
Forward-Port-Of: odoo/odoo#233006This change simplifies automated test files by removing unnecessary grouping labels that duplicated file names or could be misleading. It does not change product behavior, but it makes tests easier for developers to review and maintain.
Original PR description
This commit removes test files using a single 'describe' call to wrap its tests, with a name being either redundant with the test file itself or is too misleading.
Regular expression used to find isolated suites:
```js
/^\s*import.*(?:\n(?!describe\()(?!test\().*)+\ndescribe\("[\w\s.]+",.*(?:\n(?!describe\().*)+\n\}\);\n(?!\n)/
```
Tip for reviewers: tick **"Hide whitespace"** when reviewing diff
<img width="237" height="205" alt="image" src="https://github.com/user-attachments/assets/373f7cc6-5e0e-4599-968a-39aad8fac2f0" />
Community: https://github.com/odoo/odoo/pull/233006
Forward-Port-Of: odoo/enterprise#98171
Forward-Port-Of: odoo/enterprise#98046Documentation and clarification updates
The corporate contributor agreement record for ForgeFlow was updated. This keeps Odoo's legal contribution documentation current and helps ensure contributions are properly covered.
Original PR description
PR: https://github.com/odoo/enterprise/pull/97338 Forward-Port-Of: odoo/odoo#232545 Forward-Port-Of: odoo/odoo#231883
15 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
Documentation and clarification updates
The contributor agreement documentation for ForgeFlow has been updated. This keeps Odoo's legal records current and helps ensure contributions are covered by the proper agreement.
Original PR description
PR: https://github.com/odoo/enterprise/pull/97338 Forward-Port-Of: odoo/odoo#232545 Forward-Port-Of: odoo/odoo#231883
3 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#9588030 changes
Enhancements to existing features
Users can now start the shortcut timer from the My Timesheet grid when it is grouped by task, parent task, or helpdesk ticket, in addition to project. This makes time tracking faster and more flexible for teams who organize work around tasks or support tickets.
Original PR description
_*= helpdesk_timesheet, timesheet_grid **Current behavior:** In the My Timesheet grid view, the shortcut timer can only be started when grouped by project. **New behavior:** The shortcut timer can now also be started when the grid view is grouped by task, parent task, or helpdesk ticket. task-3429443
The Documents search view has been simplified by removing extra filters that were not needed. This makes it easier for users to find the relevant filtering options when working with documents.
Original PR description
This commit removes the extra 'Documents' and 'Hide shortcut' filters from the documents search view to make the filter list simpler and keep only the relevant options. task-5170118
Chat windows now use the same underlying conversation model as the main Discuss app. This should make messaging behavior more consistent across AI chat, live chat, website live chat, and WhatsApp integrations, reducing differences users may notice between channels.
Original PR description
PR community: https://github.com/odoo/odoo/pull/232493
Knowledge article trash notification emails now use a clearer standard layout with a direct button to open the article. Recipients are also told that trashed articles are permanently deleted after 30 days, while the person who moved the article to trash no longer receives an unnecessary notification.
Original PR description
This PR refines the existing notification email for trashed articles with the following changes: 1. Use the standard notification email layout (`mail_notification_layout`) with an access button, allowing the recipient to quickly open the trashed article. 2. Do not send a notification to the user who moved the article to the trash. 3. Include a short note in the email informing the recipient that the article will be permanently deleted after 30 days, and that they must take action if they wish to keep it. Additionally, this PR replaces all occurrence of "send to trash" with "move to trash" to match common UI terminology and improve clarity. Task-5095861
Property selection values now return their internal name rather than their display label by default. This improves consistency for payroll-related property data and reduces ambiguity when values are used across business processes or integrations.
Original PR description
Purpose ======= Followup of odoo/odoo/pull/232800 , when getting a property selection, we want to return the name by default instead of the label.
Belgian payroll now includes additional work entry types that were previously missing. This helps payroll teams classify employee time more accurately and supports more complete payroll processing.
Payroll users now receive a warning when closing a salary adjustment while related payslips are not yet finalized. This helps prevent confusion because the adjustment can still affect unfinished payslips, allowing users to review and act before payroll is completed.
Original PR description
When a salary adjustment is closed with related payslips still not done, salary adjustments are still applied. This commit adds a warning so that the user knows if this adjustment is closed to act accordingly task: 5135771
The customer ticket page now avoids repeating the same sales timesheet feature check several times. This reduces unnecessary processing and should make the page slightly more efficient without changing what users see.
Original PR description
helpdesk, helpdesk_sale_timesheet: reduce multiple calls ---------------------- In the `/my/tickets` route, the `_check_sale_timesheet_feature_enabled` method was called three times (for search input, search groupby, and value preparation). This commit passes the result of `_check_sale_timesheet_feature_enabled` in an argument, reducing the number of calls. the argument is now used in both search input and search groupby, improving performance. helpdesk: removed redundant method -------------- Removed the `_prepare_portal_layout_values` method as it only called the super method without any changes, making it unnecessary. task-4513671
Turkey payroll benefits now use the newer salary rule-based flexible benefits setup instead of separate payslip input records. This keeps the localization aligned with the current payroll flow and makes benefit inputs appear in the expected payroll input section.
Original PR description
purpose: adapting the new system of flexible benefits coming from salary rules for tr localization - adapted the fields in `hr.version` to become salary rules with `condition_select` as `property_input` which makes it appear in the input section - removed the records in `hr.payslip.input.type` and converted them into corresponding salary rules - removed the inherited view of `hr.version` - changed the tests in `test_salary_rules` to use salary rules instead of hardcoded fields task-id: 5122400
Demo data for WhatsApp accounts has been added back. This helps teams and evaluators see example WhatsApp account setup when trying or demonstrating the app.
Original PR description
Purpose of this commit, Adding back the demo data for whatsapp accounts. revert: https://github.com/odoo/enterprise/pull/97138 task-5172791 Forward-Port-Of: odoo/enterprise#98135
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
Features or functions removed from Odoo
This change removes remaining unused code from the Product Barcode Lookup module that should have been removed in an earlier update. It helps keep the system cleaner and reduces the chance of obsolete background logic affecting future maintenance.
Original PR description
Forgot to remove the code in master for https://github.com/odoo/enterprise/pull/97780 .
Code cleanup and technical improvements
This update streamlines how accounting-related automated tests create common business records such as invoices, sales orders, reversals, and down payments. It helps teams write and maintain tests more consistently across accounting and localization modules, reducing future maintenance effort without changing customer-facing behavior.
Original PR description
This commit adds bunch of helper methods on AccountTestInvoicingCommon to make it easier to do generic accounting test actions, such as: - creating invoice - creating sale order - reversing invoice - skipping test if module isn't installed - creating down payment invoice ... and many more. We're aware that there are thousands of different helpers for creating invoice out there in different localizations. This commit serves as the first necessary step to create one standard that can be extended across all other test helpers. Some tests have been rewritten to use these new helpers, but due to the sheer amount of tests out there, we're still far from converting every old tests to use this new helpers. However, this should get our feet in the door, allowing us to start writing test the correct way on new tests after this PR, and improve the DX of (accounting) test writing. :) task-4891206
20 changes
Enhancements to existing features
This update simplifies how website builder options are defined and shared across related tools, making it easier for teams to maintain and extend builder features. It affects website features such as live chat, appointments, and rental search, with no expected direct disruption for end users.
Original PR description
The commit: 1. use static property to configure a builder option 2. introduce the concept of dependencies to access the plugin's shared in builder option 3. make a plugin context the same for Plugin,…
The commit:
1. use static property to configure a builder option
2. introduce the concept of dependencies to access the plugin's shared
in builder option
3. make a plugin context the same for Plugin, BuilderOption and
BuilderAction to have the same API in each class.
Before this commit, to define an option, we had to define a javascript
object that would contain the information of the option within the
`builder_options` resource.
```js
class MyPlugin extends Plugin {
resources: {
builder_options: [
{
selector: "div.selector",
template: "my.owlTemplate",
cleanForSave() {}
// ... other option props
}
]
}
}
// For a custom component
class MyPlugin extends Plugin {
resources: {
builder_options: [
{
selector: "div.selector",
template: MyCustomComponent,
cleanForSave() {}
// ... other option props
}
]
}
}
class MyCustomComponent extends BaseOptionComponent {
// ...
}
```
When building anything for the builder, there is 3 classes that are
important: `Plugin`, `BaseOptionComponent`, `BuilderAction`.
In practice, the option object defined in builder_options feels
strange. On the other hand, making the configuration of the option as
a static property of the component somehow feels simpler as everything
related to that option is defined in the same class.
```js
class MyPlugin extends Plugin {
resources: {
builder_options: [MyCustomComponent]
}
}
class MyCustomComponent extends BaseOptionComponent {
static template = "my.owlTemplate";
static selector = "div.selector";
static cleanForSave(context) {}
// ...
}
```
To have the same mental context in the 3 important class, they all
share the same API (`dependencies`, `dispatchTo`, `getResource`, ...)
(see `Editor.getPluginContext`)
To access a plugin shared method, it's now the same for `Plugin`,
`BuliderAction` and `BaseOptionComponent`:
```js
class MyCustomComponent extends BaseOptionComponent {
static selector = "mySelector";
static dependency = "myPlugin";
myMethod() {
this.dependencies.myPlugin.pluginMethod();
}
}
```
To access a resource, dispatch, ...:
```js
class MyCustomComponent extends BaseOptionComponent {
static selector = "mySelector";
myMethod() {
const resource = this.getResource('myResource');
}
}
```
Forward-Port-Of: odoo/enterprise#94102This update adds end-of-day balance reporting and refund support for Six payment terminals in Point of Sale. It also improves transaction speed, receipt handling, and payment details so store teams get a smoother checkout and closing process.
Original PR description
Based on the feedback received from our partners we are missing some features in our Six terminal integration. This PR adds them 1. Send balance command to print end-of-day report 2. Adapt the code to reduce the sleep delay after each transaction 3. Refunds/payment reversals for Six + it also adds some minor code improvements like a) Card brand is now saved in pos payments instead of the card number b) Card number is still being sent to PoS and while not stored in v17 will be stored from v18 c) The code of ctypes_terminal_driver and Six Driver was improved to reuse the buffer size and improve the buffer usage d) Fixes the receipt size for the Six terminals e) updates the Six C libraries used to the latest version to get all the newest fixes Related C PR: https://github.com/odoo/worldline-lib/pull/9 Forward-Port-Of: odoo/enterprise#98132 Forward-Port-Of: odoo/enterprise#96748
This update simplifies how website builder options are defined and managed behind the scenes. It gives developers a more consistent way to build and maintain editing tools, helping future website editing features be delivered more reliably.
Original PR description
1. use static property to configure a builder option 2. introduce the concept of dependencies to access the plugin's shared in builder option 3. make a plugin context the same for Plugin, BuilderOption and BuilderAction to have the same API in each class. See https://github.com/odoo/odoo/pull/220746 Forward-Port-Of: odoo/odoo#220746
The Colombian reports module test coverage was updated to match new account grouping rules. This is an internal quality improvement that helps ensure trial balance reports continue to be validated correctly without changing day-to-day user workflows.
Original PR description
task-5165175
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
Documentation and clarification updates
This pull request adds a signed contributor agreement record for the contributor. It is an administrative legal update that helps confirm contribution eligibility and does not affect product features or user workflows.
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
8 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.
4 changes
Enhancements to existing features
The Italian localization no longer allows outdated tax exemption reason codes that the Italian Tax Agency now rejects. This helps businesses avoid invalid electronic invoices by using the newer, more detailed codes already available in Odoo.
Original PR description
There are old Natura (l10n_it_tax_exemption_reason) that are deprecated in favour of more detailed ones. We already have the detailed ones, but we allow the old values, but the Tax Agency considers them invalid already. ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DatiRiepilogo/Natura
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