Saturday, April 6, 2024
27 changes · master
Miscellaneous changes
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159993 Forward-Port-Of: odoo/odoo#157026
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159993 Forward-Port-Of: odoo/odoo#157026
-Before this commit the url is like /blog/1/feed then it will become a redirect 301 url to /blog/travel-1/feed which is not good for SEO. Therefore we change to slug(blog) to ensure no redirect occur 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#160503 Forward-Port-Of: odoo/odoo#160438
Original PR description
-Before this commit the url is like /blog/1/feed then it will become a redirect 301 url to /blog/travel-1/feed which is not good for SEO. Therefore we change to slug(blog) to ensure no redirect occur 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#160503 Forward-Port-Of: odoo/odoo#160438
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single
Original PR description
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 Fixes #155162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160259 Forward-Port-Of: odoo/odoo#159122
…arch view Description of the issue/feature this PR addresses: The closed ("paid") filter in the search view does not consider the reversed state and is technically closed. Current behavior before PR: Currently, when you select the "paid" and "unpaid" filters on the invoices list, it does not provide a complete view of all the universe of invoices as the reversed status is not reflected within its domain. Desired behavior after PR is merged: I propose that the closed ("paid") filter
Original PR description
…arch view
Description of the issue/feature this PR addresses:
The closed ("paid") filter in the search view does not consider the reversed state and is technically closed.
Current behavior before PR:
Currently, when you select the "paid" and "unpaid" filters on the invoices list, it does not provide a complete view of all the universe of invoices as the reversed status is not reflected within its domain.
Desired behavior after PR is merged:
I propose that the closed ("paid") filter takes into account the reversed state. Consequently, upon selecting both "paid" and "unpaid" filters, it should present a complete universe of invoices.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154204Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing the header tags. - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for
Original PR description
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing…
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing the header tags. - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for fold/unfold - Align questions to the left to be on the same level as the sections - Add an horizontal scroll to the matrix and simple/multiple choices tables when the screen is not wide enough to display all the data - Reduce vertical spacing between elements to gain space - Reduce simple/multiple choices tables line height - Reduce survey title, section title and KPIs font size - Display the "Correct", "Partial", "Responded" and "Skipped" badges on a single line and set a rounded border around. - Removing the "Result Overview" title - Removing survey description, section description and question description Task-3707687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160524 Forward-Port-Of: odoo/odoo#152263
In this commit, we make the error message more explicit to avoid to get the same error message for differents tours in runbot. e.g. - Error: Tour ${tour.name} failed at step ${describeStep(step)}. - Error: Element has been found. The error seems to be in run() To reach that, we just concatenate the two error messages in only one. e.g. - Error: Tour ${tour.name} failed at step ${describeStep(step)}. Element has been found. The error seems to be in run() Forward-Port-Of: odoo/odoo#160539
Original PR description
In this commit, we make the error message more explicit to avoid to get the same error message for differents tours in runbot. e.g.
- Error: Tour ${tour.name} failed at step ${describeStep(step)}.
- Error: Element has been found. The error seems to be in run() To reach that, we just concatenate the two error messages in only one. e.g.
- Error: Tour ${tour.name} failed at step ${describeStep(step)}. Element has been found. The error seems to be in run()
Forward-Port-Of: odoo/odoo#160539At the moment, the partner being used to get the information for the efaktur module is the partner set on the invoice. This is wrong, since if the partner set on the invoice is a child record of a company partner you cannot set most of these fields. To fix this issue, we will update in order to fetch the efaktur related fields from the commercial partner instead. (vat, along with all efaktur specific information used in the process) --- I confirm I have signed the CLA and read the PR g
Original PR description
At the moment, the partner being used to get the information for the efaktur module is the partner set on the invoice. This is wrong, since if the partner set on the invoice is a child record of a company partner you cannot set most of these fields. To fix this issue, we will update in order to fetch the efaktur related fields from the commercial partner instead. (vat, along with all efaktur specific information used in the process) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160283 Forward-Port-Of: odoo/odoo#160108
**Steps to reproduce:** 1- Create a purchase order and assign a project to its Analytic distribution 2- Go to the assigned project's 'Project Updates' 3- Click on Purchase order smart button **Current behavior before PR:** When trying to view the purchase orders linked to a project you will either get a message saying this ID doesn't exist or you will get an empty list view. This is happening because we are fetching the purchase order line ids and passing those ids to the view not the
Original PR description
**Steps to reproduce:** 1- Create a purchase order and assign a project to its Analytic distribution 2- Go to the assigned project's 'Project Updates' 3- Click on Purchase order smart button **Current behavior before PR:** When trying to view the purchase orders linked to a project you will either get a message saying this ID doesn't exist or you will get an empty list view. This is happening because we are fetching the purchase order line ids and passing those ids to the view not the ids for the purchase order itself https://github.com/odoo/odoo/blob/saas-17.1/addons/project_purchase/models/project_project.py#L31:L33 **Desired behavior after PR is merged:** We are now passing the ids of the purchase order to the view. opw-3794848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159345
Since e210809e, the concept of empty cell was altered. Before the aforementioned commit, an evaluated cell with the type "empty" could be empty or have a formula whose result is an empty string. Now, only really empty cells (no content) have the evaluated type "empty". Empty string result is now mapped to the "text" type. The menu actions to drilldown records were relying on the previous logic and were not properly adapted. Task: 3827310 Description of the issue/feature this PR ad
Original PR description
Since e210809e, the concept of empty cell was altered. Before the aforementioned commit, an evaluated cell with the type "empty" could be empty or have a formula whose result is an empty string. Now, only really empty cells (no content) have the evaluated type "empty". Empty string result is now mapped to the "text" type. The menu actions to drilldown records were relying on the previous logic and were not properly adapted. Task: 3827310 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#160152
The aim of this commit is to prevent the statistical error detection to interupt automated flow. From now on, the error detection wizard on `action_post` will only be triggered for manually created invoice. Context: Payments made through our website wouldn't be reconcile with their invoice because the flow supposed to post the invoice silently failed due to the `validate.account.move` wizard being returned by `action_post`. Before this commit: To be able to pass the error detection te
Original PR description
The aim of this commit is to prevent the statistical error detection to interupt automated flow. From now on, the error detection wizard on `action_post` will only be triggered for manually created invoice. Context: Payments made through our website wouldn't be reconcile with their invoice because the flow supposed to post the invoice silently failed due to the `validate.account.move` wizard being returned by `action_post`. Before this commit: To be able to pass the error detection test with an automated flow, you needed to setup a context key. That meant setting the context key anywhere an automated action could take place. After this commit: The automated detection error wizard `validate.account.move` will only be brought up through the `action_post` where the key is explicitely set. opw-3830725 Forward-Port-Of: odoo/odoo#160384
Currently some VAT examples that contain other terms than only the number are always displayed in English. This commit makes sure they can be translated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160520 Forward-Port-Of: odoo/odoo#158629
Original PR description
Currently some VAT examples that contain other terms than only the number are always displayed in English. This commit makes sure they can be translated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160520 Forward-Port-Of: odoo/odoo#158629
- Create a Partner who is a valid Peppol participant - Clear their UBL format - they are still displayed as valid (Bug 1) - Create an invoice for that partner and confirm it. The Peppol state changes to 'ready' - Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant - Reset the invoice to draft, confirm again: the peppol move state is still `ready` (Bug 2) 1. Do not set a participant as valid if a peppol-incompatible edi format has been selec
Original PR description
- Create a Partner who is a valid Peppol participant - Clear their UBL format - they are still displayed as valid (Bug 1) - Create an invoice for that partner and confirm it. The Peppol state changes to 'ready' - Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant - Reset the invoice to draft, confirm again: the peppol move state is still `ready` (Bug 2) 1. Do not set a participant as valid if a peppol-incompatible edi format has been selected 2. Only save Peppol move state if it's processing/done already. Otherwise, let users clear it by resetting to draft. (until we implement giving them control over this field) opw-3784945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160692 Forward-Port-Of: odoo/odoo#159852
Steps: - Install project app. - Share a project which contains a task and sub-task and project should have allow milestone - Go to task form in project sharing. - Go to milestone field of sub-task page. Issue: - Milestone field has can create and can open options enable and because of that portal user able to create edit or open milestone and which leads to tracebacks Cause: - There was no options added to prevent those attribute from that field for project sharing views. Fix: -
Original PR description
Steps: - Install project app. - Share a project which contains a task and sub-task and project should have allow milestone - Go to task form in project sharing. - Go to milestone field of sub-task page. Issue: - Milestone field has can create and can open options enable and because of that portal user able to create edit or open milestone and which leads to tracebacks Cause: - There was no options added to prevent those attribute from that field for project sharing views. Fix: - Added option to prevent those operation for project sharing view. Note: Add this options in blockby page in FW port. task-3764782 Forward-Port-Of: odoo/odoo#160514 Forward-Port-Of: odoo/odoo#155358
Before this commit, the default value definition of a Record.attr() was saved once and given to all records of the given model at record creation. This meant that lists were shared between records, which is definitely an undesireable side-effect of the implementation. This commit fixes the issue by instead getting default value from usual lifecyle as a class instance. Forward-Port-Of: odoo/odoo#160702
Original PR description
Before this commit, the default value definition of a Record.attr() was saved once and given to all records of the given model at record creation. This meant that lists were shared between records, which is definitely an undesireable side-effect of the implementation. This commit fixes the issue by instead getting default value from usual lifecyle as a class instance. Forward-Port-Of: odoo/odoo#160702
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's `DOMParser.parseFromString`, which creates several Text nodes if the text would exceed 65536 bytes. Then, only the textContent of the second Text node is passed to `JSON.parse()`, which fails because it is not valid JSON. See [this StackOverflow comment](https://stackoverflow.com/questions/6
Original PR description
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's…
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's `DOMParser.parseFromString`, which creates several Text nodes if the text would exceed 65536 bytes. Then, only the textContent of the second Text node is passed to `JSON.parse()`, which fails because it is not valid JSON. See [this StackOverflow comment](https://stackoverflow.com/questions/67738121/in-what-cases-do-browsers-create-multiple-adjacent-text-nodes/67774415#67774415) and [the WebKit code](https://github.com/WebKit/WebKit/blob/68ae0fde5f959e056fbd6700f1ca7fa652cd1ffa/Source/WebCore/html/parser/HTMLConstructionSite.cpp#L584-L592) ### Steps to reproduce This example works only in 17.1 and master due to the larger files now generated by the Romanian SAF-T export. However, you can reproduce it in any version by raising an InternalServerError with a response content larger than 65536 bytes in any controller called by `download()`. 1. Install l10n_ro_saft on a 17.1 database 2. Switch to 'RO Company' 3. Go to partner 'Azure Interior' and remove the address details (this will make the report generation return an error containing the report content) 4. Go to Accounting -> Reports -> General Ledger 5. Click on the arrow next to 'PDF' and click on 'SAF-T'. taskid: 3790302 Forward-Port-Of: odoo/odoo#160577 Forward-Port-Of: odoo/odoo#156672
Entreprise PR: https://github.com/odoo/enterprise/pull/59243 Forward-Port-Of: odoo/odoo#158823
Original PR description
Entreprise PR: https://github.com/odoo/enterprise/pull/59243 Forward-Port-Of: odoo/odoo#158823
Before this commit, when a churned contract was cancelled, the subscription_state was not reset. The resulting filter on SO would be confusing: Group by subscription_state > state After this commit, the churned order subscription-state is reset to draft or renewal quotation when canceled. This allow to reset the canceled order to quotation and to be able to restart the flow if necessary. Forward-Port-Of: odoo/enterprise#59960
Original PR description
Before this commit, when a churned contract was cancelled, the subscription_state was not reset. The resulting filter on SO would be confusing: Group by subscription_state > state After this commit, the churned order subscription-state is reset to draft or renewal quotation when canceled. This allow to reset the canceled order to quotation and to be able to restart the flow if necessary. Forward-Port-Of: odoo/enterprise#59960
Community PR: https://github.com/odoo/odoo/pull/158823 Forward-Port-Of: odoo/enterprise#59243
Original PR description
Community PR: https://github.com/odoo/odoo/pull/158823 Forward-Port-Of: odoo/enterprise#59243
[FIX] project: smart scheduling unasigned tasks Steps to reproduce: - Go to project/gantt view. - select a slot from the unasigned row. - select unasigned tasks and assigned tasks. - Auto plan => The smart scheduling is not applied correctly for assigned tasks. Fix: When there is no user_ids in vals (i.e. when we clicked on the 'unasigned' row), we have to group the tasks by user to compute the smart scheduling correctly. taskid:3839483 Forward-Port-Of: odoo/
Original PR description
[FIX] project: smart scheduling unasigned tasks
Steps to reproduce:
- Go to project/gantt view.
- select a slot from the unasigned row.
- select unasigned tasks and assigned tasks.
- Auto plan
=> The smart scheduling is not applied correctly for assigned tasks.
Fix: When there is no user_ids in vals (i.e. when we clicked on the
'unasigned' row), we have to group the tasks by user to compute the
smart scheduling correctly.
taskid:3839483
Forward-Port-Of: odoo/enterprise#59922`user_has_groups` has been removed in saas-17.2 (https://github.com/odoo/odoo/pull/151597) but a fw port (https://github.com/odoo/enterprise/pull/59797) didn't take that into account Forward-Port-Of: odoo/enterprise#60213
Original PR description
`user_has_groups` has been removed in saas-17.2 (https://github.com/odoo/odoo/pull/151597) but a fw port (https://github.com/odoo/enterprise/pull/59797) didn't take that into account Forward-Port-Of: odoo/enterprise#60213
**Steps to reproduce:** 1- Navigate to Inventory > Configuration > Warehouses and select the warehouse 2- Click on the Routes smart button and filter by archived routes 3- Unarchive the Replenish on Order (MTO) route 4- Navigate to Sales > Products > Products and create a new product 5- Make the product a Recurring product that has the product type set to storable and the invoicing policy set to ordered quantities 6- Navigate to the Inventory tab and enable the Replenish on Order (MT
Original PR description
**Steps to reproduce:** 1- Navigate to Inventory > Configuration > Warehouses and select the warehouse 2- Click on the Routes smart button and filter by archived routes 3- Unarchive the Replenish on…
**Steps to reproduce:** 1- Navigate to Inventory > Configuration > Warehouses and select the warehouse 2- Click on the Routes smart button and filter by archived routes 3- Unarchive the Replenish on Order (MTO) route 4- Navigate to Sales > Products > Products and create a new product 5- Make the product a Recurring product that has the product type set to storable and the invoicing policy set to ordered quantities 6- Navigate to the Inventory tab and enable the Replenish on Order (MTO) and Manufacture Routes 7- Navigate to Sales and create a new quote and confirm it with the newly created product 8- Click on Create Invoice and then Create Draft Invoice 9- Click on Confirm **Current behavior before PR:** This is happening because while creating the draft invoice we pass the default move type for the invoice in the context and because the attribute 'move_type' has the same name in 'account.move' and 'procurement.group' so when getting the default value to create the procurement group it gets the value in the context which is for the account move so this value is incorrect for the move_type in procurement group **Desired behavior after PR is merged:** We clean the context that was stored for creating the invoice before posting it as this context will not be used anymore opw-3718420 Forward-Port-Of: odoo/enterprise#60118 Forward-Port-Of: odoo/enterprise#59164
…the SAT - Create an invoice in prod PAC environment - Sign it - Cancel it Even if the PAC approved the cancellation, the SAT could reject it. This is because, in some cases, the partner could reject the cancellation. opw-3745401 Forward-Port-Of: odoo/enterprise#59914 Forward-Port-Of: odoo/enterprise#58657
Original PR description
…the SAT - Create an invoice in prod PAC environment - Sign it - Cancel it Even if the PAC approved the cancellation, the SAT could reject it. This is because, in some cases, the partner could reject the cancellation. opw-3745401 Forward-Port-Of: odoo/enterprise#59914 Forward-Port-Of: odoo/enterprise#58657
When switching from `appointment_resource_ids` to `resource_ids` We forgot to update the associated compute methods so that they may be triggered from the relevant views. task-3813567 Forward-Port-Of: odoo/enterprise#60094
Original PR description
When switching from `appointment_resource_ids` to `resource_ids` We forgot to update the associated compute methods so that they may be triggered from the relevant views. task-3813567 Forward-Port-Of: odoo/enterprise#60094
Since https://github.com/odoo/odoo/commoit/e210809e, the concept of empty cell was altered. Before the aforementioned commit, an evaluated cell with the type "empty" could be empty or have a formula whose result is an empty string. Now, only really empty cells (no content) have the evaluated type "empty". Empty string result is now mapped to the "text" type. The menu actions to drilldown records were relying on the previous logic and were not properly adapted. Task: 3827310 Forward-
Original PR description
Since https://github.com/odoo/odoo/commoit/e210809e, the concept of empty cell was altered. Before the aforementioned commit, an evaluated cell with the type "empty" could be empty or have a formula whose result is an empty string. Now, only really empty cells (no content) have the evaluated type "empty". Empty string result is now mapped to the "text" type. The menu actions to drilldown records were relying on the previous logic and were not properly adapted. Task: 3827310 Forward-Port-Of: odoo/enterprise#59912
This traceback will arise when the user removes the attendees while creating the new "Staff Booking". Steps to reproduce: - Install ``appointments`` - Open appointments -> Dental care - Go to new -> create appointment -> remove Attendees -> Save&Close Traceback : ```TypeError: 'bool' object is not subscriptable File "odoo/http.py", line 2252, in __call__ response = request._serve_db() File "odoo/http.py", line 1828, in _serve_db return self._transactioning(_serve_ir_
Original PR description
This traceback will arise when the user removes the attendees while creating the new "Staff Booking". Steps to reproduce: - Install ``appointments`` - Open appointments -> Dental care - Go to new ->…
This traceback will arise when the user removes the attendees while creating the new "Staff Booking".
Steps to reproduce:
- Install ``appointments``
- Open appointments -> Dental care
- Go to new -> create appointment -> remove Attendees -> Save&Close
Traceback :
```TypeError: 'bool' object is not subscriptable
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/appointment/models/calendar_event.py", line 392, in get_gantt_data
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
File "home/odoo/src/enterprise/saas-17.1/appointment/models/calendar_event.py", line 392, in <listcomp>
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
```
This commit will check for the presence of partner_ids. If they are present, it will schedule the appointment; otherwise, it will not.
sentry-4934421570
Forward-Port-Of: odoo/enterprise#60084
Forward-Port-Of: odoo/enterprise#59117Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on the partner ledger. If the number of returned `res.partner` records exceed a certain number, there is an overutilzation of memory when getting fields id, name and trust in method `_get_report_line_partners` leading to a MemoryError when loading the partner ledger report. Solution --> Replace
Original PR description
Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on…
Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on the partner ledger. If the number of returned `res.partner` records exceed a certain number, there is an overutilzation of memory when getting fields id, name and trust in method `_get_report_line_partners` leading to a MemoryError when loading the partner ledger report. Solution --> Replace the `search` call with a `search_fetch` call and store the specific field values in cache. This prevents the fetch of the field values. Flamegraph before  After  Peak memory utilization reduced from 1.9GB to 1.3GB for about 150k `res.partner` records opw-3785731 Forward-Port-Of: odoo/enterprise#59948
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59826 Forward-Port-Of: odoo/enterprise#58332
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59826 Forward-Port-Of: odoo/enterprise#58332