Daily updates from Odoo
Thursday, January 2, 2025
28 changes · 18.0
New functionality added to Odoo
This change adds a new linked custom extension repository to the enterprise codebase. It helps include organization-specific Odoo 18 customizations as part of the project setup, with minimal direct impact on everyday users until those customizations are used.
Enhancements to existing features
This change improves how Odoo counts expenses linked to a sales order by making the lookup more efficient. Users should see faster loading of the related expenses smart button on sales order forms, especially where many expenses exist.
Original PR description
## Description `sale.order._compute_expense_count` does a `_read_group` with a domain only based on `sale_order_id`, which is an unindexed FKey, leading to a guaranteed `Seq.Scan`. This `_compute_expense_count` is used to compute the count of related expenses for a `sale.order`, shown as a smart button on the form view, which is a frequent operation. ## Reference task-3977983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update cleans up and reorganizes Argentina withholding and perception tax records so they are easier to use and better aligned with current tax terminology. It also removes outdated duplicate taxes, corrects tax grouping, and relaxes a form requirement when a tax is not an Argentina withholding tax.
Original PR description
_l10n_ar_withholding_: 1) Make not required "WTH Tax" (l10n_ar_tax_type) field in account.tax form view if "Argentina Tax Type" (l10n_ar_type_tax_use) is 'customer' or 'supplier'. So, if the tax is…
_l10n_ar_withholding_: 1) Make not required "WTH Tax" (l10n_ar_tax_type) field in account.tax form view if "Argentina Tax Type" (l10n_ar_type_tax_use) is 'customer' or 'supplier'. So, if the tax is not for argentina withholding then the "WTH Tax" field will not be required. 2) "Earnings WTH A" tax is deleted because is not used any more. 3) Earnings WTH taxes have "VAT 21%" as "Tax Group", in this pr is changed to "Withholding" tax group. 4) Change IIBB Withholding and Earnings 'name' and 'description' fields on account.tax model. Delete words "incurred" or "applied", change word 'earnings' to 'profits'. Also adapt translations. WTH SUSS and WTH Earnings taxes are duplicated, delete both taxes from addons/l10n_ar_withholding/data/template/account.tax-ar_ri.csv. IIBB withholdings and perception state names abreviations are changed, for example: old name --> IIBB WTH Chubut I, new name --> IIBB WTH CHT 0%. 5) Update addons/l10n_ar_withholding/data/template/account.tax-ar_ex.csv external ids with new state name abreviations and also profits withholding taxes (example: old id --> ex_tax_withholding_profits_regimen_31_insc, new id: ex_tax_withholding_profits_regimen_31_insc). 6) Change 'amount_type' from 'fixed' to 'percent' on taxes on addons/l10n_ar/data/template/account.tax-ar_ex.csv 7) Create file addons/l10n_ar_withholding/data/template/account.tax-ar_base.csv with iibb withholding iibb incurred taxes and delete those taxes from addons/l10n_ar_withholding/data/template/account.tax-ar_ri.csv 8) Add on file addons/l10n_ar_withholding/data/template/account.tax-ar_ex.csv iibb withholding applied taxes and profits withholding applied taxes . Delete those taxes from addons/l10n_ar_withholding/data/template/account.tax-ar_ri.csv . 9) Rename tax group file from addons/l10n_ar_withholding/data/template/account.tax.group-ar_ri.csv to addons/l10n_ar_withholding/data/template/account.tax.group-ar_base.csv 10) Adapt addons/l10n_ar_withholding/demo/account_demo.py and addons/l10n_ar_withholding/tests/test_withholding_ar_ri.py with the new external ids. _l10n_ar_: Change perception 'name', 'description' and 'invoice_label' fields on account.tax model. On field 'name' set the same state abbreviation as abbreviations applied on withholding ar taxes. On the field 'description' delete the word "applied or incurred". On field 'invoice_label' delete the last letter (I or A). Also translations are adapted. _**Task Adhoc side**_: 43411 _**Task Latam side**_: 1289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves performance in the Expenses app by making expense lines easier for the system to find by their related expense sheet. Users may notice faster loading or processing in areas that read, submit, or recalculate expense sheet information, especially as data volume grows.
Original PR description
## Why
- Inverse of the One2many `expense_line_ids`, the ORM will search on it to resolve the read on the field
- Used as a traversable dependency of a few compute methods (`@api. depends('sheet_id.xxx')`), index will be hit when ORM resolves the computation of dependencies to know what compute method to call when the dependency changed.
- Frequently used as the traversal field of related fields, index will be hit when reading on the field in SQL in `_traverse_related_sql`.
- Using Full index, as there aren't many `NULL`/`False` entries, as it's moslty pending expense lines that are pending for reporting. So a search on the NULL criteria (done in `get_expenses_to_submit`) will hit the index.
## Reference
task-3977983
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update changes the security support documentation to show that Odoo 15.0 is no longer actively supported. It helps customers and partners plan upgrades and understand which versions remain covered for security maintenance.
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
Resolved issues and error corrections
The tax form for Argentine withholding now shows the Minimum Threshold field for applicable perception taxes. This helps users correctly view and manage threshold settings without hidden information on the tax form.
Original PR description
It is needed to make not invisible "Minimum Treshold" on applied perceptions AR taxes. Task Adhoc side: 43625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The TDS Entry button is now shown for payments that have already been marked as paid, not only those still in process. This helps users complete or review withholding tax entries without needing the payment to remain in an intermediate state.
Original PR description
Before This Commit: - The TDS Entry button is visible only in `In Process` state. After This Commit: - The TDS Entry button is visible in both `In Process` and `Paid` state. Task: 4432364
This change prevents a sales-related automated test from failing when the broader sales management app is not installed. It improves reliability for Odoo.sh projects that use Sales features through custom modules without enabling the full Sales Management menu.
Original PR description
### Description of the issue this PR addresses: Test TestSaleComboConfigurator.test_sale_combo_configurator (introduced with #186645) depends on the Sale menu being shown, but it isn't if the sale_management module is not installed. This change skips this test in this case. ### Current behavior before PR: The test fails on odoo.sh with custom modules that only depend on sale and not sale_management. ### Desired behavior after PR is merged: The test succeeds in the condition mentionned above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents production spreadsheets from blocking copies of older versions when referenced fields or data sources have since changed or been removed. Development and testing environments still keep the validation checks so dashboard issues can be caught before release.
Original PR description
Following #184846, the data validation is no longer necessary in a production context. Moreover, it currently limits some capacities for the user to user the history of the spreadsheets. Eg: - Create…
Following #184846, the data validation is no longer necessary in a production context. Moreover, it currently limits some capacities for the user to user the history of the spreadsheets. Eg: - Create a new field with studio - Add a datasouce in a spreadsheet which relies on that field - make a bunch of revision - Delete the field you created - Go back to the spreadsheet - Open the version history and try to "make a copy" of some recent revision => it will throw as you try to create a spreadsheet with invalid fields However, the data validation still make sense to alert developpers to adapts dashboards when they change the schema of some tables. This revision deactivates the data validation on production which ensures that the last point is still respected while developping (will be detected by runbot tests). Task: 4363803 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 sales product catalog now keeps the discounted pricelist price visible after a product is added to an order. This prevents customers or sales teams from seeing the price jump from the discounted amount back to the original price when using pricelists and discounts.
Original PR description
Steps: - install sale and activate pricelists - activate discounts from setting - create a product with price 100 - create a pricelist with of 2% discount on the product - create a sale order with the new pricelist - open the new product in catalog and add 1 quantity Issue: - the price for the product changes from 98 to 100 after adding quantity Cause: - the display price in catalog comes from either SOL price unit or computed from SO pricelist_id. When discounts setting is active the SOL price_unit is pricelist price without discount else with discount. Hence when first time the catalog is loaded it is computed from SO's pricelist and after adding a quantity it takes pricelist price without discount from SOL Fix: - Updated `_update_order_line_info` so it will always take the pricelist computed price and not SOL unit_price opw - 4345503 opw - 4406373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an unnecessary hidden field from the French localization company form. It prevents a test failure on Odoo SH and helps keep the module compliant with Odoo view validation rules.
Original PR description
Description of the issue/feature this PR addresses: The field **is_france_country** was added to the **l10n_fr.res_company_form_l10n_fr** view with the invisible attribute set to 1. This caused an error on Odoo SH due to commit #162009. Since fields used in Python expressions are automatically added to the view, we do not need to keep it. Current behavior before PR: When you enable tests for the module l10n_fr, you have the following error : Please indicate why the always invisible fields are present in the view, or remove the field tag. Addons: 'l10n_fr' Views: ['res_company_form_l10n_fr'] Desired behavior after PR is merged: Pass the test test_uncommented_invisible_field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Firefox where users could not open the editing popover for button-styled links in the HTML editor. Users can now click and edit these links normally, improving reliability when preparing website or email content.
Original PR description
**Current behavior before PR:** - In Firefox, the user-select: none style disabled text selection and prevented the cursor from being placed inside a button. This caused the button click to fail in opening the link popover. **Desired behavior after PR is merged:** - The user-select property for the btn class is changed from none to auto. This allows users to place the cursor inside the button-styled link, enabling editing and ensuring the link popover can be opened as expected. task:4358091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Partner Ledger no longer crashes when partner names start with special characters such as '~' and report grouping is enabled. This ensures accounting users can open and review ledgers normally even when customer or vendor names contain unusual characters.
Original PR description
Steps --------- 1. Debug mode 2. Go to Accounting 3. Configuration > Management > Accounting Reports 4. Open "Partner Ledger" 5. In the Options tab, set the "Prefix Groups Threshold to 3" 6. Create 3…
Steps
---------
1. Debug mode
2. Go to Accounting
3. Configuration > Management > Accounting Reports
4. Open "Partner Ledger"
5. In the Options tab, set the "Prefix Groups Threshold to 3"
6. Create 3 different partners, each having their name starting with a '\~'
7. Create an invoice for each of the partners created in previous steps
8. Open the partner ledger -> Traceback
Problem
---------
When there are more lines in the report than the prefix group value, the partners are grouped by names: P -> PA -> PAR, etc.
However, some partners could have a '\~' in their names making the groupby line_id \~account.report\~14|{"groupby_prefix_group": "\~"}\~\~. The line ID being split using the | and \~ characters, it causes some issues.
Solution
---------
Since the line ID format is fixed: markup\~model\~id|markup\~model\~id|... We can split from the back and hard limit the split to 2 to make sure we always have (markup, model and ID) no matter the content of the markup.
task-4420258When a quotation or sales order is deleted, its custom spreadsheet is now removed as well. This prevents order-specific spreadsheets from being reused accidentally in quotation templates, keeping sales data cleaner and more consistent.
Original PR description
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254
The chat window header buttons are now slightly larger, making them easier to click on desktop. This reduces small interaction frustrations for users who frequently use chat quick actions.
Original PR description
Click on quick ation button in Chat window header was a bit tedious in desktop. This happens because the clickable area is 24px x 24px. This commit makes it easier by increasing to 28px x 28px, thanks to explicit `p-1` on buttons. This ain't much but this gives less frustration to use chat window quick actions. <img width="601" alt="Screenshot 2025-01-02 at 18 23 47" src="https://github.com/user-attachments/assets/b0c09d0c-906b-43b9-b8f7-6fb954c34998" />
Miscellaneous changes
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Sel
Original PR description
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task…
Before this commit, when the user sets a project as a default value for his tasks, that default value will also be applied inside To-Do app because a to-do is in fact a private task (that is, a task without any project set). This commit adds a default value inside the context of the main action used in To-Do to make sure the default value for `project_id` field in To-Do is false and nothing else. Steps to reproduce ================== 1. Install Project app 2. Go to Project app 3. Select/create a project 4. Select/create and edit a task inside 5. Enable the debug mode 6. Click on debug menu and select `Set Default Values` 7. Apply `project = <your project selected/created>` and save 8. Go to To-Do app 9. Create a to-do Expected Behavior ----------------- A to-do should be created without any issue in the kanban view. Current Behavior ---------------- A form view will be displayed inside a modal to create the to-do but the form view is in fact the one used in Project app and the project set is the one set as default value instead of having no project since the user is creating a to-do and not a task inside that project. Forward-Port-Of: odoo/odoo#191583
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Original PR description
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes were not adapted correctly. For instance, in the statusbar widget, the title was ported as an `aria-label` attribute ("Current state" and "Not active state"), which overrides the actual status name. This commit fixes the above issue by removing the incorrect `aria-label` attributes and fixing logic for other ones like `aria-checked`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes
were not adapted correctly. For instance, in the statusbar widget, the
title was ported as an `aria-label` attribute ("Current state" and "Not
active state"), which overrides the actual status name.
This commit fixes the above issue by removing the incorrect `aria-label`
attributes and fixing logic for other ones like `aria-checked`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191494
Forward-Port-Of: odoo/odoo#183447- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
Original PR description
- edit the codition to check if the active model is HR to use the smae plan summary as the buttom rfom the employee from Task: 4237311 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#189480
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192058 Forward-Port-Of: odoo/odoo#191066
Original PR description
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192058 Forward-Port-Of: odoo/odoo#191066
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
Original PR description
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next t
Original PR description
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next to the QR code. opw-4337379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190976
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 ---
Original PR description
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191142
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#185448
Original PR description
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#185448
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
Original PR description
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Original PR description
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Previously, when a customer was selected or input was entered, the onboarding tour failed to proceed to the next step. With this fix, the tour will correctly advance when the user provides input. Without demo data, the database does not have Deco, so I used admin. task-4372470 Forward-Port-Of: odoo/enterprise#75100
Original PR description
Previously, when a customer was selected or input was entered, the onboarding tour failed to proceed to the next step. With this fix, the tour will correctly advance when the user provides input. Without demo data, the database does not have Deco, so I used admin. task-4372470 Forward-Port-Of: odoo/enterprise#75100
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and link
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create…
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and linked to the Global Invoice `l10n_mx_edi.document`, but if the link from document to attachment is complete, the opposite is not the case. `ir.attachment.res_id` has a value of 0, and, when checking access rights for `ir.attachment`, we will use the `_search` method in which one of three conditions, two of them having a `res_id` check, must be fulfilled for `ir.attachment` to be considered available to the user. https://github.com/odoo/odoo/blob/afdfbc4041f167ba6d6ff6c17b8432eb531df6b1/odoo/addons/base/models/ir_attachment.py#L561-L570 A user that did not Create Global Invoice and without `base.group_system` in their `groups_id` fulfills none of those conditions. ### Fix reasoning: The issue lies more within `res_id` not being `l10n_mx_edi.document.id` rather than a flaw in `_search`. This change should only apply when creating a Global Invoice. When sending an Invoice to the CFDI through the regular `action_send_and_print` process, `ir.attachment` is linked to `account.move` instead. opw-4365535 Forward-Port-Of: odoo/enterprise#76023 Forward-Port-Of: odoo/enterprise#75031