Tuesday, July 8, 2025
28 changes · saas-18.3
Enhancements to existing features
The accounting journal field previously labelled "Private Part Account" is now labelled "Private Share Account". This improves clarity for users by avoiding wording that can be misunderstood in English, without changing the underlying accounting behavior.
Original PR description
Change label of `non_deductible_account_id` field on `account.journal` from `Private Part Account` to `Private Share Account` as private part means something else in english. task-4868244 Forward-Port-Of: odoo/odoo#217289
The Spanish SII electronic invoicing demo certificate has been renewed to keep test and demonstration flows working with AEAT services. This helps maintain continuity for localization validation without changing day-to-day 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 Forward-Port-Of: odoo/odoo#217341
The AI feature now uses the shared message copy action provided by the mail/discuss system. This keeps the user experience consistent and reduces duplicated behavior between AI and messaging features.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/89402 The "copy-message" action is moved to mail in the community counterpart of this commit. This commit updates the ai code to use the mail action.
Resolved issues and error corrections
Website editors can now set and keep default values on form fields even when those fields use contextual data. This prevents saved form settings, such as contact form subjects or recruitment fields, from being unintentionally cleared during editing.
Original PR description
Scenario: - go to the /contactus page - edit the subject field and set a default value then save Result: the default value is not saved. Reason: in 13.0, field default value had priority over…
Scenario: - go to the /contactus page - edit the subject field and set a default value then save Result: the default value is not saved. Reason: in 13.0, field default value had priority over data-for so an issue was solved by b637a5e32f767b62736241042f88fa0cecf9f10b that if you saved a form, the data-for would become the default for all the uses of that form (so eg. a job position would be set for all job positions). In 8d0a63f35519090a74fcefedf482fea5f6eedd97 the priority was changed so data-for has higher priority than the default value, that made the prior fix unnecessary (just a nice to have, to not save the data-for as default that would be overridden by another data-for). The fix was reintroduced by ca433f38dbfe379dc9e0b823c7862eaec1a7ed9d but it removes default value if there is a data-for. Fix: remove the filling and removing of value: the data-for is not shown in the editor (allowing us to set default) but has the priority when rendering the field in non-editable mode. This is mirroring what is already done for data-fill-with. Side note: this commit also remove useless data-fill-with="undefined" attributes that are added when editing field. They shouldn't cause any issue unless someone add a "undefined" field in the prefilled fields. opw-4794903 Forward-Port-Of: odoo/odoo#217200 Forward-Port-Of: odoo/odoo#211083
Miscellaneous changes
In order to satisfy certification requirements from the LNE, we implement the following: - A product is weighed at e.g. 200g and added to the order - Another product is weighed. The weight must change from 200g before the user is allowed to add the item. - This should also happen even if another non-weighed product is added in-between. task-4859589 Enterprise PR: https://github.com/odoo/enterprise/pull/87296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
In order to satisfy certification requirements from the LNE, we implement the following: - A product is weighed at e.g. 200g and added to the order - Another product is weighed. The weight must change from 200g before the user is allowed to add the item. - This should also happen even if another non-weighed product is added in-between. task-4859589 Enterprise PR: https://github.com/odoo/enterprise/pull/87296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214997 Forward-Port-Of: odoo/odoo#213537
This fixes an issue where customers using both the Spanish TicketBAI POS localization and Peruvian POS electronic invoicing could miss the refund reason popup. Refund workflows now wait for the required step to complete, helping staff capture the proper refund information consistently.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/odoo#217358 Forward-Port-Of: odoo/odoo#216379
The online shop now checks category values in URLs before using them. This prevents shoppers from seeing an error page if a category link is malformed or manually changed, improving storefront reliability.
Original PR description
The system will crash when we get the `category` as `str` and we try to evaluate `int(category)` in `_validate_and_get_category` method. **Root Cause:-** - At [1] and [2], we are passing an object in…
The system will crash when we get the `category` as `str` and we try to evaluate `int(category)` in `_validate_and_get_category` method. **Root Cause:-** - At [1] and [2], we are passing an object in the arguments for the category. If we manually provide a category, it may result in a `not found` error instead of a regular error. - However, at point [3], Since the `category` is received from a `query parameter`, it can be easily tampered with, so it should be properly validated before use. - This controller makes the `older controller` (used before V14) `compatible` with the new one. [1] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L470 [2] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L247 [3] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L546 **Error:-** `ValueError: invalid literal for int() with base 10: 'duffle-bags'` **Solution:-** - We added a `validation` to ensure the category parameter is a `valid integer` before using it. - This prevents crashes when users manually input 'invalid` or `tampered category` values in the URL. **Sentry - 6658317828** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer address entries without a contact name now show their address type, such as invoicing address, instead of an incorrect “False” label. This makes customer selection clearer in sales flows and avoids confusion when companies have unnamed child contacts.
Original PR description
Steps to reproduce =============== 1. Create a company called Acme. 2. Create a child contact of type Invoicing address but do not give it any name. 3. Go to Sales. 4. Open the dropdown to select customer ---> Recipient without name will show False after the parent name From commit [Commit 1], formatted display name was added. After this commit, add a fallback as customer's type to the name. [Commit 1]: https://github.com/odoo/odoo/commit/4f594949164f7ee6753f1da92222d2bd904d1d58 Task-4812554
This fix updates an internal test for Malaysian electronic invoicing in Point of Sale so it no longer depends on an enterprise-only component. It helps ensure the community edition test suite runs reliably without affecting day-to-day user features.
Original PR description
The test in this module imports a common setup from account_reports which is not a dependency, and is not auto installed when the test runs with community modules only. This fix replaces the setup by the community one AccountTestInvoicingCommon. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217681
This update cleans up duplicated helper code used in accounting tests. It reduces maintenance overhead and helps keep future test changes simpler, with no expected impact on day-to-day users.
Original PR description
In 0f3a9dee5cf15 we added helpers to create test taxes in `AccountTestInvoicingCommon`, not realizing that they were already in `TestTaxCommon`. This commit removes them from `TestTaxCommon` to avoid the duplication. task-none Forward-Port-Of: odoo/odoo#217553
The live chat start button now waits for the correct availability check before appearing. This avoids briefly showing chat as available on pages where live chat rules later determine it should not be shown, creating a smoother visitor experience.
Original PR description
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it…
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it doesn’t consider the live chat rules. Since [1], we do not wait for the live chat service to be initialized, so the initial value is used instead of the corrected one.
These rules depend on the URL. Since `get_livechat_info` is called from the website template, we can’t determine which rule applies at that point. The goal is mainly to avoid calling `init_livechat` ("/mail/data") if we already know the live chat won’t be available. However, this check alone isn’t enough to decide whether to show the chat button.
This commit renames `isAvailable` to `can_load_livechat` for clarity. If `can_load_livechat` is set, we can load the live chat and call `init_livechat`, which will then set the `livechat_available` value.
task-4908197
[1]: https://github.com/odoo/odoo/pull/194399
backport-of: https://github.com/odoo/odoo/pull/216595
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-prThe Translate with AI button now displays with the correct color when users work in dark mode. This improves readability and keeps the editing experience visually consistent across display themes.
Original PR description
Purpose of this PR: - Backport a [PR #206008](https://github.com/odoo/odoo/pull/206008) which ensures that the `Translate with AI` (`oe-language-icon`) button changes color appropriately in dark mode. task-4897771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when a bill of materials with operations and by-products is copied, the copied by-product lines are linked to the new copied operation instead of the original one. This prevents confusion and incorrect references when managing or archiving operations on copied manufacturing setups.
Original PR description
### Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. ### Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom #### > The copied by product line refer to the operation of the original bom this can be checked by archiving the copied operation which should erase its link with the copied by product line but will not ### Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217319 Forward-Port-Of: odoo/odoo#216609
This change corrects an internal test so it no longer overlooks missing database indexes in certain test runs. It also adds the missing indexes identified by the corrected check, helping prevent performance issues and inconsistent CI results.
Original PR description
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria…
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a small configuration error that could stop a hardware driver update from completing during a git checkout. The change helps ensure updates proceed reliably without an unexpected failure.
Original PR description
Introduced in odoo/odoo#213177. A simple typo meant the `update_conf` method was being called with a set instead of a dict, leading to an error being thrown and preventing the git checkout. This commit fixes the typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215397 Forward-Port-Of: odoo/odoo#215230
Sales orders created from CRM no longer carry over the CRM lead's assigned user when they are confirmed. This prevents related quality checks from being assigned to the wrong person, improving accuracy for teams using sales and quality workflows.
Original PR description
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 Forward-Port-Of: odoo/odoo#215499
The map view now opens Google Maps using the contact's full address instead of relying on stored coordinates that may be imprecise. This helps users get the correct destination when choosing "View in Google Maps" from a contact marker.
Original PR description
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be…
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be slightly different from given one (when using OpenStreeMap) - Click on the position marker > `Navigate To` the address is recomputed correctly - Click on `View in Google Maps` the address given is often wrong **Issue:** Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results. As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results. **Fix:** Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps. opw-4649910 Forward-Port-Of: odoo/enterprise#87430
Removing a field matching from a spreadsheet global filter is now saved correctly. This prevents deleted filter links from reappearing after users save their changes, making spreadsheet filter editing more reliable.
Original PR description
Steps to reproduce: 1. Open a spreadsheet with global filters. 2. Open the global filter editor. 3. Open a global filter. 4. Delete the field matching (and nothing else). 5. Save the global filter. => The field matching is not saved. This was due to the fact that the removal of the field matching makes an early return in the `updateFieldMatching` method, which had for last instruction to set the `draft` property to mark the filter as dirty. This commit fixes the issue by ensuring that the `draft` property is set even when the field matching is removed. Task: 4882261
This change updates the manufacturing work order test setup to use a dedicated test order numbering pattern. It helps avoid conflicts with sample data, making automated checks more stable without affecting normal users.
Original PR description
This commit modifies the MO sequence as defined in the test's setup from "WH/MO/" to "WH/TEST/MO", this way, there won't be any name's conflict with MO created by demo data. Runbot build error: [223328](https://runbot.odoo.com/odoo/error/223328)
Users with view-only access no longer see the option to split PDF documents. This prevents a confusing error and keeps document actions aligned with each user's permission level.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451 Forward-Port-Of: odoo/enterprise#89328 Forward-Port-Of: odoo/enterprise#75803
This update fixes an issue that could cause errors when translated text was generated in employee referrals and loan workflows. The change improves reliability for users working in translated environments without changing business functionality.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198 Forward-Port-Of: odoo/enterprise#88632
This fix prevents upgrade failures when the Belgian disallowed expenses setup references accounts that are not present in older databases. It only updates accounts that already exist, making upgrades more reliable without changing day-to-day functionality.
Original PR description
The accounts being updated are [added](https://github.com/odoo/odoo/commit/fe8570caf8eb8067fba800cf0d76de78d9cf8585) in saas-18.3. When upgrading from earlier versions the [init hook](https://github.com/odoo/enterprise/blob/0250ade8e90b4590318c152864c42d5fc5a62338/l10n_be_disallowed_expenses/models/account_chart_template.py#L11) will load the module's csv and fail because the accounts do not exist. This fix adds a filter on existing accounts. runbot error https://runbot.odoo.com/odoo/runbot.build.error/224150
This fixes an internal testing issue that could miss required database indexes during development but catch them later in nightly runs. The change makes validation more consistent and adds the missing indexes, reducing late CI failures and helping keep performance safeguards reliable.
Original PR description
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria…
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546
Installing Field Service Sales no longer fails if the default Services product category was previously deleted. The setup now continues by leaving that category unset, helping customers avoid a blocking installation error.
Original PR description
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `industry_fsm_sale` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/enterprise/saas-18.3/industry_fsm_sale/data/industry_fsm_data.xml:5, somewhere inside <record id="field_service_product" model="product.product">
<field name="name">Field Service</field>
<field name="project_id" search="[('id', '=?', ref('industry_fsm.fsm_project', raise_if_not_found=False)), ('is_fsm', '=', True)]"/>
<field name="service_tracking">task_global_project</field>
<field name="type">service</field>
<field name="categ_id" ref="product.product_category_services"/>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#89510This update prevents an error during Point of Sale IoT setup when assigning a barcode scanner. It helps businesses configure scanner devices reliably and avoid setup interruptions.
Original PR description
The error occurs because `append()` is used on the Many2many field `iface_scanner_ids` in `pos_config`, which is not allowed. Traceback: `AttributeError: 'iot.device' object has no attribute 'append'` Many2many fields should be updated using `|=` to add records, as the Python list method `append` is not supported for relational fields. [1]- https://github.com/odoo/enterprise/blob/5bff585cfa24940626b14cdeaeae07b50a931e94/pos_iot/wizard/auto_config_pos_iot.py#L55 sentry-6719710908
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87165
Original PR description
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87165
The main changes are in the community PR odoo/odoo#213537. This commit simply adds a call in the `scale_service.js` override to ensure the new behaviour is also enabled in Enterprise. task-4859589 Forward-Port-Of: odoo/enterprise#88050 Forward-Port-Of: odoo/enterprise#87296
Original PR description
The main changes are in the community PR odoo/odoo#213537. This commit simply adds a call in the `scale_service.js` override to ensure the new behaviour is also enabled in Enterprise. task-4859589 Forward-Port-Of: odoo/enterprise#88050 Forward-Port-Of: odoo/enterprise#87296
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock dat
Original PR description
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to…
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored. Fix: Replaced the direct lock date check with _get_lock_date_violations(), which: - Correctly considers user-specific temporary lock date exceptions. - Returns violations based on effective lock rules (including hard lock). - Provides a more generic error message. Steps to reproduce: - Use a tax report with carryover values (e.g. Belgian VAT return, line 81). - Post a refund using a tax that maps to the carryover (e.g. 21% M). - Generate a closing entry. - Set the company’s tax_lock_date to a date covering the refund. - Grant a temporary lock date exception to the user, covering the same date. - Try to reset the closing entry → Lock date error is raised (incorrectly). opw-4715100 Forward-Port-Of: odoo/enterprise#85337