Tuesday, March 25, 2025
15 changes · 17.0
Resolved issues and error corrections
Stages created in the To-Do app no longer disappear after reloading the page. They are correctly shown as personal stages when they are not linked to a specific project, helping users keep their task organization intact.
Original PR description
Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169
This update fixes unstable automated tests in the base automation area by waiting for the expected page content more reliably. It helps reduce random test failures in validation pipelines, making release checks more dependable without changing user-facing functionality.
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
The analytic distribution widget now correctly uses context settings defined on the field. This helps ensure accounting-related actions behave as configured and reduces errors in workflows that rely on those settings.
Original PR description
Description of the issue/feature this PR addresses: Previously, the `context` attribute set in the `analytic_distribution` field was not usable in the related `AnalyticDistribution` widget. For…
Description of the issue/feature this PR addresses:
Previously, the `context` attribute set in the `analytic_distribution` field was not usable in the related `AnalyticDistribution` widget. For example:
```xml
<field name="analytic_distribution" widget="analytic_distribution"
groups="analytic.group_analytic_accounting"
optional="show"
options="{'product_field': 'product_id', 'account_field': 'account_id', 'force_applicability': 'optional'}"
context="{'context_key': 'context_value'}" <!-- not usable in the widget -->
/>
```
Current behavior before PR:
The `context` was neither extracted nor propagated to relevant methods, causing issues in operations dependent on it.
Desired behavior after PR is merged:
This fix ensures that the `context` is properly handled and propagated throughout the component, enabling its use in ORM interactions and improving the widget's functionality.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects how style values are generated for the web search panel, preventing broken CSS from being included in the application. It helps ensure the interface displays consistently and avoids visual glitches caused by malformed styling rules.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties
This fix makes project-related sales item lookups more reliable by ensuring pending data updates are saved before the lookup runs. It helps prevent intermittent test failures and reduces the risk of inconsistent project profitability or sales information during processing.
Original PR description
Description of the issue/feature this PR addresses: Tests dependent on project.task's _get_sale_order_items method fail intermittently. This was noted while migrating a custom module from 15.0 to…
Description of the issue/feature this PR addresses: Tests dependent on project.task's _get_sale_order_items method fail intermittently. This was noted while migrating a custom module from 15.0 to 17.0 and ensuring it passed all tests. In debugging, it was noted that the project.task and sale.order.line records expected to be found by the query in project.project's _get_sale_order_items_query were in fact not present in the database despite the objects being accessible in the memory. This was confirmed by observing records in memory at a break point during test debugging as well as running SQL queries using the same debug environment. Current behavior before PR: Intermittent test failures at: - sale_project/tests/test_sale_project.py:143 - sale_project/tests/test_project_profitability:175 Desired behavior after PR is merged: Sale order items are correctly fetched by project._get_sale_order_items() regardless of whether there are pending computations and updates to the database. Tests mentioned above now pass as expected more consistently. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website searches using this result layout no longer trigger an unnecessary warning. This keeps logs cleaner for administrators without changing how search results appear or behave for users.
Original PR description
This commit fixes a warning raised each time a user runs a search on a website where the results are listed using the list_hybrid template from website/views/website_templates.xml. As the warning points out, the t-key directive is unused. **Warning prior to this fix:** Unknown directives or unused attributes: ["t-key"] in website.list_hybrid **Expected behaviour after this fix:** No more warning and no functionality is lost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Branch companies can no longer open the Peru tax report, which was not intended for their use. This avoids confusing errors and ensures the report is only accessed by eligible main companies.
Original PR description
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580
This update corrects how Studio styling values are inserted into generated stylesheets. It prevents broken visual rules from being produced, helping the Studio interface display consistently.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties
Miscellaneous changes
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For m
Original PR description
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on…
LATAM task 1299 / Adhoc Task 47453 --- ### Description of the issue/feature this PR addresses: Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes. For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448 ### Current behavior before PR: Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals  ### Desired behavior after PR is merged: We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201257
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201186
Original PR description
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201186
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_reg
Original PR description
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_100_199/archivos_24/DISENOS_LOGICOS_190-2024.pdf https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/GI10/Instrucciones/instr_mod190_es_es.pdf @moduon MT-8853 @rafaelbn @etobella @pedrobaeza @jco-odoo @chklop --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198546
## How to reproduce the issue: - In the Gantt view of the **All Tasks** view in **Project**, create a new task with allocated hours. - Set the task to last **at least two days** and set its **end date** between **12:00 AM and 3:00 AM** (or its **start date** between **9:00 PM and 12:00 AM**). Instead of displaying the **task name**, the **display name** shows the **start and end times**. This happens because if a task **spans across days** but its start/end time is within **3 hours o
Original PR description
## How to reproduce the issue: - In the Gantt view of the **All Tasks** view in **Project**, create a new task with allocated hours. - Set the task to last **at least two days** and set its **end…
## How to reproduce the issue: - In the Gantt view of the **All Tasks** view in **Project**, create a new task with allocated hours. - Set the task to last **at least two days** and set its **end date** between **12:00 AM and 3:00 AM** (or its **start date** between **9:00 PM and 12:00 AM**). Instead of displaying the **task name**, the **display name** shows the **start and end times**. This happens because if a task **spans across days** but its start/end time is within **3 hours of midnight**, the display name includes the **start and end time** in the **week and month scale view**. Commit https://github.com/odoo/enterprise/commit/1713de228c772e43d756f068dc8b7258e3299af0 introduced a fix via `spanAccrossDays` to display the **start and end times** for tasks (shifts) where the **startDate** or **endDate** falls within **3 hours of midnight**. If `spanAccrossDays` is **false**, then the pill display name is the **start and end time** in the **week and month scale view**. However, this behavior also applied to tasks spanning more than two days. After this commit, if the pill **spans more than two days**, the pill name will only be the **task name**: - **Example 1:** **Start:** *01/01/2025, 4 PM*, **End:** *02/01/2025, 1 AM* → **Display name: Start/End Time - Task name** (since the end time is before 3 AM). - **Example 2:** **Start:** *01/01/2025, 4 PM*, **End:** *03/01/2025* → **Display name: Task Name** (since the task spans more than two days). opw-4474991 Forward-Port-Of: odoo/enterprise#78174
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to c
Original PR description
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to category c2. - You are now an approver of the approval request. This commit fixes the issue by reseting the list of approvers to only take the ones configured on the category. task-4637083 Forward-Port-Of: odoo/enterprise#81129
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Original PR description
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were p
Original PR description
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were provided from FedEx support. opw-4461150 Forward-Port-Of: odoo/enterprise#79617