Odoo Changelog — 2021-05-12

Wednesday, May 12, 2021

18 changes · master

Improvements(1)

Enhancements to existing features

[IMP] hr_payroll: generate payslip report in batches in cron

Enterprisemasterhr_payrolldocuments_hr_payrollMedium

Payslip reports and related emails are now created by an hourly scheduled process instead of during payslip validation. This reduces the risk of payroll validation failing or timing out when many payslips are processed at once.

Original PR description

Instead of generating the payslip report (and the email) upon payslip
validation, run them in batches in a cron every hour.
Previously a big batch of payslip could lead to a time out and thus a
fail.

Task ID: 2501296

#payroll#payslips#reports#automation

Bug Fixes(1)

Resolved issues and error corrections

[FIX] stock : merge and unlink quants fast

PR #64188

CoremasterstockMedium

Inventory actions involving serialized products now clean up only the relevant product records instead of scanning the full inventory history. This reduces delays on large databases and adds routine daily cleanup to keep stock records efficient over time.

Original PR description

**Description of the issue/feature this PR addresses:**
On large database with product with serial number, when you perform those actions
- on product : action_open_quants()
- on stock.quant.package : unpack()

It take lot of time (12 secondes with database with 1 200 000 stock.quants).

This PR perform merge and unlink zero quant only on current product. And make an daily vacuum

This issue exist in V12 to master.

@nim-odoo
@rco-odoo 

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Other(16)

Miscellaneous changes

[FW][FIX] account: speeds up `account.payment` deletion

PR #70719

Coremasteraccount

Original PR description

The deletion of `account.payment` were slowed down because of the missing index ``` QUERY PLAN…

The deletion of `account.payment` were slowed down
because of the missing index

```
                                                                                  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Delete on account_payment  (cost=20.37..44.45 rows=10 width=34) (actual time=0.449..0.450 rows=0 loops=1)
   ->  Nested Loop  (cost=20.37..44.45 rows=10 width=34) (actual time=0.383..0.404 rows=10 loops=1)
         ->  HashAggregate  (cost=19.95..20.05 rows=10 width=32) (actual time=0.378..0.380 rows=10 loops=1)
               Group Key: "ANY_subquery".id
               Batches: 1  Memory Usage: 24kB
               ->  Subquery Scan on "ANY_subquery"  (cost=0.42..19.92 rows=10 width=32) (actual time=0.035..0.371 rows=10 loops=1)
                     ->  Limit  (cost=0.42..19.82 rows=10 width=4) (actual time=0.032..0.365 rows=10 loops=1)
                           ->  Nested Loop  (cost=0.42..186848.76 rows=96312 width=4) (actual time=0.031..0.364 rows=10 loops=1)
                                 ->  Seq Scan on account_payment_pre_backup pay_backup  (cost=0.00..14763.48 rows=277317 width=4) (actual time=0.015..0.086 rows=53 loops=1)
                                       Filter: ((state)::text <> ALL ('{draft,cancelled}'::text[]))
                                       Rows Removed by Filter: 166
                                 ->  Index Scan using account_payment_pkey on account_payment pay  (cost=0.42..0.62 rows=1 width=4) (actual time=0.005..0.005 rows=0 loops=53)
                                       Index Cond: (id = pay_backup.id)
                                       Filter: (move_id IS NULL)
                                       Rows Removed by Filter: 1
         ->  Index Scan using account_payment_pkey on account_payment  (cost=0.42..2.44 rows=1 width=10) (actual time=0.002..0.002 rows=1 loops=10)
               Index Cond: (id = "ANY_subquery".id)
 Planning Time: 0.294 ms
 Trigger for constraint account_move_line_payment_id_fkey: time=1.236 calls=10
 Trigger for constraint account_payment_sale_order_rel_account_payment_id_fkey: time=0.195 calls=10
 Trigger for constraint credit_token_payment_id_fkey: time=1.308 calls=10
 Trigger for constraint payment_transaction_payment_id_fkey: time=0.288 calls=10
 Trigger for constraint account_invoice_payment_rel_payment_id_fkey1: time=0.191 calls=10
 Trigger for constraint account_move_payment_id_fkey: time=6015.799 calls=10
 Trigger for constraint account_payment_account_bank_statement__account_payment_id_fkey: time=0.444 calls=10
 Execution Time: 6019.988 ms
```

upg-12139

Forward-Port-Of: odoo/odoo#70712

Instead of generating the payslip report (and the email) upon payslip validation, run them in batches in a cron every hour. Previously a big batch of payslip could lead to a time out and thus a fail. Task ID: 2501296

**Description of the issue/feature this PR addresses:** On large database with product with serial number, when you perform those actions - on product : action_open_quants() - on stock.quant.package : unpack() It take lot of time (12 secondes with database with 1 200 000 stock.quants). This PR perform merge and unlink zero quant only on current product. And make an daily vacuum This issue exist in V12 to master. @nim-odoo @rco-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The deletion of `account.payment` were slowed down because of the missing index ``` QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Delete on account_payment (cost=20.37..44.45 rows=10 width=34) (actual time=0.449..0.450 rows=0 loops=1) -> Nested Loop (cost=20.37..44.45 rows=10 width=34) (actual time=0.383..0.404 rows=10 loops=1) -> HashAggregate (cost=19.95..20.05 rows=10 width=32) (actual time=0.378..0.380 rows=10 loops=1) Group Key: "ANY_subquery".id Batches: 1 Memory Usage: 24kB -> Subquery Scan on "ANY_subquery" (cost=0.42..19.92 rows=10 width=32) (actual time=0.035..0.371 rows=10 loops=1) -> Limit (cost=0.42..19.82 rows=10 width=4) (actual time=0.032..0.365 rows=10 loops=1) -> Nested Loop (cost=0.42..186848.76 rows=96312 width=4) (actual time=0.031..0.364 rows=10 loops=1) -> Seq Scan on account_payment_pre_backup pay_backup (cost=0.00..14763.48 rows=277317 width=4) (actual time=0.015..0.086 rows=53 loops=1) Filter: ((state)::text <> ALL ('{draft,cancelled}'::text[])) Rows Removed by Filter: 166 -> Index Scan using account_payment_pkey on account_payment pay (cost=0.42..0.62 rows=1 width=4) (actual time=0.005..0.005 rows=0 loops=53) Index Cond: (id = pay_backup.id) Filter: (move_id IS NULL) Rows Removed by Filter: 1 -> Index Scan using account_payment_pkey on account_payment (cost=0.42..2.44 rows=1 width=10) (actual time=0.002..0.002 rows=1 loops=10) Index Cond: (id = "ANY_subquery".id) Planning Time: 0.294 ms Trigger for constraint account_move_line_payment_id_fkey: time=1.236 calls=10 Trigger for constraint account_payment_sale_order_rel_account_payment_id_fkey: time=0.195 calls=10 Trigger for constraint credit_token_payment_id_fkey: time=1.308 calls=10 Trigger for constraint payment_transaction_payment_id_fkey: time=0.288 calls=10 Trigger for constraint account_invoice_payment_rel_payment_id_fkey1: time=0.191 calls=10 Trigger for constraint account_move_payment_id_fkey: time=6015.799 calls=10 Trigger for constraint account_payment_account_bank_statement__account_payment_id_fkey: time=0.444 calls=10 Execution Time: 6019.988 ms ``` upg-12139 Forward-Port-Of: odoo/odoo#70712

RATIONALE All unassigned leads should be assigned to teams as soon as possible to ease lead analysis. Purpose of assign thresholds is to ensure sales people receive at least this amount of leads within 30 days, counting lost and won leads. Giving them leads regularly is also one goal of automatic assign. SPECIFICATIONS: TEAM ALLOCATION Team assignment has to be updated as we may have team domains that overlap. We therefore remove maximum number of leads to allocate to teams. Instead all available unassigned leads are allocated within teams. - Solution: assign all available leads and not a count based on team's capacity. This notably reverts the main goal of odoo/odoo@6df2f0c (see odoo#48422) This assignment process is done proportionally to the team capacity. It is computed as the sum of each member's maximum assignment counter. This means that with a team having twice as much sale capacity than another team sharing the same domain: first team should receive about 2/3 of leads while the second one should receive the remaining 1/3. - Solution: assign lead one by one. Choose a team randomly using a weighted random algorithm, based on team's members capacity. SPECIFICATIONS: MEMBER ASSIGN Counting every lead whatever its state may lead to an inconvenient situation. Moreover salespersons may opt-out from assign by setting their max capacity to 0, for example when going on holidays. When doing that lead assignment is not smooth and getting back to a full pipe may take several days. To solve that issue a compensation is added in assignment quota done to sales people. Salespersons having few leads will get a boost in assign as soon as they get back in assign process. When being near maximum compensation is nearing 0 and daily quota is given. ENSURE SALES PERSONS PIPE FILLING Counting every lead whatever its state may lead to an inconvenient situation. If a salesman always reaches its maximum every days he will always receive the number of lead he got 30 days ago. For example if the salesman goes in holidays for few days and set the max to 0 he receives no lead during his vacation. Then after a few days of assign he reaches its maximum and receive 0 leads for a few days. This leads to having windows of leads that repeat themselves every 30 days. * Solution: do not limit at maximum capacity anymore. Compensation is voided if limit is achieved. However asked assignment is done. Salesman could receive more than its max capacity but 30 days window ensure old leads are regularly going out of count. ``assignment_max`` is now more a mean target of leads to be assigned during a 30 days window than a real maximum capacity. Field is renamed accordingly. WORK DAYS / CRON TIME CONFIGURATION When running the cron is should assign leads based on its frequency. If cron runs once every day, work_days given to sub methods should be 1. If it runs more than once day it should be less than 1. We therefore remove the *2 multiplier and support fraction of days. As assign process changes in this merge, assigning more strictly compared to salespersons capacity will not be an issue anymore. Assign process is best designed to run every few hours (~4 times / day) or each few days. Code and work_days are updated accordingly. PERFORMANCE During team assignment setting team on leads one lead at a time may cause performance issue. As PLS is computed at each flush we want to flush after a bunch of lead. For that purpose we need to avoid too much commits and also avoid to search for duplicate at each assignation. We therefore perform the search for duplicates before going into allocation and use a cache through loops to ease using pre-fetched information. Unlinking duplicates at each iteration is also sub efficient as it causes recomputation or invalidation. We therefore aggregate all duplicates to unlink and unlink them in the main team-based loop instead of the sub loop that is lead-based. LESS AUTO COMMITS During team assignation, assigning lead one by one may cause performance issue. Since PLS is computed at each flush, so we want to flush after a bunch of lead. To solve that we obviously need to not commit at each assignation but also avoid to search for duplicate at each assignation, that why the search for duplicates is done at the beginning of the process and stored in memory. ASSIGN WON / LOST LEADS USAGE In this merge we also * use stage instead of probability to exclude won duplicated leads in order to include leads with 100% but still not won; * count all leads in lead_month_count used in assign to effectively compute sales persons workload; * keep team when assigning and deduplicating leads instead of erasing master opportunity team; * crm: correctly filter out won and lost leads for assignment using stage; LINKS Task ID-2444908 (assign fixes) Task ID-2489951 (assign process improvements) COM PR odoo/odoo#70172 Forward-Port-Of: odoo/odoo#70664 Forward-Port-Of: odoo/odoo#70172

Improvements(1)

[IMP] hr_payroll: generate payslip report in batches in cron

Bug Fixes(1)

[FIX] stock : merge and unlink quants fast

Other(16)

[FW][FIX] account: speeds up `account.payment` deletion

Improvements(1)

[IMP] hr_payroll: generate payslip report in batches in cron

Bug Fixes(1)

[FIX] stock : merge and unlink quants fast

Other(16)

[FW][FIX] account: speeds up `account.payment` deletion

[FW][FIX] website_livechat: error during closing livechat

[FW][FIX] purchase_stock: PO line related stock moves getting stuck

[FW][FIX] website : prevent bad query

[FW][FIX] iot: Fix port 9000 used by Ingenico in IoT

[FW][FIX] account: Partial revert of https://github.com/odoo/odoo/commit/…

[FW][IMP] l10n_generic_coa: add missing default tax closing accounts on CoA

[FW][FIX] product: correctly consider context key for display_name

[FW][FIX] crm: correctly compute phone_sanitized without having crm_sms i…

[FW][MERGE][REF] crm: ensure teams and salespersons pipe constant filling

[FW][FIX] slides: Verifying the returned value of re.search before accessing the capture groups.

[FW][FIX] mail: impossible to update image of user on large database

[FW][FIX] project: incorrect creation of recurring tasks

[FW]Saas 14.2 assign burp tde

[FW][FIX] sale_amazon: fix sync of partially canceled orders

[FW][FIX] iot: Fix port 9000 used by Ingenico in IoT