Thursday, May 16, 2024
2 changes · 17.0
Enhancements to existing features
This update significantly speeds up the product variant creation process when dealing with many product options and exclusion rules. By optimizing how the system checks which product combinations are valid, operations that previously took over 15 minutes now complete in just 12 seconds, dramatically improving user experience when managing complex products with many variants.
Original PR description
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to…
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and `self._get_own_attribute_exclusions` for each combination is pretty slow. To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequence of combinations and yield those that are valid w.r.t. the exclusions. Because values that only depends on self are computed once before looping through the combinations, this lead to a significant speedup. This method is a generator to avoid MemoryErrors, be able to raise a UserError after "creating" 1000 variants and be consistent with choices made in `_create_variant_ids`. https://github.com/odoo/odoo/blob/0042b9d3eece219d4e89fe9c6ecb9971a1f3bf12/addons/product/models/product_template.py#L710 #### speedup Customer saas-16.4 database with 378 templates, 3832 products, 44 product.attributes, 186 product.attribute.values, 79 product.template.attribute.lines, 484 product.template.attribute.values, 374 product.template.attribute.exclusions. No dynamic attributes. Timing to write on product.template, adding a new attribute value on a ProductTemplate Form increasing the number of combinations. | Combinations | Before PR | After PR | |:------------:|:----------------:|:--------:| | 4 | 219ms | 218ms | | 55 | 785ms | 440ms | | 216 | 1.36s | 592ms | | 1 944 | 28s | 809ms | | 33 048 | 5min30s | 3.78s | | 231 336 | +15min (timeout) | 12s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162239
Resolved issues and error corrections
This update fixes critical issues in Hungarian electronic invoice processing that were causing system crashes and blocking email delivery. The changes prevent crashes when invoice names aren't set, allow demo mode usage without credentials, enable proper email delivery for invoices in certain states, and ensure modification invoices use the correct submission method to allow future corrections.
Original PR description
1. Avoid crashing if move.name is not set
In the tests
- `:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion`
- `:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_mode`
the compute method `_compute_l10n_hu_edi_attachment_filename` was called before the invoice name was set.
Because of this, calling move.name.replace('/', '_') was raising an AttributeError.
2. Allow user to not put credentials when they are using demo mode.
3. sent (waiting for response) and confirmed_warning states should not raise a UserError and should not block an e-mail from being sent to the customer.
4. always send modification invoices using 'MODIFY' (never 'STORNO') since 'STORNO' prevents further modifications from being issued to the invoice, but in Odoo we can't predict whether the user will want to issue further corrections to an invoice in the future.
Fixes runbot errors 64755 and 64756.