Tuesday, July 8, 2025
11 changes · saas-18.2
Resolved issues and error corrections
Sale orders created from CRM no longer carry the CRM lead's assigned user into related records during confirmation. This prevents quality checks from being assigned to the wrong person, helping teams keep operational responsibilities accurate.
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
Copying a bill of materials now correctly links copied by-products to the copied manufacturing operation instead of the original one. This prevents confusion and incorrect operation references when manufacturers duplicate BoMs that include operations and by-products.
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
Point of Sale receipts now show the cashier who completes the payment, even if the cashier was changed during checkout. This prevents incorrect staff attribution on customer receipts and restores the expected behavior.
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 Forward-Port-Of: odoo/odoo#216339 Forward-Port-Of: odoo/odoo#215543
Email recipient tags now use the contact's full display name when a contact has no direct name or email address. This prevents business users from seeing a generic “Unnamed” label and makes it easier to identify the correct recipient in the mail composer.
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 send mail composer and add this partner as a recipient. ---> The recipient tag will show Unnamed. From [Commit 1], the fallback was given Unnamed. After this commit we'll use display_name as a fallback for no name and email. [Commit 1]: https://github.com/odoo/odoo/commit/cba81ac77d3bad1c686d95f3a9a67f6bde51c569 Task-4812554
Website forms now correctly update conditional fields when values are filled in automatically, such as a logged-in user's email. This prevents relevant follow-up questions from staying hidden until the visitor manually edits the form.
Original PR description
When [1] introduced a cached version of the form data to compute visibility, it did not take into account the values that are completed through `prefillValues`. Because of this, input events are required for those to be taken into account. This commit fixes this by re-evaluating the form content after the execution of `prefillValues`. Steps to reproduce: - Drop a "Form" snippet - Make "Your Question" field visible only if "Your Email" is set. - Save page. => Upon display, the email is populated with the user's email, but "Your Question" did not become visible. [1]: https://github.com/odoo/odoo/commit/027ce4e3991c9fefdbbb862a69f73e865a1100c8 task-jke
This update removes duplicated helper code used only in accounting tests. It helps keep the test suite easier to maintain without changing any customer-facing accounting behavior.
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
This fix updates the Malaysian e-invoicing POS test setup so it no longer relies on an enterprise-only component. It helps ensure community-only test runs work reliably without affecting customer-facing 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 fixes an unstable automated test in the barcode workflow by making sure the intended serial-number line is selected before removal. It helps keep quality checks reliable and reduces false test failures during development.
Original PR description
### Issue: The test 'test_remove_sublines_and_scan_serial_again' fails undeterministically because of the 'decrementLotLineQty' steps. The problem is that the lines related to the serial numbers are expected to be removed as follows: 1) Click on the subline referring to that serial number, which should make the -1 'Remove' button appear on that line. 2) Click on the Remove button. However, since every line in the barcode is an `.o_barcode_line`, the second substep does not wait for the first line you clicked on to be selected, so you might end up removing a different serial number. selected one, so you might end up removing a different serial number. the one you expected to remove. ### Fix: We will make these triggers more precise by waiting for the correct line to be selected and removed. As the helper cannot really be generic, we remove it. runbot-229224
Users can now share shortcut folders directly from the cog menu next to the breadcrumbs. This fixes a missing action in Documents and makes folder sharing more consistent, while also removing unused code behind the scenes.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#88512
This update prevents translation-related errors that could occur when generating referral sharing links or processing loan information. It improves reliability for users working in translated versions of the affected apps without changing business workflows.
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
Installing the Field Service Sales module no longer fails if the default Services product category was previously deleted. This prevents a setup-blocking error and lets users continue installing the module in customized databases.
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#89510