Tuesday, February 1, 2022
12 changes · master
New functionality added to Odoo
This change adds a command-line option to neutralize copied databases before investigation, helping prevent accidental emails, payments, external service calls, or tax reporting submissions. It also updates several business modules so their sensitive external integrations are disabled during this irreversible neutralization process.
Original PR description
When debugging a database, it's sometimes desirable to neutralize it to avoid undesired side effects like sending emails. This PR adds a generic method on models to neutralize the current database. This method have to be overridden by modules models. The neutralize operation cannot be reversed should only be used on a database copy.
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
Resolved issues and error corrections
This fix ensures archived records still load their related chatter information, such as followers, activities, and suggested recipients. Business users can now view and use communication details on archived documents without missing data or errors.
Original PR description
With a recent commit[1], we now gather the chatter related data with a single controller ('/mail/thread/data') which was a bit scattered previously. With this controller, instead of searching in…
With a recent commit[1], we now gather the chatter related data with a
single controller ('/mail/thread/data') which was a bit scattered
previously. With this controller, instead of searching in dedicated
model, we now simply use the main document/record itself and it's
fields whenever possible. For example, previously for the followers,
we used to search data from 'mail.followers' model, but now we simply
use `message_follower_ids` field of the record itself.
The problem with this approach is, if the record is archived, we won't
be able to fetch the related data. That leads to empty follower list/
activities and a trackback while getting suggested recipients.
This PR fixes the issue by loading the record even if it's
archived, and thus fetching the data required by chatter.
commit[1] - https://github.com/odoo/odoo/commit/e0913197ac84b25b40e7599a6432362141d104c9
TaskID-2748030
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prOdoo 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
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
The payment registration process now automatically uses the partner's bank account and prevents users from changing or creating a different recipient account for inbound and cash-related payments. This helps reduce payment mistakes and hides the bank account field when it is not relevant for cash journals.
Original PR description
Currently: the "register payment" wizard allows selecting different bank accounts or even creating one when registering a payment on customer invoice/vendor refund. Should be: the field should be set to partner_bank_id and be set as readonly. Task ID: 2710936 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Improved how Odoo finds failed outgoing mail, SMS, and letters for the current user. This prevents long waits in failure-related views or actions, reducing response time from potentially over 20 seconds to near-instant in affected cases.
Original PR description
We are currently lacking an index with (author, failure) due to the information being spread out in two different tables which are both rather big (there are a lot of non-failure messages for the current user, as well as a lot of failure messages for other users), so the fetch of failures for the current user can become extremely slow (> 20s). With this new index, the query takes less than 1ms. task-2742946
Saving a record now avoids sending unchanged selection data to the server. This prevents unrelated sales order lines from being recalculated, reducing unexpected price changes and improving save behavior.
Original PR description
Following recent conversion of onchanges to computes in the sale scope, it was observed that updating one line triggered price recomputation in other lines (which isn't expected). After investigation, it seems that the `product_packaging_id` field is considered modified and sent on SO save for all the lines, which triggers the `product_uom_qty` record computation, then the whole price computation is triggered, since it depends on that quantity field. This commit aims to fix this case by only considering a m2o field as modified if its value was effectively changed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes visual inconsistencies when adding text fields during signing and restores pinch-to-zoom behavior on mobile. It improves the signing experience by making text fields look consistent and preventing mobile errors while users zoom documents.
Original PR description
This task fixes some UI issues found in sign while testing v15.1 and v15.2 - [FIX] sign: fix edit while signing text type handlers and font-size When a text sign item is added while signing, its font-size and handlers have different size than an item created in the template editor. This commit fixes the css of the sign item and also fixes the default width and height of text sign items. - [FIX] sign: fix pinching in mobile In mobile version of sign, pinching the screen while signing should zoom-in/ zoom-out. However, after refactoring the js code in task-2664886, pinching started causing an error. This commit fixes this issue, preventing the error caused from the loss of context when calling `PinchItemMixin.init`.