Thursday, February 20, 2020
43 changes · master
New functionality added to Odoo
A new automated test verifies that the web interface reloads when a company is created or updated. This helps ensure users always see the correct company context after administrative changes, reducing the risk of stale information in the system.
Original PR description
The purpose of this task is to when a company is created, the web-client is refresh Task-ID: 2188789
Enhancements to existing features
This update renames several internal accounting fields to make their purpose clearer and reduce confusion for future maintenance. It does not change the underlying reporting data structure, so business behavior and existing reports should remain consistent.
Original PR description
Rename field 'type' to 'move_type' in a model account.move Rename field 'tag_ids' to 'tax_tag_ids' in module account.move.line -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update removes unused selection settings from related fields across several Odoo apps and adds a warning to help prevent the issue from returning. It improves code quality and helps avoid confusing or incorrect field labels without changing core business workflows.
Original PR description
Code cleanup and technical improvements
This update removes unnecessary internal processing when survey pages are prepared for display. It simplifies the survey code path without changing what users see, helping keep the system easier to maintain.
Original PR description
This commit cleans some useless .decode('utf-8') calls when we return rendered
templates results in the survey controllers.
The http module is capable of handling that type of results and the calls were
not necessary / added complexity.
Task '2187328'
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-prMiscellaneous changes
Line return will add a space between icon & text, as it is done for the one just above and the one below. Forward-Port-Of: odoo/odoo#45862
Original PR description
Line return will add a space between icon & text, as it is done for the one just above and the one below. Forward-Port-Of: odoo/odoo#45862
Recruitment applications now keep a history of changes to important fields such as job, department, company, salary expectations, proposed salary, and availability. This improves visibility for HR teams by making it easier to understand how an applicant record evolved over time.
Original PR description
Track following fields:
- job_id
- department_id
- company_id
- salary_proposed
- salary_expected
- availability
TaskID: 2195796
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-prThis update clarifies company-related labels in the Time Off module for multi-company setups. It reduces confusion by distinguishing the company grouping mode from the employee's actual company, without changing the underlying business behavior.
Original PR description
Task:https://www.odoo.com/web#id=2168320&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.2b35e4880768ecb612ff9358ad6ad378 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
When a future driver is applied to a fleet vehicle, the previous driver's history record now receives an end date matching the new driver's start date. This keeps vehicle assignment history complete and avoids unclear or overlapping driver records.
Original PR description
Purpose ======= If you set a future driver and click on "apply change", a new assignation log is automatically created for the new driver. But the end date of the former assignation isn't populate. Specifications ============== Set the date "end date" for the former driver with the "start date" of the new driver. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now warns developers when selection settings are defined on related fields where they have no effect. Several existing field definitions were corrected, reducing hidden configuration mistakes across business apps without changing day-to-day user workflows.
Original PR description
When a field is related, defining a selection or selection_add will have no effect and the paramater is ignored. Log a warning and fix all fields badly definied Closes odoo/odoo#45716
Internal compatibility warnings are now shown only when debug mode is enabled. This reduces unnecessary noise during normal use while keeping diagnostic information available for troubleshooting.
Original PR description
Before this commit ComponentAdapter warned on every update and render. This can make a lot of noises when we use some adpaters. After this commit ComponentAdapter will warn only in debug mode.
This update gives Odoo's web interface more flexibility in how it reacts to user actions such as clicks. It helps developers fine-tune interaction behavior without changing the user experience directly.
Original PR description
Helpful if for example one wants to trigger the capture phase of the event
processing.
e.g.
`useListener('click', 'button', this.onClick, { capture: true })`
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPlanning users no longer see Edit or Delete buttons in calendar popovers. This helps keep schedule changes limited to the appropriate roles and reduces the risk of accidental updates.
Original PR description
This commit aims at removing the buttons "Edit" / "Delete" in the calendar popover for Planning Users. TaskID: 2181530
This update standardizes internal accounting field names across invoices, assets, follow-ups, bank reconciliation, inter-company rules, intrastat, and invoice extraction. It improves consistency and maintainability for future accounting changes without changing report data structures or expected business workflows.
Original PR description
Rename field 'type' to 'move_type' in a model account.move Rename field 'tag_ids' to 'tax_tag_ids' in module account.move.line
**Description of the issue/feature this PR addresses:** Some selection fields that are related have an explicit selection attribute that is not being used. Sometimes, those are just strings that don't have the "string=" part. This PR adds a logged warning to avoid this issue. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes error handling behave more consistently between standard web requests and JSON-based requests. It allows custom modules to handle JSON request errors in the same centralized way, reducing unexpected differences without materially changing normal behavior.
Original PR description
The idea is to make the dispatching and error-handling consistent for JsonRequest and HTTPRequest.
In 8809c77 we introduced a way for request-specific error-handling, but JsonRequest.dispatch() was still catching all errors internally, instead of letting them bubble up to ir_http._handle_exception()
By removing the internal try/except in JsonRequest.dispatch(), we do not
change the behavior much as there are only a couple of "ifs" in ir_http._handle_exception() before returning to the request-specific handle_exception. However we give the opportunity to modules to customize exception handling even for JsonRPC, the same way it is possible for HTTP requests.
Here is a simple pseudo code of the flow
```python
ir_http.dispatch():
try:
request.dispatch()
catch Exception as e:
ir_http._handle_exception(e)
```
```python
ir_http.handle_exception(e):
request._handle_exception(e)
```This update removes field options that were being ignored by the system because they do not apply to related fields. It helps keep payroll and timesheet configuration code cleaner without changing how users work with the system.
Original PR description
When a field is related, defining a selection or selection_add will have no effect and the attribute will be ignored. Enterprise part of odoo/odoo#45832 cc @MiquelRForgeFlow
Since Chrome version 80, the V8 javascript engine is using an new pointer compression feature [1]. This features tries to reserve more the 4GiB of memory. As a consequence, during HttpCase tests, odoo tries to launch chrome headless in a subprocess but fails because of the memory-limit-soft. With this commit, the Chrome browser is spawned in a forked process that removes the memory limit. Also: * a new Chrome CLI switch is used to prevent crash reports to be sent to google *
Original PR description
Since Chrome version 80, the V8 javascript engine is using an new pointer compression feature [1]. This features tries to reserve more the 4GiB of memory. As a consequence, during HttpCase tests, odoo tries to launch chrome headless in a subprocess but fails because of the memory-limit-soft. With this commit, the Chrome browser is spawned in a forked process that removes the memory limit. Also: * a new Chrome CLI switch is used to prevent crash reports to be sent to google * a bug that only occurs during Chrome crash is fixed [2] [1] https://v8.dev/blog/v8-release-80 [2] None type object does not have a send method Forward-Port-Of: odoo/odoo#45799 Forward-Port-Of: odoo/odoo#45347
Before this fix, if the user has no PoS access rights, he cannot delete a contact due to a check done on open PoS sessions. Description of the issue/feature this PR addresses: opw-2199860 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#45795
Original PR description
Before this fix, if the user has no PoS access rights, he cannot delete a contact due to a check done on open PoS sessions. Description of the issue/feature this PR addresses: opw-2199860 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#45795
Before this commit, the popup activity in kanban was rendered using the position of the button. So the left popup was nearly in the center of the screen but the width is too large to be contained on the screen. After this commit, in mobile, the popup activity in kanban will be placed on the left of the button to avoid to go outside of the viewport. S
Original PR description
Before this commit, the popup activity in kanban was rendered using the position of the button. So the left popup was nearly in the center of the screen but the width is too large to be contained on the screen. After this commit, in mobile, the popup activity in kanban will be placed on the left of the button to avoid to go outside of the viewport. Steps to reproduce: * Go to sale app (in mobile) * Click on the activity button of a kanban card (clock icon) BUG Task ID: 2198429 Forward-Port-Of: odoo/odoo#45802
The computed field 'session_show_ranking' was only computed based on the fact that the survey had a scoring mechanism. It's not very accurate since we also need a question that saves as the attendee nickname to be able to display a relevant ranking chart. This commit fixes the compute method by adding the necessary condition. Task ID 2188482 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I conf
Original PR description
The computed field 'session_show_ranking' was only computed based on the fact that the survey had a scoring mechanism. It's not very accurate since we also need a question that saves as the attendee nickname to be able to display a relevant ranking chart. This commit fixes the compute method by adding the necessary condition. Task ID 2188482 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#45277
`require_signature`and `require_payment` were visible in debug-mode only for seemingly no reasons, making our sales team having difficulties with our customers payments. Issue introduced by TaskID #2033229. Forward-Port-Of: odoo/odoo#45816
Original PR description
`require_signature`and `require_payment` were visible in debug-mode only for seemingly no reasons, making our sales team having difficulties with our customers payments. Issue introduced by TaskID #2033229. Forward-Port-Of: odoo/odoo#45816
Previously, When we edit a link in website page will be fetched to find the anchor that will result in lots of useless requests. In this commit We have added a delay of 1000 ms to avoid the above issue. PR #45485 task - 2187754 Forward-Port-Of: odoo/odoo#45485
Original PR description
Previously, When we edit a link in website page will be fetched to find the anchor that will result in lots of useless requests. In this commit We have added a delay of 1000 ms to avoid the above issue. PR #45485 task - 2187754 Forward-Port-Of: odoo/odoo#45485
Description of the issue/feature this PR addresses: fix parsing failure for Japanese tax report Current behavior before PR: fail to parse Japanese tax report Desired behavior after PR is merged: success to parse Japanese tax report -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45760
Original PR description
Description of the issue/feature this PR addresses: fix parsing failure for Japanese tax report Current behavior before PR: fail to parse Japanese tax report Desired behavior after PR is merged: success to parse Japanese tax report -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45760
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#45793
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#45793
The compute_all JS-side hasn't be updated since recent changes in the tax computation. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45733
Original PR description
The compute_all JS-side hasn't be updated since recent changes in the tax computation. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45733
- create a SO with a section; - create an invoice from the SO. Before this commit, an SQL constraint was raised : 'Forbidden unit price, account and quantity on non-accountable invoice line'. This error occurs, because the default_get function adds a default account_id to all the lines (including section lines) if a journal_id is passed in the context. The journal_id is added in the context since : 0335311 Now, the default_get function only adds a default account_id if the line is no
Original PR description
- create a SO with a section; - create an invoice from the SO. Before this commit, an SQL constraint was raised : 'Forbidden unit price, account and quantity on non-accountable invoice line'. This error occurs, because the default_get function adds a default account_id to all the lines (including section lines) if a journal_id is passed in the context. The journal_id is added in the context since : 0335311 Now, the default_get function only adds a default account_id if the line is not a section line or a note line. This avoids the SQL constraint to be raised, and the invoice is correctly created. opw-2199356 opw-2199017 opw-2198781 opw-2198650 Forward-Port-Of: odoo/odoo#45774 Forward-Port-Of: odoo/odoo#45684
In case of MTO+Manufacture, a sale order have a count of manufacturing order created from it : 1. create SO with MFG+MTO product with quantity of 5. 2. confirm it. MO will be created for 5 Nos. 3. increase it to 7 . another MO created for 2 Nos. 4. there are 2 MO created based on 1 SO. It was due that new stock move was merge, and the 'created_production_id' info was lost during the merge (keep only the original one). To fix, avoid merging stock move with distinct 'created_productio
Original PR description
In case of MTO+Manufacture, a sale order have a count of manufacturing order created from it : 1. create SO with MFG+MTO product with quantity of 5. 2. confirm it. MO will be created for 5 Nos. 3. increase it to 7 . another MO created for 2 Nos. 4. there are 2 MO created based on 1 SO. It was due that new stock move was merge, and the 'created_production_id' info was lost during the merge (keep only the original one). To fix, avoid merging stock move with distinct 'created_production_id' (done by override '_prepare_merge_moves_distinct_fields' and '_prepare_merge_move_sort_method' methods ). task-2199568 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#45722
Fix bad forward-port of https://github.com/odoo/odoo/commit/e09798098679fa6719cfd9f8e1cac69731387bd9 made in https://github.com/odoo/odoo/commit/51d49517a8b5af2d1c85d9c620e45a0941cdc6b4 Original commit message was: [FIX] account: fix bank account requirement on account.payment form When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the u
Original PR description
Fix bad forward-port of https://github.com/odoo/odoo/commit/e09798098679fa6719cfd9f8e1cac69731387bd9 made in https://github.com/odoo/odoo/commit/51d49517a8b5af2d1c85d9c620e45a0941cdc6b4 Original commit message was: [FIX] account: fix bank account requirement on account.payment form When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the user needs to be able to correct the payments by cancelling them. It was not possible. Forward-Port-Of: odoo/odoo#45676
The product demo file marks a lot of product as 'invoice on delivery' (the default is invoice on order), but the invoice status and amount to invoice on order lines is _not_ recomputed when the product's invoice policy changes (this is a conscious choice, as it would trigger recomputation on past orders). This means that the demo for products must be loaded _before_ the orders demo, otherwise the computation for what is to invoice or not will seem to make no sense on a demo db (even tho
Original PR description
The product demo file marks a lot of product as 'invoice on delivery' (the default is invoice on order), but the invoice status and amount to invoice on order lines is _not_ recomputed when the product's invoice policy changes (this is a conscious choice, as it would trigger recomputation on past orders). This means that the demo for products must be loaded _before_ the orders demo, otherwise the computation for what is to invoice or not will seem to make no sense on a demo db (even though the computation is in fact correct): a lot of orders where marked as 'to invoice' while the products where not delivered; invoice those and the system will again mark them as 'to invoice' and will immediately want to generate a refund... Forward-Port-Of: odoo/odoo#45753
### Issue - Install Sale and/or Purchase - Create new order - Debugger > Set Defaults - Set default value for payment terms - Quit and re-create Default value is not filled ### Cause The default value is set but it's overridden by a onchange ### Solution Remove the override who puts the value to False **OPW-2197940** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45727
Original PR description
### Issue - Install Sale and/or Purchase - Create new order - Debugger > Set Defaults - Set default value for payment terms - Quit and re-create Default value is not filled ### Cause The default value is set but it's overridden by a onchange ### Solution Remove the override who puts the value to False **OPW-2197940** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45727
The button which allows to indicate that an answer is correct is supposed to turn green once the answer is validated. This was not the case anymore since the link button was missing its href. Indeed BS4 forces those links to "color: inherit". Forward-Port-Of: odoo/odoo#45726 Forward-Port-Of: odoo/odoo#45482
Original PR description
The button which allows to indicate that an answer is correct is supposed to turn green once the answer is validated. This was not the case anymore since the link button was missing its href. Indeed BS4 forces those links to "color: inherit". Forward-Port-Of: odoo/odoo#45726 Forward-Port-Of: odoo/odoo#45482
This fixes the following issue. Set the field `arch` on a view; this automatically writes on `arch_db`, which is a translated field. If some translations are discarded, a call to `unlink()` invalidates the whole cache. And then things go wrong: when `arch_db` is validated, the field `arch` is missing from cache, and the ORM sets it to `None` because the field is still protected by the initial write! Fix the issue by avoiding the call to `unlink()`, and do it in SQL instead. Forward-
Original PR description
This fixes the following issue. Set the field `arch` on a view; this automatically writes on `arch_db`, which is a translated field. If some translations are discarded, a call to `unlink()` invalidates the whole cache. And then things go wrong: when `arch_db` is validated, the field `arch` is missing from cache, and the ORM sets it to `None` because the field is still protected by the initial write! Fix the issue by avoiding the call to `unlink()`, and do it in SQL instead. Forward-Port-Of: odoo/odoo#45715 Forward-Port-Of: odoo/odoo#45705
In the previous snippet cleanup, a lot of superfluous row > col were removed in favour of having the bare content directly in the section, this streamlines the interface and prevents having many useless UI elements. At the same time however, there are some snippet on which you might want columns so that you can pull the content off-center and give the block a background color independently of its containing section (namely: the cover, title and text-block snippets) this commit adds a
Original PR description
In the previous snippet cleanup, a lot of superfluous row > col were removed in favour of having the bare content directly in the section, this streamlines the interface and prevents having many useless UI elements. At the same time however, there are some snippet on which you might want columns so that you can pull the content off-center and give the block a background color independently of its containing section (namely: the cover, title and text-block snippets) this commit adds an option to add columns on those snippets (and remove those columns completely if they're no longer wanted) task-2120360 Forward-Port-Of: odoo/odoo#44709
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#45057
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#45057
Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider two production locations L1 in C1 and L2 in C2 - Let's consider that the company of SUPERUSER is C1 - Add the field Production location in the form view of mrp.production - Log in C2 - Create a product P with a BOM in C2 with L2 as production location - Create a MO for P Bug: The production location of P was L1 instead L2 PS: related_sudo is set to True by default. opw:2196707 Forward-Port
Original PR description
Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider two production locations L1 in C1 and L2 in C2 - Let's consider that the company of SUPERUSER is C1 - Add the field Production location in the form view of mrp.production - Log in C2 - Create a product P with a BOM in C2 with L2 as production location - Create a MO for P Bug: The production location of P was L1 instead L2 PS: related_sudo is set to True by default. opw:2196707 Forward-Port-Of: odoo/odoo#45481 Forward-Port-Of: odoo/odoo#45307
For multi-company setup, it is annoying to require the language_code if the employee is not in Belgium and does not speak French, Dutch or German. As this field is quite specific for Belgium, make it required only if the company of the employee is located in Belgium. Forward-Port-Of: odoo/enterprise#8606 Forward-Port-Of: odoo/enterprise#8532
Original PR description
For multi-company setup, it is annoying to require the language_code if the employee is not in Belgium and does not speak French, Dutch or German. As this field is quite specific for Belgium, make it required only if the company of the employee is located in Belgium. Forward-Port-Of: odoo/enterprise#8606 Forward-Port-Of: odoo/enterprise#8532
Don't send next activity mail as the sign request mail is quite sufficient. Task 1944014 Forward-Port-Of: odoo/enterprise#8610 Forward-Port-Of: odoo/enterprise#8603
Original PR description
Don't send next activity mail as the sign request mail is quite sufficient. Task 1944014 Forward-Port-Of: odoo/enterprise#8610 Forward-Port-Of: odoo/enterprise#8603
[FIX] account_reports: financial reports: count_rows: make use of get_with_statement Without that, features added with using the get_with_statement (such as the threshold date used in mod 347 of l10n_es_reports) [FIX] l10n_es_reports: mod 347: count the number of partners having an invoice compatible with mod 347 instead of just the ones with an invoice This change was necessary for consistency with the rest of the report. In most cases, however, this bug will not occur, as the mod 3
Original PR description
[FIX] account_reports: financial reports: count_rows: make use of get_with_statement Without that, features added with using the get_with_statement (such as the threshold date used in mod 347 of l10n_es_reports) [FIX] l10n_es_reports: mod 347: count the number of partners having an invoice compatible with mod 347 instead of just the ones with an invoice This change was necessary for consistency with the rest of the report. In most cases, however, this bug will not occur, as the mod 347 invoice type field has a default value. So, it needs to be manually set to None by the user to cause some real issue, in which case a module update will be necessary. Forward-Port-Of: odoo/enterprise#8452 Forward-Port-Of: odoo/enterprise#8422
Forward-Port-Of: odoo/enterprise#8567
Original PR description
Forward-Port-Of: odoo/enterprise#8567
We have to do this in 13.1 because of the migration tests failure. There was a missing dependency in web_mobile: "mail". To fix this we have to: 1. Rename "ocn_client" to "mail_mobile" for consistency. 2. Automatically install it if mail_enterprise is installed. 3. Move the part of code that depends on mail from "web_mobile" to "mail_mobile". Task ID: 2178953 Forward-Port-Of: odoo/enterprise#8524
Original PR description
We have to do this in 13.1 because of the migration tests failure. There was a missing dependency in web_mobile: "mail". To fix this we have to: 1. Rename "ocn_client" to "mail_mobile" for consistency. 2. Automatically install it if mail_enterprise is installed. 3. Move the part of code that depends on mail from "web_mobile" to "mail_mobile". Task ID: 2178953 Forward-Port-Of: odoo/enterprise#8524
On the salary configurator page, if the transport mode of the employee was not set to "private car" and if the "km to work" were set to any value, checking private car does not update dynamically the refund. Forward-Port-Of: odoo/enterprise#8568
Original PR description
On the salary configurator page, if the transport mode of the employee was not set to "private car" and if the "km to work" were set to any value, checking private car does not update dynamically the refund. Forward-Port-Of: odoo/enterprise#8568
This commit ensures that the test waits for the document inspector painting before interacting with it. The bug was introduced in #7911 Forward-Port-Of: odoo/enterprise#8561
Original PR description
This commit ensures that the test waits for the document inspector painting before interacting with it. The bug was introduced in #7911 Forward-Port-Of: odoo/enterprise#8561
For some strange reason, rng validation struggles with many attributes and become quadratic. 16 attributes ~ 1 seconds 17 attributes ~ 5 seconds 18 attributes 30~40 second 19 attributes more than 2 minutes With project_forecast installed, planning.planning_view_gantt has 18 attributes. General _schema_gant validation takes around 7% of an enterprise install. With this new adapted python validation, we except to make the validation time almost negligible . http://runbot20.odoo.c
Original PR description
For some strange reason, rng validation struggles with many attributes and become quadratic. 16 attributes ~ 1 seconds 17 attributes ~ 5 seconds 18 attributes 30~40 second 19 attributes more than 2 minutes With project_forecast installed, planning.planning_view_gantt has 18 attributes. General _schema_gant validation takes around 7% of an enterprise install. With this new adapted python validation, we except to make the validation time almost negligible . http://runbot20.odoo.com/runbot/static/build/1304375-saas-13-2-6cb268/logs/flame_flamegraph-install-all.svg libxml2 corresponding issue: https://gitlab.gnome.org/GNOME/libxml2/issues/146 Forward-Port-Of: odoo/enterprise#8546 Forward-Port-Of: odoo/enterprise#8536
Forward-Port-Of: odoo/enterprise#8399
Original PR description
Forward-Port-Of: odoo/enterprise#8399