Daily updates from Odoo
Wednesday, April 9, 2025
26 changes · 18.0
Enhancements to existing features
When a sales order is completed through Point of Sale, any custom product description from the original sales order now appears unchanged on the invoice. This helps ensure customer invoices match the agreed sale details and reduces manual corrections.
Original PR description
In this commit: ------------------- - If we have custom description applied in the sale order for any product that custom description would be reflected as it is on the invoice when we settle that SO from POS. Task - 4645762
Resolved issues and error corrections
The website shop autocomplete component is now set to install automatically when its related apps are present. This helps ensure the expected search assistance is available without extra manual setup.
Original PR description
task-4715664 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes and streamlines internal automated testing tools used across several Odoo apps. It helps tests better match real user behavior and server responses, reducing false results and improving confidence in future releases.
Original PR description
New PR: https://github.com/odoo/odoo/pull/205405
When a discussion thread is created from a message, the message author is now added as a participant automatically. This helps ensure the right person stays included in follow-up conversations without manual action.
Original PR description
**Current behavior before PR:** When a thread is created from a message, the message author is not automatically added as a member of the thread. **Desired behavior after PR is merged:** The message author is implicitly added as a member when a thread is created from message. **Task**-4656632 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents product images from appearing cropped or overly zoomed when opening the Point of Sale register. It helps sales staff identify products more easily and keeps the checkout interface visually clear.
Original PR description
Description of the issue/feature this PR addresses:
> - When we open the POS register, products get cropped and zoomed in version 18.0
Link to OPW :[4571051](https://www.odoo.com/odoo/project/70/tasks/4571051)
**Steps:**
> - Install module: point_of_sale
> - Open Point of sale -> Continue selling in dashboard -> and show the images
Current behavior before PR:
Before fix:
After fix:
Desired behavior after PR is merged:
- All product images are appropriately shown after my fix
- The issue comes in version 18.0, saas~18.1 and saas~18.2
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue that could cause a server error when users added a task line on a contact form and selected a project. This improves reliability for customized contact forms using task-related fields.
Original PR description
Issue: Server error raised when selecting a project in a new task field added to a contact form Steps to reproduce: - Go to Contacts > select a contact - Click on toggle studio - Add the 'task' field in the contact form - Go back to the contact - In the task field, add a line - Select a project an error is raised This fix is to properly handles NewId objects in the domain construction. opw-4575975
This fix separates test setup settings for web components and their surrounding containers. It helps prevent incorrect test conditions, making future web interface changes safer and more reliable without affecting end users directly.
Original PR description
Before this commit, in the `mountWithCleanup` test helper, the same `env` object was passed to both the given component and the main component container. This is wrong as in some cases, the env given to the given component should include sub-env specific information, like the `config` key given to the `View` component (that shouldn't be given to the container). This commit ensures that these `env` objects can be configured separately. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated check for the website rental flow so it selects date range fields more reliably. It helps ensure the rental period selection experience is tested correctly and avoids false failures caused by keyboard focus moving to the wrong field.
Original PR description
In this commit, we prefer to use click on element instead of press Tab because tab will directly focus the other range period input.
This update improves internal automated tests by enforcing consistent data types and simplifying test setup definitions. It helps reduce false test failures and supports smoother ongoing maintenance across several Odoo apps, without changing day-to-day user features.
Original PR description
New PR: https://github.com/odoo/enterprise/pull/83169
A Documents app test was adjusted so it no longer fails when French accounting data adds an extra company to the test user. This improves reliability of automated checks without changing business features or user workflows.
Original PR description
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user…
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user having another company : base.demo_company_fr
This creates the following error message when running the tests:
```Py
FAIL: TestDocumentsControllers.test_upload_internal_multi_company_defaults
Traceback (most recent call last):
File "/home/odoo/src/enterprise/documents/tests/test_controllers.py", line 953, in test_upload_internal_multi_company_defaults
self.assertEqual(self.user_admin.company_ids, main_company | comp)
AssertionError: res.company(28, 1, 110) != res.company(1, 110)
```
with the following command :
```bash
python3 odoo-bin --addons-path="addons/,../enterprise/" -d test_4507424 -i documents,accountant,l10n_fr_account --test-tags .test_upload_internal_multi_company_defaults
```
(make sure to use the correct python3, odoo-bin, and addons-path)
This commit fixes the test by removing the constraint that self.user_admin can only have 2 companies
After this commit, the test is successful with the same configuration and execution command
opw-4700255
opw-4507424Code cleanup and technical improvements
This refactor changes how Odoo’s automated web tours detect page elements, making the process simpler and less dependent on timing assumptions. It should reduce inconsistent tour failures and make related issues easier to understand and resolve, with no intended direct change for end users.
Original PR description
In this commit, we're refactoring macro.js by completely changing its operation. To detect triggers in the DOM, we no longer rely on DOM mutations, but instead check for each frame to see if the trigger is in the DOM. Once the trigger is found, we perform the action and move on to the next step. This significantly simplifies understanding of how macro.js works, tours, and, more importantly, the bugs that can occur in tours. This also avoids many indeterministic errors that could occur in the tours due to the completely arbitrary "checkDelay" parameter (the time period after which there are no more mutations before the element is checked to see if it is in the DOM). This checkDelay parameter is therefore no longer used. It will be completely removed from the codebase in a future PR.
Miscellaneous changes
- have a follower with a portal partner linked to a specific company "portal" user is important here because internal users don't have multi-company rule. - view the chatter with a user which has no access to that company - the chatter is currently locked by an ACL error The follower should be displayed instead. task-4648765 Forward-Port-Of: odoo/odoo#203808 Forward-Port-Of: odoo/odoo#201864
Original PR description
- have a follower with a portal partner linked to a specific company "portal" user is important here because internal users don't have multi-company rule. - view the chatter with a user which has no access to that company - the chatter is currently locked by an ACL error The follower should be displayed instead. task-4648765 Forward-Port-Of: odoo/odoo#203808 Forward-Port-Of: odoo/odoo#201864
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In t
Original PR description
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In that case, `displayed` will be undefined. a0732ec87edbb7fee6ebc76ea093bc8a52fd3fad didn't check if displayed was defined. It also checked the length of non-string values. While it doesn't cause an error, it doesn't make sense. A comparison of `typeof displayed === "string"` is not enough, because we also need to handle Markup elements. opw-4572496 Forward-Port-Of: odoo/odoo#205256 Forward-Port-Of: odoo/odoo#204816
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format - Create an invoice: * Customer: [the Spanish customer] * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected because
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format -…
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create or edit a Spanish customer and set "Facturae" as eInvoice format - Create an invoice: * Customer: [the Spanish customer] * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected because "ReceiverTransactionReference" and "ReceiverContractReference" are not defined for each "InvoiceLine" element. There are just defined for the invoice in general in "FileReference" element. According to the official documentation https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx they can be defined in "InvoiceIssueData" and "InvoiceLine". FACe seems to require it in "InvoiceLine". **Solution:** Also add "ReceiverContractReference" in "InvoiceLine" and fall back on customer reference of the invoice for "ReceiverTransactionReference" of the line. opw-4579987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204294
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of
Original PR description
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of the python running the test, which might be different than the python running pylint. To limit the risks of contamination, strip out any path starting with one of the `sys.$CATEGORY_prefix` entries. Forward-Port-Of: odoo/odoo#205194
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: |
Original PR description
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: | # of lines with MTO | Before | After | |---------------------|---------|--------| | 20 | 3:48 | 2:48 | | 10 | 1:45 | 1:18 | ### Reference: opw-4629884 Forward-Port-Of: odoo/odoo#204808
* applies to: `l10n_in_edi_ewaybill`, `l10n_in_ewaybill_stock` * Before this commit: When there were multiple alerts, the code handled all alert messages correctly and calculated the `distance` as expected. However, when there was only a single alert related to distance, the process would get stuck. * After this commit: The code now also handles cases with a single distance-related alert message, ensuring proper detection and processing in all scenarios. > No Task ID --- I confirm
Original PR description
* applies to: `l10n_in_edi_ewaybill`, `l10n_in_ewaybill_stock` * Before this commit: When there were multiple alerts, the code handled all alert messages correctly and calculated the `distance` as expected. However, when there was only a single alert related to distance, the process would get stuck. * After this commit: The code now also handles cases with a single distance-related alert message, ensuring proper detection and processing in all scenarios. > No Task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205054
Steps to reproduce: - Install apps accounting, purchase and stock. - Create a PO with a different currency than the main currency. - Add a least one PO line. - Confirm the PO and mark the quantities as received. - Create a vendor bill and try to link the PO -> Traceback. Since commit 90158f6, the `balance` of the `account.move.line` is computed before the call to `_compute_all_tax` when importing a PO. Before, it wasn't computed yet and was equal to 0. The line `amount_currency` isn't co
Original PR description
Steps to reproduce: - Install apps accounting, purchase and stock. - Create a PO with a different currency than the main currency. - Add a least one PO line. - Confirm the PO and mark the quantities as received. - Create a vendor bill and try to link the PO -> Traceback. Since commit 90158f6, the `balance` of the `account.move.line` is computed before the call to `_compute_all_tax` when importing a PO. Before, it wasn't computed yet and was equal to 0. The line `amount_currency` isn't computed yet at this point, it is always 0. Since the `rate` is computed as `amount_currency`/`balance`, it is always computed to 0, which then causes a `ZeroDivisionError` in further computations. [opw-4710499](https://www.odoo.com/odoo/project/967/tasks/4710499) Forward-Port-Of: odoo/odoo#205195
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
Original PR description
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing. To reproduce this issue: 1) Install `mass_mail` 2) Create new mailings with `contact_list_ids` and make sure to give the value for `preview` in the settings page. 3) Don't select any `Mail Body` templates. 4) Schedule the record with the `previous day`. 5) An Error was encountered in the terminal. Error:- ``` TypeError: expected string or bytes-like object ``` A corn job runs w
Original PR description
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing. To reproduce this issue: 1) Install `mass_mail` 2) Create new mailings with `contact_list_ids` and make…
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing.
To reproduce this issue:
1) Install `mass_mail`
2) Create new mailings with `contact_list_ids` and make sure to give
the value for `preview` in the settings page.
3) Don't select any `Mail Body` templates.
4) Schedule the record with the `previous day`.
5) An Error was encountered in the terminal.
Error:-
```
TypeError: expected string or bytes-like object
```
A corn job runs when the user `schedules` a mail, in which `action_send_mail` triggers.
In that method while composing values, `body` is used to get values from `mail.body_html`.
https://github.com/odoo/odoo/blob/e37c393d415d686584487f9ad92f062279504cf8/addons/mass_mailing/models/mailing.py#L1043-L1046
Because when the user doesn't select the body template its value will be `false` which leads to the above traceback,
as the `re.search` method is used between preview and body.
https://github.com/odoo/odoo/blob/e37c393d415d686584487f9ad92f062279504cf8/odoo/tools/mail.py#L500
This commit will resolve the issue by giving a fallback value of empty string when the user doesn't select the body template.
sentry-5983589884
Forward-Port-Of: odoo/odoo#204167
Forward-Port-Of: odoo/odoo#166962Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These of
Original PR description
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These offers, though, don't need that safety net, and can thus just be ignored. If their stock needs to be sync someday, the stock cron will take care of these. opw-4684657 opw-4684605 Forward-Port-Of: odoo/enterprise#83023
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347
Original PR description
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347 Forward-Port-Of: odoo/enterprise#82682
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
Original PR description
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
## Steps to reproduce: 1. Install l10n_mx. 2. Activate developer mode. 3. Activate Download XSD files (XML validation). 4. Go to accounting configuration > chart of accounts 5. Make sure here to have 2 accounts like 702.XXX. One should have the credit tag and the other one the debit one. 8. Go to reports and select Trial Balance. 9. Click on the download drop list and select COA SAT ## Issue: Up to now we have just intentionally marked this accounts as no valid, we can see that
Original PR description
## Steps to reproduce: 1. Install l10n_mx. 2. Activate developer mode. 3. Activate Download XSD files (XML validation). 4. Go to accounting configuration > chart of accounts 5. Make sure here to have…
## Steps to reproduce: 1. Install l10n_mx. 2. Activate developer mode. 3. Activate Download XSD files (XML validation). 4. Go to accounting configuration > chart of accounts 5. Make sure here to have 2 accounts like 702.XXX. One should have the credit tag and the other one the debit one. 8. Go to reports and select Trial Balance. 9. Click on the download drop list and select COA SAT ## Issue: Up to now we have just intentionally marked this accounts as no valid, we can see that inside trial_balance.py for l10n_mx_reports at L201 this was a known limitation. ## Solution: As we can see from the technical anex in the mexican goverment site https://www.gob.mx/sat/documentos/contabilidad-en-medios-electronicos-anexo-tecnico we can see that there are asset, liability and equity accounts which, by their nature, can be presented as debit or credit. ### Example Scenario: Let's say we have two hypothetical accounts, 701.01.01 and 701.01.02: Account 701.01.01 (perhaps an asset account) would be a Deudora (D). Account 701.01.02 (perhaps a liability account) would be Acreedora (A). The nature (D or A) depends on the type of account according to the categorization provided in the document. So, - Accounts related to Assets, Costs, and Expenses should generally be Deudora (D). - Accounts related to Liabilities, Equity, and Income should generally be Acreedora (A). - Some special accounts may vary and can be both Deudora (D) and Acreedora (A). opw-4185713 Forward-Port-Of: odoo/enterprise#82588 Forward-Port-Of: odoo/enterprise#70113
Vendor bills and purchase orders should always be negative on a budget with type `both`, as they are expenses. - Create a budget with type `both` - Create a sales invoice and several purchase orders and vendor bills - The budget report's purchase order amounts are positive and added up. As soon as they are billed they become negative. Task [link](https://www.odoo.com/odoo/project/967/tasks/4568067) opw-4568067 Forward-Port-Of: odoo/enterprise#81356
Original PR description
Vendor bills and purchase orders should always be negative on a budget with type `both`, as they are expenses. - Create a budget with type `both` - Create a sales invoice and several purchase orders and vendor bills - The budget report's purchase order amounts are positive and added up. As soon as they are billed they become negative. Task [link](https://www.odoo.com/odoo/project/967/tasks/4568067) opw-4568067 Forward-Port-Of: odoo/enterprise#81356
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692
Original PR description
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692