Tuesday, February 1, 2022
8 changes · master
Enhancements to existing features
The mail app now includes a database optimization that helps retrieve the latest channel messages more quickly. This can reduce waiting time in discussions or messaging areas, especially on larger systems with many messages.
Original PR description
Before this PR, the query from _channel_last_message_ids could take a significant amount of time. This add an index to speed up the query. task-2746108
Odoo now handles large batches of newly created records more efficiently by grouping database inserts instead of processing each record separately. This can improve performance for imports, data generation, and other operations that create many records at once, while also simplifying some internal database cursor handling.
Original PR description
# POC: Batch `INSERT INTO` of `_create` method (`BaseModel`) ## Idea When we create several of record in database, we make one "INSERT INTO" (one sql request) by values (by record) which isn't…
# POC: Batch `INSERT INTO` of `_create` method (`BaseModel`)
## Idea
When we create several of record in database, we make one "INSERT INTO" (one sql request) by values (by record) which isn't efficient. Then make a bulk insert instead.
The goal is to batch the insertion of record and by extension speed up `create` method when we give it many values.
## HOW TO
Make a batched version of our INSERT INTO loop in the `_create` method.
### Performance testing
To test, we use the "populate script" of odoo-bin and by changing the batch size of it to get data depending on the number of values/record to create (check the branch `master-create-insert-batch-with-measurements-ryv`).
Because we know that the drawback of this approach is when values_list are sparse (we need to fill a lot of DEFAULT value). Then create a model ('worst.case') with 100 fields and with a "populate script" which create most sparse as possible values_list.
## `create` vs `_create` vs insertion loop vs 'insert into'
- `create` measure the time of the all `create` method of `BaseModel` (then not calculate the time of inherited create)
- `_create` measure the time of the all `_create` method of `BaseModel`
- 'Insertion loop' measure the time of the insertion loop: convert_to_column + creation of query + the 'INSERT INTO'. (we focus on this one)
- 'INSERT INTO' measure only the time made by the insert into queries.
Then `create` contains `_create`, `_create` contains 'Insertion loop' and 'Insertion loop' contains 'INSERT INTO'.
### Time figures
#### Before
#### After
### % Time figures
It is the % of time of the `create` method of each step (we try to improve the red and green ones) :
#### Before
#### After
## Focus on the 'insertion loop' time (what we change)
### Graph
### Table Results
#### `create`
#### `_create`
#### 'insertion loop'
#### 'insert into'
## Note
- The result are noisy, then is hard to conclude anything when the difference is small and the variance is high.
- The `mail.follower` aren't created in batch (fix in https://github.com/odoo/odoo/pull/80954), it is why we have only the data for mono create.
## Conclusion
It is clearly worth it for small model where the time of `create` method is mainly due to the insertion in DB. Also, the test was done on my compute where the database is local and the psql use a SSD: we can expect better result with a remote psql server and/or traditional hard disk.
In another hand, it increases a bit the complexity of the code.Employee sample data now includes working schedules for all employees and links some employees to users across multiple companies. This helps appointment planning reflect real employee availability when schedules are used.
Original PR description
Previously for `appointment`, now for `appointment_hr`, the computation of users' availability for appointment slots can be dependent on that person's work schedule if: * The user is linked to an employee * The user's employee has working hours defined (resource calendar) This commit provides working hours to all employees and a user to some, within a multi-company setup. Task-2728093 See odoo/enterprise#22642 See Task-2631088
The mail server setup screens now use existing authentication choices to identify Gmail connections, reducing extra options and making configuration clearer. Administrators also get a settings option to install Gmail integration more directly from the main settings area.
Original PR description
Purpose ======= A field `use_google_gmail_service` has been used in stable to define a mail server which use Gmail authentication. But now that the field `smtp_authentication` exists, we want to use it to simplify the mail server form view. For the incoming mail server, the field `server_type` will be used for the same purpose. Add a new field to have the option to install `google_gmail` in the main settings page. Task-2170676
Manufacturing teams can now divide a manufacturing order into several smaller orders or combine compatible orders for the same product and bill of materials. This gives planners more flexibility to adjust production quantities and consolidate work when priorities or capacity change.
Original PR description
Split a manufacturing order in several parts using the back order mechanism Merge several manufacturing orders related to the same product/bom by cancelling all of them and creating a new one task: 2662566 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
Appointment sample data now includes more work-hours appointment types and more available time slots. The data also better reflects common business setups by matching appointment users with the same company, supporting more realistic testing and performance validation.
Original PR description
Add some appointment_types with category 'work_hours'. Also ensures users from an appointment type are from the same company as it is the most common use case. Finally, to increase computing load, more slots are added per appointment type. Task-2728093 See odoo/odoo#80688
Vendor bill resets now handle related draft and posted assets more consistently, preventing outdated asset records and clearer error messages. Expense accounts also clear incompatible disallowed expense categories automatically, reducing hidden configuration mistakes and duplicate chatter entries.
Original PR description
The goal is to improve the following: - When trying to reset a Vendor Bill to draft that already has one or more posted asset(s) related, the UserError text was not correct. - When resetting a Vendor Bill to draft that already has one or more draft asset(s) related, those were left and not updated after re-posting the Vendor Bill. Now they will be unlinked a created again. - When changing an account type that already has a Disallowed Expenses Category, and setting a type that is not compatible with Disallowed Expenses, the field disappears from the view, but the value remains set. That is no longer the case. - Corrects a small bug that posted the non-deductible tax value twice in the chatter when an asset was created automatically. task-2747209
Several country-specific invoicing, tax, point-of-sale certification, and mobile messaging components now support database neutralization. This helps companies prepare copied databases for testing or staging by disabling or replacing sensitive live-service settings and reducing the risk of accidental real-world transactions.
Original PR description
A _neutralize model method was added in order to neutralize a database. This commit adds the implementation of this method for various models. Companion of https://github.com/odoo/odoo/pull/67825 Task id: 1818795