Sunday, December 4, 2022
9 changes · master
Resolved issues and error corrections
This fixes a configuration screen issue caused by a recent invoice template change. Argentina localization and Colombia point-of-sale settings should display correctly again, avoiding setup confusion for affected users.
Original PR description
This commit was merged during a small hiccup of runbot's l10n staging 🥴
This fixes a template conflict affecting Peru electronic invoicing reports after a recent system change. It helps ensure invoice reports and related configuration screens continue to render correctly without interference from other localization customizations.
Original PR description
This commit was merged during a small hiccup of runbot's l10n staging 🥴
Miscellaneous changes
This fixes the performance of the search panel of `account.move.line` Menu > Accounting > Accounting > Journal Items The control panel based on the accounts' roots was the issue (call to `search_panel_select_range`) Before this fix, the entire table was read through the use of a `read_group`. Since the data returned by the `read_group` is not interresting in our case, we can simply do a lateral join on an indexed column with a limit in order to improve the performances. Forward-Port-Of: od
Original PR description
This fixes the performance of the search panel of `account.move.line` Menu > Accounting > Accounting > Journal Items The control panel based on the accounts' roots was the issue (call to `search_panel_select_range`) Before this fix, the entire table was read through the use of a `read_group`. Since the data returned by the `read_group` is not interresting in our case, we can simply do a lateral join on an indexed column with a limit in order to improve the performances. Forward-Port-Of: odoo/odoo#103564
If an aml has no product, it should not trigger a model that has a product. So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters. We also changed a bit how the company field on distribution model is valued. The idea is that a model with a company specified should be better than a model without one. But we also want that a model with 1 valid rule and no company is better than one with only a good selected company. Descript
Original PR description
If an aml has no product, it should not trigger a model that has a product. So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters. We also changed a bit how the company field on distribution model is valued. The idea is that a model with a company specified should be better than a model without one. But we also want that a model with 1 valid rule and no company is better than one with only a good selected company. 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#103787
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines. We add the info in the context of the button, so automatic flows are still not blocked. t-3040929 Description of the issue/feature this PR addresses: Current behavior before PR: When the applicability rule requires a mandatory analytic distribution, no check at all on POs, SOs, Expenses. Desired behavior after PR is merged: Whe
Original PR description
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines. We add the info in the context of the button, so automatic flows are still not blocked. t-3040929 Description of the issue/feature this PR addresses: Current behavior before PR: When the applicability rule requires a mandatory analytic distribution, no check at all on POs, SOs, Expenses. Desired behavior after PR is merged: When the applicability rule requires a mandatory analytic distribution, raise an error upon : - confirming PO, - sending SO (or approving it in backend) - approving Expense Report by manager. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104147
Description of the issue/feature this PR addresses: Current behavior before PR: Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard have text overflow bug for large numbers , in USD/EUR this bug might be rare but in currency like Yuan or VND its common  Desired behavior after PR is merged: The text part will be pushed to the left when number too large
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard have text overflow bug for large numbers , in USD/EUR this bug might be rare but in currency like Yuan or VND its common  Desired behavior after PR is merged: The text part will be pushed to the left when number too large  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106737 Forward-Port-Of: odoo/odoo#104782
latam task 445 related to opw-2528442 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96074
Original PR description
latam task 445 related to opw-2528442 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96074
This commit ensures that when searching on `name` field of `website.page` model, it works properly when `pg_trgm` is activated. Indeed, `name` is a field of `website.page` record but only at the ORM level, not in SQL, due to how `inherits` works. So, when the `pg_trgm` extension is enabled, it will switch from ORM queries to raw SQL query (to use the native SQL similarity feature and not our custom python/orm one, as obviously the SQL one is better, more powerfull/accurate and faster). But t
Original PR description
This commit ensures that when searching on `name` field of `website.page` model, it works properly when `pg_trgm` is activated. Indeed, `name` is a field of `website.page` record but only at the ORM level, not in SQL, due to how `inherits` works. So, when the `pg_trgm` extension is enabled, it will switch from ORM queries to raw SQL query (to use the native SQL similarity feature and not our custom python/orm one, as obviously the SQL one is better, more powerfull/accurate and faster). But this will actually make the code fail when searching on fields from a model which has `inherits` and that you search on that `inherits` model fields. Note that in 15.2, the `pg_trgm` extension is auto installed when possible thanks to [1] and [2]. [1]: https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff [2]: https://github.com/odoo/odoo/commit/75e6b645acdc95aece506ce0249fd0760838281c opw-3063592 Forward-Port-Of: odoo/odoo#107119 Forward-Port-Of: odoo/odoo#106879
Have 2 companies with Inter-Company Transactions set to 'Synchronize Inoices/bills' Create an Analytic Account A with no company and Plan P having no company as well Create an invoice from company 1 to company 2, set A on a invoice line Confirm invoice Error will raise Database fetch misses ids (('19',)) and has extra ids ((19,)), may be caused by a type incoherence in a previous request opw-3063728 Forward-Port-Of: odoo/enterprise#34587
Original PR description
Have 2 companies with Inter-Company Transactions set to 'Synchronize Inoices/bills'
Create an Analytic Account A with no company and Plan P having no company as well
Create an invoice from company 1 to company 2, set A on a invoice line Confirm invoice
Error will raise
Database fetch misses ids (('19',)) and has extra ids ((19,)), may be caused by a type incoherence in a previous request
opw-3063728
Forward-Port-Of: odoo/enterprise#34587