Wednesday, May 19, 2021
4 changes · master
Enhancements to existing features
This update improves performance by caching regional tax position lookups that are used frequently, such as when showing product prices in the online shop. Customers and staff should experience faster page loading and pricing calculations, especially on pages with many products.
Original PR description
'_get_fpos_by_region' is called quite regularly (once per product to compute the price on website "/shop" for example). This is master data that hardly changes, the cache saves a significant amount of time. Refactoring how to get information might improve performance and no longer require this cache. 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
The mail module now retrieves message recipient data much more efficiently when databases contain very large numbers of contacts and followers. This reduces delays in notification-related processing and can improve responsiveness for customers with high-volume communication data.
Original PR description
Previous implementation with WHERE EXISTS works slowly with big res_partner
table. So, use JOIN explicitly.
Also, check simpler condition first (partner.id in (123,456,)).
It's ok to keep WHERE EXISTS for mail_channel, because it's unlikely to have
many records there.
TEST:
1. populate partners and followers
```
records = env['res.partner']
for num in range(1, 1333000):
partner = env['res.partner'].create({'name': "dummy %s" % num})
for r in records:
devnull = r.message_subscribe(partner.ids)
records |= partner
if len(records) > 5:
records = records[3:]
if not num % 10000:
print(num)
env.cr.commit()
```
2. add time measuring for _get_recipient_data
3. run test
-i test_mail --test-tags /test_mail:DuplicateNotificationTest
MY RESULTS:
* 600K records in res.partner
* 3M records in mail.followers
* _get_recipient_data:
* BEFORE: 1.7 sec
* AFTER: 0.003 sec
---
opw-2411637Website forms now show a loading spinner while files are uploading, so visitors know their submission is in progress. If an uploaded file is too large, the visitor receives a specific error message instead of a vague failure notice.
Original PR description
If a visitor tries to send a file too large, they will get a message after a while that an error occurred. This isn't specific enough. Now when a visitor sends a form, a spinner will appear indicating that the file is being uploaded. If the upload fails because the file is too large, the user will be notified. task-2234699
Users can now retry failed or canceled SMS messages directly from the SMS form, and resend multiple failed messages at once from the list view. This reduces manual follow-up work and makes it easier to recover from SMS delivery failures.
Original PR description
PURPOSE If the user send SMS automatically and doesn't pay attention that the sending of his SMS is failing, he has to go through each record one by one to resend the SMS. An action to resend all of…
PURPOSE
If the user send SMS automatically and doesn't pay
attention that the sending of his SMS is failing,
he has to go through each record one by one to
resend the SMS. An action to resend all of the
failed SMS in batch would ease the process.
SPECIFICATION
by sending SMS one by one is a heavy process if
message in a bulk, and in the form view if the SMS
failed there are no option to resend that message or
put that message again in outgoing state.
so for this problem we are adding a resend button in
form view and it's visible only in error or canceled
state, by clicking this the message will be in outgoing
state so user can resend the message.
and if there are lots of failed messages in the tree view
than user can select the failed messages and from the tree view
it can resend all the messages directly.
Task Id:2465233
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr