Wednesday, October 20, 2021
16 changes · master
Enhancements to existing features
CRM opportunity lists now show the expected closing date, making it easier for teams to monitor upcoming deals at a glance. This helps sales users prioritize follow-ups and track pipeline timing without opening each opportunity.
Original PR description
It is convenient to be able to keep an eye on the expected closing date of opportunities. Task-2668131
Code cleanup and technical improvements
This update removes unused HR-related code and outdated elements across Expenses, Time Off, and Work Entries. It helps keep the system easier to maintain without changing day-to-day user workflows.
Original PR description
*: hr_expense, hr_holidays, hr_work_entry_holidays - Remove unused template; - Remove unused fields (hr_expense); - Rename group_days_allocation to convey proper meaning; - Remove deprecated method. TaskID: 2665866 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
On the right panel of the mail editor, the icons of the mass mailing module do not match with the other icons. We will then update them to improve the consistency of the layout. The icons will now have the same background color as the other icons. task-2658133 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78163
Original PR description
On the right panel of the mail editor, the icons of the mass mailing module do not match with the other icons. We will then update them to improve the consistency of the layout. The icons will now have the same background color as the other icons. task-2658133 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78163
This is a followup on b6c688caa2bad1706443a7f950a268723b70e508, which has introduced a new bug. Consider two groups A and B in a given category, where B implies A and also A.id > B.id. For the sake of simplicity, assume that A.id=2 and B.id=1. Following the commit above, the name of the group selection field will be 'sel_groups_1_2'. Consider a user in group B. Because B implies A, this means that the user now belongs to both A and B. A call to read() on that user returns field 'sel_gr
Original PR description
This is a followup on b6c688caa2bad1706443a7f950a268723b70e508, which has introduced a new bug. Consider two groups A and B in a given category, where B implies A and also A.id > B.id. For the sake of simplicity, assume that A.id=2 and B.id=1. Following the commit above, the name of the group selection field will be 'sel_groups_1_2'. Consider a user in group B. Because B implies A, this means that the user now belongs to both A and B. A call to read() on that user returns field 'sel_groups_1_2' with value 2, which on the form view appears as the user belonging to A only. The error is in read(), which assumes that the group ids in the field name correspond to the implication order of the groups, which is no longer the case since b6c688caa2bad1706443a7f950a268723b70e508. Forward-Port-Of: odoo/odoo#78626
Description of the issue/feature this PR addresses: When invoicing a product with variants and a kit BOM for each of those variants, the Cost Of Good Sold had the wrong amount. As you can see on the screenshot, the COGS in the invoice for the product Tic-Tac (orange) has a price of 7, it should be 9 as shown in the BoM Structure & Cost of Tic-Tac (orange), instead it's using the value of the Tic-Tac (coca)  has a price of 7, it should be 9 as shown in the BoM Structure & Cost of Tic-Tac (orange), instead it's using the value of the Tic-Tac (coca)  Current behavior before PR: The function _stock_account_get_anglo_saxon_price_unit() on the sale_mrp module was selecting the product bom from the product_template of our product. However variants share the same product template, resulting in all variant boms to be selected, and the first one in the list being arbitrarily selected; most of the time the wrong one. The price_unit was then computed using the incorrect bom. Desired behavior after PR is merged: We use the variant_bom_ids of the product when available, if not we fall back to the bom_ids of the product template. Related support ticket: https://www.odoo.com/web#id=2662863&action=3531&model=project.task&view_type=form&cids=1&menu_id=4720 Forward-Port-Of: odoo/odoo#78595 Forward-Port-Of: odoo/odoo#78428
Steps to reproduce the bug: - Go to purchase > Configuration > Vendor Pricelists - Filters > select the “Active” filter Problem: Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active. Opw-2659829 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78515
Original PR description
Steps to reproduce the bug: - Go to purchase > Configuration > Vendor Pricelists - Filters > select the “Active” filter Problem: Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active. Opw-2659829 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78515
**Description of the issue/feature this PR addresses:** Restore proper alignment and spacing of user avatar, after https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431 **Current behavior before PR:**  **Desired behavior after PR is merged:** 
Original PR description
**Description of the issue/feature this PR addresses:** Restore proper alignment and spacing of user avatar, after https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431 **Current behavior before PR:**  **Desired behavior after PR is merged:**  ping @aab-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78663
PURPOSE The purpose of this commit is to fix the random bug of 'TestWebsiteCrm.test_catch_logged_partner_info_tour' on runbot. SPECIFICATIONS Currently, The 'TestWebsiteCrm.test_catch_logged_partner_info_tour' is randomly failing on runbot. The tour is trigger on the contact us page. This tour is linked with selectors. So, This updates the selectors and adds the extra triggers. This is the goal of this commit. LINKS PR #78512 Task-2649723 -- I confirm I have signed th
Original PR description
PURPOSE The purpose of this commit is to fix the random bug of 'TestWebsiteCrm.test_catch_logged_partner_info_tour' on runbot. SPECIFICATIONS Currently, The 'TestWebsiteCrm.test_catch_logged_partner_info_tour' is randomly failing on runbot. The tour is trigger on the contact us page. This tour is linked with selectors. So, This updates the selectors and adds the extra triggers. This is the goal of this commit. LINKS PR #78512 Task-2649723 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78512
Bug === If we open a view in readonly mode, click on a radio widget and if a constraint exists on this field, an error message is raised. (e.g. the enroll field in "website_slides_sale"). Technical ========= This is because in the "Basic controller", in the "_onFieldChanged", we force "force_save" if the view is in readonly mode. This is wanted for widgets that can change the value even in readonly mode (e.g. Priority), but clicking on a Radio widget switch the mode to edit, so this
Original PR description
Bug === If we open a view in readonly mode, click on a radio widget and if a constraint exists on this field, an error message is raised. (e.g. the enroll field in "website_slides_sale"). Technical ========= This is because in the "Basic controller", in the "_onFieldChanged", we force "force_save" if the view is in readonly mode. This is wanted for widgets that can change the value even in readonly mode (e.g. Priority), but clicking on a Radio widget switch the mode to edit, so this is not needed. To fix that, we call `setValue` after switching to the edit mode. So the `setValue` is skipped in `_onInputClick` if we are in readonly mode, and the `setValue` is done in `_quickEdit` instead. Task-2668763 Forward-Port-Of: odoo/odoo#78392
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#78555
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 Forward-Port-Of: odoo/odoo#78555
Currently, DDT use the product_uom_quantity of product for the ddt move which is inaccurate in case of no-backorder change in quantity The fix correctly check if the done quantity is higher than 0 for the delivery and if it is, use it as the delivery quantity (else, no line is added) opw-2663174 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78184
Original PR description
Currently, DDT use the product_uom_quantity of product for the ddt move which is inaccurate in case of no-backorder change in quantity The fix correctly check if the done quantity is higher than 0 for the delivery and if it is, use it as the delivery quantity (else, no line is added) opw-2663174 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78184
In some cases when creating a new ticket, the default product type shown is a "Consumable". It should rather be handled as a "Service". In later versions, a detailed type is created, but the base product type should be set to service too. This commit uses the `product_id` `context` to set the default type to "service". Task-2655226 Forward-Port-Of: odoo/odoo#78519 Forward-Port-Of: odoo/odoo#78046
Original PR description
In some cases when creating a new ticket, the default product type shown is a "Consumable". It should rather be handled as a "Service". In later versions, a detailed type is created, but the base product type should be set to service too. This commit uses the `product_id` `context` to set the default type to "service". Task-2655226 Forward-Port-Of: odoo/odoo#78519 Forward-Port-Of: odoo/odoo#78046
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#78621
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 Forward-Port-Of: odoo/odoo#78621
Before this commit if button text had styles, they would override the color set by customizing the button. Also, colors from classes could not be used. After this commit button text styles are removed when applying custom button colors. Colors are now also applied when selected from classes colors. task-2653874 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 re
Original PR description
Before this commit if button text had styles, they would override the color set by customizing the button. Also, colors from classes could not be used. After this commit button text styles are removed when applying custom button colors. Colors are now also applied when selected from classes colors. task-2653874 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#76936
Go to: - Accounting > Reporting > General Ledger with Mexican or Norwegian localization - Accounting > Reporting > Sales|Purchase VAT Book with Argentinian localization The following error is raised: "TypeError: _get_reports_buttons() takes 1 positional argument but 2 were given" The "options" arg is missing in some override of "_get_reports_buttons" method. Also, "account_tax_fiscal_country_id" field has been renamed to "account_fiscal_country_id". opw-2667517 opw-2669396 Forward
Original PR description
Go to: - Accounting > Reporting > General Ledger with Mexican or Norwegian localization - Accounting > Reporting > Sales|Purchase VAT Book with Argentinian localization The following error is raised: "TypeError: _get_reports_buttons() takes 1 positional argument but 2 were given" The "options" arg is missing in some override of "_get_reports_buttons" method. Also, "account_tax_fiscal_country_id" field has been renamed to "account_fiscal_country_id". opw-2667517 opw-2669396 Forward-Port-Of: odoo/enterprise#21800
Forward-Port-Of: odoo/enterprise#21320
Original PR description
Forward-Port-Of: odoo/enterprise#21320