Saturday, February 10, 2024
11 changes · saas-17.1
Resolved issues and error corrections
The spreadsheet component was updated to a newer maintenance version to resolve known issues. This helps improve reliability for users working with documents and spreadsheet-based views, including pivot-related scenarios.
Miscellaneous changes
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of reconciliation batches 5. Precompute fields on partials 1: Handle the inverse fields of `account.full.reconcile` manually ----------------------------------------------------------------- In order to update the inverse fields of `reconciled_line_ids` and `partial_reconcile_ids`, the ORM is tr
Original PR description
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of…
Summary: ======== 1. Handle the inverse fields of `account.full.reconcile` manually 2. Batch the update of matching numbers 3. Batch the balance consistency test 4. Batch the construction of reconciliation batches 5. Precompute fields on partials 1: Handle the inverse fields of `account.full.reconcile` manually ----------------------------------------------------------------- In order to update the inverse fields of `reconciled_line_ids` and `partial_reconcile_ids`, the ORM is triggering one query per full reconcile record. In the case of a big batch payment, that is a lot of round trips. This also bypasses the computation for possible tracking, which is expensive to do for 2 records at a time. That field is not tracked anyway. 2: Batch the update of matching numbers --------------------------------------- Basically the same as 1. without the tracking. 3: Batch the balance consistency test ------------------------------------- Use the various context managers around `__reconcile_plan` to check for the balance consistency only at the end in one single query. This avoids checking it at every single intermediate write done on the lines. Also doing it for the sync of dynamic lines. It should be useless but it doesn't cost anything, and allows to remove the context keys in enterprise without a cost. (they shouldn't be used explicitly, the context managers should always be used instead) Using these context managers also allows to remove all the `skip_` context keys, which should not be used: using them will mean that as soon as the journal entry is modified for any reason, some business fields will change because of the synchronisation since the context won't be the same anymore. This commit therefore also makes `_sync_dynamic_line` more resilient and avoids even more useless syncs. 4: Batch the construction of reconciliation batches --------------------------------------------------- Introduce `_reconciled_by_number`, which is basically a `_read_group`. In conjuction with `_filter_reconciled_by_number`, we can find all the reconciled lines in one single query, for as many batches as needed; as opposed to one query per batch before. 5: Precompute fields on partials -------------------------------- Simply avoid doing one batched `INSERT INTO` followed by one `UPDATE` for each record. Benchmark: ========== We are testing 2 use cases: * a lot of small matchings that are producing a full 2 by 2 * one big matching (also producing a full) To reconcile a batch payment of 500 (identical) lines in the bank reco: | | Queries | SQL | Other | |--------|---------|-------|--------| | Before | 4191 | 4.649 | 16.253 | | After | 226 | 0.989 | 3.581 | To reconcile one big batch of 1000 lines with the generic reco widget (spaghetti): | | Queries | SQL | Other | |--------|---------|-------|--------| | Before | 82 | 0.478 | 1.131 | | After | 66 | 0.634 | 0.974 | All the times are in seconds. We can see the the use case of the batch payment is improved a lot (the time is expected to be linear with regards to the number of payments), while the time for big batches is not impacted. Forward-Port-Of: odoo/odoo#152284
It is possible to have context keys being leaked from outside the context manager in the following case: * a new transaction starts with a new environment * the code calls `_disable_recursion` * all the existing environment are modified with the context key * inside of the context manager, a new environment is created without specifying a full context: we keep the previous one, which contains the context key * the code exits the context manager and cleans all the environment it was aware of
Original PR description
It is possible to have context keys being leaked from outside the context manager in the following case: * a new transaction starts with a new environment * the code calls `_disable_recursion` * all the existing environment are modified with the context key * inside of the context manager, a new environment is created without specifying a full context: we keep the previous one, which contains the context key * the code exits the context manager and cleans all the environment it was aware of <-- this is the issue * the environment that was created inside the context manager still contains the context key, if it is used and is never cleaned. Now, we also remove the context key of all the environments created inside the context manager. It is better to risk having some recursion (probably leading to operations being done multiple times) than doing nothing at all because the context disables some features. Forward-Port-Of: odoo/odoo#146336
Current behavior before PR: If base.partner_root email is modified before installing mail, mail will overwite it (since it is at install and not on update) Desired behavior after PR is merged: Set it up once: on database creating then let the user modify it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152665
Original PR description
Current behavior before PR: If base.partner_root email is modified before installing mail, mail will overwite it (since it is at install and not on update) Desired behavior after PR is merged: Set it up once: on database creating then let the user modify it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152665
Steps: - Create an automation rule with a model X - Delete model X (need a way that keep the rule) Actual result: - Crash due to warning message Expected result: - Warning message is logged without issue opw-3722953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153078
Original PR description
Steps: - Create an automation rule with a model X - Delete model X (need a way that keep the rule) Actual result: - Crash due to warning message Expected result: - Warning message is logged without issue opw-3722953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153078
When repartition_lines are added to an already existing account_tax record, on upgrade, the new repartition lines are inserted with just tags, which results in the insertion of null value in document_type column. To reproduce: - Modify `l10n_fr/__manifest__.py` version to `2.0` - Create an empty DB - Start `./odoo-bin -c ../.myodoorc -i l10n_fr` with demo data - Stop the database (can dump it for convenience) - Start `./odoo-bin -c ../.myodoorc -u l10n_fr` - Add a couple of repartitio
Original PR description
When repartition_lines are added to an already existing account_tax record, on upgrade, the new repartition lines are inserted with just tags, which results in the insertion of null value in…
When repartition_lines are added to an already existing account_tax record, on upgrade, the new repartition lines are inserted with just tags, which results in the insertion of null value in document_type column.
To reproduce:
- Modify `l10n_fr/__manifest__.py` version to `2.0`
- Create an empty DB
- Start `./odoo-bin -c ../.myodoorc -i l10n_fr` with demo data
- Stop the database (can dump it for convenience)
- Start `./odoo-bin -c ../.myodoorc -u l10n_fr`
- Add a couple of repartition lines (invoice + refund) to an existing tax to `odoo/addons/l10n_fr/data/template/account.tax-fr.csv`
- Modify `l10n_fr/__manifest__.py` version to `2.1`
- Start `./odoo-bin -c ../.myodoorc -u l10n_fr`
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-16.3/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/saas-16.3/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/registry.py", line 90, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 478, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 366, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/migration.py", line 233, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/saas-16.3/addons/l10n_fr/migrations/2.1/post-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('fr', company)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 142, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 186, in _load
self._load_data(data)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 499, in _load_data
created_vals[model] = self.with_context(lang='en_US').env[model]._load_records(create_vals)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4663, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4594, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/account_tax.py", line 362, in write
return super().write(self._sanitize_vals(vals))
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4033, in write
field.write(self, value)
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4240, in write
self.write_batch([(records, value)])
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4261, in write_batch
self.write_real(records_commands_list, create)
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4441, in write_real
flush()
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4397, in flush
comodel.create(to_create)
File "<decorator-gen-119>", line 2, in create
File "/home/odoo/src/odoo/saas-16.3/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/tmp/tmp90kuz8ug/migrations/util/orm.py", line 210, in wrapper
return f(*args, **kwargs)
File "/tmp/tmp90kuz8ug/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
return super().create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "/home/odoo/src/odoo/saas-16.3/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4231, in create
records = self._create(data_list)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4434, in _create
cr.execute(
File "/home/odoo/src/odoo/saas-16.3/odoo/sql_db.py", line 319, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "document_type" of relation "account_tax_repartition_line" violates not-null constraint
DETAIL: Failing row contains (305, null, 1, 1, 1, 1, tax, f, 2023-10-17 19:52:56.357571, 2023-10-17 19:52:56.357571, 100, 6, null).
```
Forward-Port-Of: odoo/odoo#149733
Forward-Port-Of: odoo/odoo#148643To reproduce: - Put your fiscal year to the 30th of December (yes it's unlikely) - Create an asset - Compute depreciations => they are created for the 31th of December It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February opw-3704466 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
Original PR description
To reproduce: - Put your fiscal year to the 30th of December (yes it's unlikely) - Create an asset - Compute depreciations => they are created for the 31th of December It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February opw-3704466 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#152710
This patch is an improvement and simplification over the fix done in 5a64974501b5be231e2eed941f42ae6dfe110f18 When generating the company search query we should skip unloaded modules to avoid a `KeyError`. This issue became more visible now that the check in `ir.rule` is done for each domain. Refer to the above commit for steps on how to reproduce the issue. This issue has a high impact in upgrades since it potentially blocks all upgrades for which a `data_merge.record` entry exists for a
Original PR description
This patch is an improvement and simplification over the fix done in 5a64974501b5be231e2eed941f42ae6dfe110f18 When generating the company search query we should skip unloaded modules to avoid a `KeyError`. This issue became more visible now that the check in `ir.rule` is done for each domain. Refer to the above commit for steps on how to reproduce the issue. This issue has a high impact in upgrades since it potentially blocks all upgrades for which a `data_merge.record` entry exists for a custom model. Forward-Port-Of: odoo/enterprise#56228
Forward-Port-Of: odoo/enterprise#56255
Original PR description
Forward-Port-Of: odoo/enterprise#56255
Simply prefetch all the values because we are analyzing a list of recordsets without any prefetch ids. Forward-Port-Of: odoo/enterprise#55633
Original PR description
Simply prefetch all the values because we are analyzing a list of recordsets without any prefetch ids. Forward-Port-Of: odoo/enterprise#55633
We used to skip the SvcLvl node on generic ISO20022 payments. This caused some banks to reject the XML file generated for them (though this node is not supposed to be mandatory). We now always set in on them, with the default NURG code, indicating that the payment is non-urgent. OPW 3679650 Forward-Port-Of: odoo/enterprise#55451 Forward-Port-Of: odoo/enterprise#55038
Original PR description
We used to skip the SvcLvl node on generic ISO20022 payments. This caused some banks to reject the XML file generated for them (though this node is not supposed to be mandatory). We now always set in on them, with the default NURG code, indicating that the payment is non-urgent. OPW 3679650 Forward-Port-Of: odoo/enterprise#55451 Forward-Port-Of: odoo/enterprise#55038