Monday, February 24, 2025
20 changes · saas-18.1
Enhancements to existing features
The IoT box image setup now includes a shortcut to reset an Odoo repository from the public Odoo source, matching an existing development-branch shortcut. This helps teams maintain or recover IoT box environments more consistently with less manual setup.
Original PR description
We already added an alias to reset odoo on a development branch (odoo-dev), this commit brings the equivalent to reset on a public version on odoo. Task: 4593093
Resolved issues and error corrections
This change fixes an unstable automated test in the Mail app that could fail depending on employee status data from HR. It helps keep quality checks reliable so valid updates are less likely to be blocked by false test failures.
Original PR description
Before this PR, the `last_seen_message_should_send_notification_only_once` test was sometimes failing. This is due to the assertion of `im_status` being set to `offline` while the hr module overrides statuses with values such as `leave_offline`. This PR fixes the issue. runbot-112747 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
Miscellaneous changes
It would help people to be able to search on the Total amount for invoices task-4575021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197744
Original PR description
It would help people to be able to search on the Total amount for invoices task-4575021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197744
Live chat chatbot responses now appear immediately instead of waiting 1.5 seconds. This makes automated conversations feel faster and reduces unnecessary waiting for website visitors.
Original PR description
This PR removes the chatbot 1.5s delay before show the answer. Task-4577776
Bookkeepers can now see the general information section for bank-related products and accounts as intended. This fixes an access display issue caused by a view setting that unintentionally replaced the allowed user groups.
Original PR description
…eneral info The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 X-original-commit: 68f6c1f9fd3ff6762c98e1a405ade035129efce0
Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal
Original PR description
Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal dashboard view due to missing access After this commit: The Accounting module and journal dashboard view work correctly for non-admin users Reproducing the issue in Runbot: https://drive.google.com/file/d/1YIjvoXNDe6atVyzWC1dVU58rDFnoYH7x/view?usp=drive_link opw-4551932 Forward-Port-Of: odoo/odoo#197520
in this commit, we improve the method to look for indeterminisms in the tours. The method waits a certain amount of time once the trigger has been found and then checks if the element is still visible, if it has changed or if it has undergone mutations. We take advantage of this commit to also improve the method to find the trigger in the DOM (we check that body does not have the class o_is_blocked and that the frame is is-ready=true if the element is in an iframe) Forward-Port-Of: odoo/
Original PR description
in this commit, we improve the method to look for indeterminisms in the tours. The method waits a certain amount of time once the trigger has been found and then checks if the element is still visible, if it has changed or if it has undergone mutations. We take advantage of this commit to also improve the method to find the trigger in the DOM (we check that body does not have the class o_is_blocked and that the frame is is-ready=true if the element is in an iframe) Forward-Port-Of: odoo/odoo#198596
Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198719
Original PR description
Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198719
… taxes Bug introduced by https://github.com/odoo/odoo/commit/90949cd56da77da3645922f670f86483d7859c2f See tests in this commit for a concrete use case. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198805
Original PR description
… taxes Bug introduced by https://github.com/odoo/odoo/commit/90949cd56da77da3645922f670f86483d7859c2f See tests in this commit for a concrete use case. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198805
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases. ### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry" - On the Journal Entry, add the something to Customer Reference - Go back to the report, you should see the invoice name and Customer reference are shown twice ### Cause: The bug appeared in this commit (https://github.com/odoo
Original PR description
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases. ### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the…
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases.
### Steps to reproduce:
- Go to Accounting > Reports > Aged Receivable
- Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry"
- On the Journal Entry, add the something to Customer Reference
- Go back to the report, you should see the invoice name and Customer reference are shown twice
### Cause:
The bug appeared in this commit (https://github.com/odoo/odoo/commit/eb872c09897eb9edd5b6e5b9e8171fa6764be3dc) when computing the line display_name, if there is a move name, a reference and `line_name`.
The variable `line_name` already include the reference: `name = f'{line.move_id.ref} - {line.move_id.payment_reference}'` (https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7)
So `line_name` is different from `move_name` and the result is: `line.move_id.name (line.move_id.ref) line.move_id.ref - line.move_id.payment_reference`
### Solution:
The previous fix prevents `line_name` from having the same string twice. But it does not fix the issue when the invoice name and Customer reference are different.
This commit checks if `move_name` and `move_ref` are included in `line_name` before adding it to the display name.
This is not optimal as it makes this code dependent on the format of `line_name`.
opw-4492298
Forward-Port-Of: odoo/odoo#196570Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196900 Forward-Port-Of: odoo/odoo#194191
Original PR description
Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196900 Forward-Port-Of: odoo/odoo#194191
Steps to reproduce: 1) Install Click & Collect 2) Configure a standard delivery to deliver only to Belgium and publish 3) Unpublish the others 4) Go to /shop page add a storable product 5) Proceed to /checkout add two addresses one with US country, the other with Belgium 6) Try to click on US partner then on Belgium then again on US 7) Observe traceback After this commit we skip the check in _canEnableMainButton if a radio element is not found. Forward-Port-Of: odoo/odoo#197721
Original PR description
Steps to reproduce: 1) Install Click & Collect 2) Configure a standard delivery to deliver only to Belgium and publish 3) Unpublish the others 4) Go to /shop page add a storable product 5) Proceed to /checkout add two addresses one with US country, the other with Belgium 6) Try to click on US partner then on Belgium then again on US 7) Observe traceback After this commit we skip the check in _canEnableMainButton if a radio element is not found. Forward-Port-Of: odoo/odoo#197721
Problem: The complementary information were not displayed on the form view of a rule in a route. These informations are supposed to change depending on the Supply Method that has been selected, but since version 18, they always displayed the same information. The suffix, which is used to give information depending on the Supply Method, is not being used anymore and needs to be displayed again. Steps to reproduce: - Go to a route in Inventory and pick a rule - With Pull From set as Action,
Original PR description
Problem: The complementary information were not displayed on the form view of a rule in a route. These informations are supposed to change depending on the Supply Method that has been selected, but since version 18, they always displayed the same information. The suffix, which is used to give information depending on the Supply Method, is not being used anymore and needs to be displayed again. Steps to reproduce: - Go to a route in Inventory and pick a rule - With Pull From set as Action, change the Supply Method - The helper on the right won't change but it should Fix: The suffix was added to the message that has to be displayed. opw-4511907 Forward-Port-Of: odoo/odoo#197741
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
Original PR description
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character Before this commit- if a partner with pincode `000000` then no validation error After this commit- if a partner with pincode `000000` invalid pincode validation raises Description of the issue/feature this PR addresses: Current behavior before PR: Desired
Original PR description
As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character Before this commit- if a partner with pincode `000000` then no validation error After this commit- if a partner with pincode `000000` invalid pincode validation raises 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#198302
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79623 Forward-Port-Of: odoo/enterprise#76341
Original PR description
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79623 Forward-Port-Of: odoo/enterprise#76341
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific
Original PR description
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting,…
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific section inside the accounting group. Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group. **Root Cause** The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly. **Fix** To avoid modifying a module unrelated to Brazilian taxes, which might have a broader impact, the existing behaviour is left unchanged. Instead, a new section has been added within the accounting tab to display the necessary information. This ensures that only the l10n_br_avatax module is modified. Opw-4533760 Forward-Port-Of: odoo/enterprise#79245
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#79044
Original PR description
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#79044
Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no dead
Original PR description
Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no deadline is computed (bad configuration) opw:4563223 Forward-Port-Of: odoo/enterprise#79674
### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to
Original PR description
### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to choose SEPA and by doing this it uses the 'sepa_ct' payment method: https://github.com/odoo/enterprise/blob/033b3f7773e0dd41cb1dfcc5542d19b22f5fe609/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L26 ### Solution: Add a new value to choose from other than SEPA for the Report Format and make this format use the payment method iso20022_ch. opw-4437968 Forward-Port-Of: odoo/enterprise#79858