Saturday, January 27, 2024
15 changes · master
Code cleanup and technical improvements
Spreadsheet pivots now avoid repeatedly reloading the same pivot setup during template and autofill operations. This reduces unnecessary processing and helps keep spreadsheet interactions responsive, especially for larger or more complex pivot tables.
Miscellaneous changes
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go to eShop page of Website X Issue: On the eShop products list page, the price of the product should be "Tax Included"
Original PR description
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go to eShop page of Website X Issue: On the eShop products list page, the price of the product should be "Tax Included" ($115), but it is not. The displayed price is $100. When accessing the product page, the price is correctly displayed with the tax ($115). Cause: When computing the prices, taxes from parent companies are not taken into account. opw-3660156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151223
Steps to reproduce the bug: - Create a product “P1” tracked by SN - Update the quantity with “SN1” and a package “Pack 1” - Create a repair order to repair the product P1: - Select the “SN1” - Try to confirm the repair Problem: A wizard with the following message is triggered: Insufficient Quantity to repair “The product is not available in sufficient quantity in WH/Stock Because when the function “action_validate” is called, we check if there is quant with the same SN but wi
Original PR description
Steps to reproduce the bug:
- Create a product “P1” tracked by SN
- Update the quantity with “SN1” and a package “Pack 1”
- Create a repair order to repair the product P1:
- Select the “SN1”
- Try to confirm the repair
Problem:
A wizard with the following message is triggered:
Insufficient Quantity to repair “The product is not available in sufficient quantity in WH/Stock
Because when the function “action_validate” is called, we check if there is quant with the same SN but with strict=True so, the package should be false to find the quant:
https://github.com/odoo/odoo/blob/61c9921596662a2cbc15a154a91dd2f52c9854fd/addons/mrp_repair/models/mrp_repair.py#L210-L211
https://github.com/odoo/odoo/blob/b3180c841101510081ee8ef9c52d205497efdd4f/addons/stock/models/stock_quant.py#L102
Opw-3648874
Forward-Port-Of: odoo/odoo#151234
Forward-Port-Of: odoo/odoo#149740of check_company=True fields. Suppose two models class A: company_id = fields.M2O() # not required class B: _check_company_auto = True company_id = fields.M2O() # not required a_id = fields.M20(check_company=True) and the following code: a = A.create({'company_id': 1}) b = B.create({'a_id': a.id, 'company_id': False}) The creation of B will fail because of the multi-company checks, which is expected. Nevertheless, since 0d30cc2bc9b9cc2b805d6c2d0a440f
Original PR description
of check_company=True fields. Suppose two models class A: company_id = fields.M2O() # not required class B: _check_company_auto = True company_id = fields.M2O() # not required a_id =…
of check_company=True fields.
Suppose two models
class A:
company_id = fields.M2O() # not required
class B:
_check_company_auto = True
company_id = fields.M2O() # not required
a_id = fields.M20(check_company=True)
and the following code:
a = A.create({'company_id': 1})
b = B.create({'a_id': a.id, 'company_id': False})
The creation of B will fail because of the multi-company checks, which is expected.
Nevertheless, since 0d30cc2bc9b9cc2b805d6c2d0a440f185c648da0, the domain of the field a_id would be:
(company_id and ['|', ('company_id', '=', False), ('company_id', 'in', [company_id])] or []) + ([])
which means that through the interface, if you create a record b following the example above (no company_id on b), the evaluated domain would be empty, allowing to select records of class A, even if they belong to another company. Of course, this would lead to a multi-company error when trying to save the record.
This commit makes sure that the right domain is applied on check_company=True fields, even if the current record has no value in its `company_id` field.
opw-3629374
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#146331Before this commit, the `_search_is_timeoff_task` search method for the `is_timeoff_task` field could return the same task id many times in the right part of the leaf inside the domain returned by the method. This commit makes sure the list of ids in the right part of the leaf in the domain returned by the search method will be each time different task ids. Forward-Port-Of: odoo/odoo#150408
Original PR description
Before this commit, the `_search_is_timeoff_task` search method for the `is_timeoff_task` field could return the same task id many times in the right part of the leaf inside the domain returned by the method. This commit makes sure the list of ids in the right part of the leaf in the domain returned by the search method will be each time different task ids. Forward-Port-Of: odoo/odoo#150408
- Currently, once the SMS code has been created, it's valid forever, which is not very secure. Verification codes should expire after some time and users should have an opportunity to request a new one after some time elapses instead of having to cancel the registration and retry. - We've had several cases where users tried to register while having an active registration somewhere else. In that case, we cannot register them and we have to reach out to the user asking to deregister from the othe
Original PR description
- Currently, once the SMS code has been created, it's valid forever, which is not very secure. Verification codes should expire after some time and users should have an opportunity to request a new one after some time elapses instead of having to cancel the registration and retry. - We've had several cases where users tried to register while having an active registration somewhere else. In that case, we cannot register them and we have to reach out to the user asking to deregister from the other service. It is better to catch that instantly. task-3677877 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151202 Forward-Port-Of: odoo/odoo#149425
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix of manual fields (named x_...) and of base fields (originating from some mixin). Unlink all linked views or object, and try to unlink that model eventually. Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty. After this commit, the deletion works. Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added pa
Original PR description
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix of manual fields (named x_...) and of base fields (originating from some mixin). Unlink all linked views or object, and try to unlink that model eventually. Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty. After this commit, the deletion works. Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added partial support for this and a backport of 7550bcd61e52bc9c3de007d06cf95c91eaec893a which fixed the former PR in 17.0 opw-3558590 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#151290 Forward-Port-Of: odoo/odoo#151020
Pivot functions with the `"__count"` measure always return `"0`", which is supposed to be the format. Mistake introduce with forward-port d63fccd7 Task: 3705106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151370
Original PR description
Pivot functions with the `"__count"` measure always return `"0`", which is supposed to be the format. Mistake introduce with forward-port d63fccd7 Task: 3705106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151370
Problem --------- There is currently no localization for Uganda. Objective --------- Add the base localization for Uganda: - Chart of accounts - Taxes - Fiscal positions - Default settings - Tax reports Solution --------- Create a new localization and set up all basic required information: - tax and tax groups, CoA and fiscal positions are defined in CSVs. Details have been obtained in documents (for details about those documents, refer to the task). - demo data is generated
Original PR description
Problem --------- There is currently no localization for Uganda. Objective --------- Add the base localization for Uganda: - Chart of accounts - Taxes - Fiscal positions - Default settings - Tax reports Solution --------- Create a new localization and set up all basic required information: - tax and tax groups, CoA and fiscal positions are defined in CSVs. Details have been obtained in documents (for details about those documents, refer to the task). - demo data is generated (it uses a random address) - default accounts and value are set up for the company - Profit and loss report and balance sheet use the generic template - Tax report has been made following the template provided by the URA task-3340378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131877
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#150780 Forward-Port-Of: odoo/odoo#139295
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#150780 Forward-Port-Of: odoo/odoo#139295
Forward-Port-Of: odoo/enterprise#54990 Forward-Port-Of: odoo/enterprise#49300
Original PR description
Forward-Port-Of: odoo/enterprise#54990 Forward-Port-Of: odoo/enterprise#49300
Before this, resetting or unlinking a vendor bill would try to launch requests to external tax services. opw-3702163 Forward-Port-Of: odoo/enterprise#55199
Original PR description
Before this, resetting or unlinking a vendor bill would try to launch requests to external tax services. opw-3702163 Forward-Port-Of: odoo/enterprise#55199
Before this method we were trying to use the auto detect on WSFBE and it is not supported on that webservice. Adhoc Helpdesk 68703 Forward-Port-Of: odoo/enterprise#53458
Original PR description
Before this method we were trying to use the auto detect on WSFBE and it is not supported on that webservice. Adhoc Helpdesk 68703 Forward-Port-Of: odoo/enterprise#53458
task-3497444 Forward-Port-Of: odoo/enterprise#47096
Original PR description
task-3497444 Forward-Port-Of: odoo/enterprise#47096
# [FIX] timesheet_grid: avoid extra condition for group expand in grid view Before this commit, when the group expand is triggered in the grid view of timesheets to get the empty lines according to the timesheets recorded in the previous period, the domain to gather the additional lines will make sure the projects still have the timesheets feature enabled and the tasks are always actives. This commit removes those extra conditions because we could assume in one week the project in which we
Original PR description
# [FIX] timesheet_grid: avoid extra condition for group expand in grid view Before this commit, when the group expand is triggered in the grid view of timesheets to get the empty lines according to…
# [FIX] timesheet_grid: avoid extra condition for group expand in grid view
Before this commit, when the group expand is triggered in the grid view of timesheets to get the empty lines according to the timesheets recorded in the previous period, the domain to gather the additional lines will make sure the projects still have the timesheets feature enabled and the tasks are always actives.
This commit removes those extra conditions because we could assume in one week the project in which we previously record a timesheet, still has the timesheets feature enabled. Same idea for the tasks, we could also assume the tasks are still actives. For the reason about removing those extra conditions is because `('task_id.active', '=', True)` leaf will also trigger the `ir.rule` to make sure the user can read the fields in the task, idem for project with `('project_id.allow_timesheets', '=', True)` leaf.
# [FIX] palnning,project_forecast: only compute template_id when it is needed
Before this commit, when the `allocated_hours` is altered in a `planning.slot`,
it will trigger the compute of `template_id` in `planning_slot` to finally do
nothing since the `allocated_hours` is not used inside that compute.
The problem by letting that field in the dependencies is the `compute_role_id`
will be triggered because the template_id potentially changed thanks to its
compute method and so the compute method of `slot_properties` will be triggered
and could raise an access error in the case the `planning.slot` cannot be read.
This commit removes `allocated_hours` field in the dependencies of
`compute_template_id` since it does not seem to have any reason to trigger
that compute when the allocated_hours is changed on a `planning.slot`.
Forward-Port-Of: odoo/enterprise#54830