Friday, January 28, 2022
7 changes · master
Enhancements to existing features
This update improves how Odoo creates multiple records at once across many business apps. It should reduce processing overhead during bulk operations and lays groundwork for more consistent performance improvements in future updates.
Original PR description
By default, the ORM supports batch creation of records, but when one `create` overrides doesn't support the creation of records in batch, records creation on the given model are done 1 by 1, disabling lots of improvements gained thanks to the manipulation of records in batch. To enable such performance improvements (at the ORM level, but also in create overrides sometimes), this PR aims to adapt the majority of existing create overrides in Odoo codebase to support batch record creation. Some of the changes won't really have any impact because the records are always created one by one, but converting them: 1) encourages new create override to support multi record creation (devs are copy/pasting/... a lot) 2) provides the basis for a potential future API change to enforce batch creation support. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Form views now keep fields, labels, and spacing more consistent when users switch between edit and read-only modes. This reduces visual jumping on the page, making data entry and review feel steadier and easier to follow.
Original PR description
Reduce shift in form view when switching mode --- This PR reduces the shift between edit and readonly mode in the form view. Reducing the shift means that both modes should be identical: * Fields should be at the same place * Fields have the same render in both modes * Labels shouldn't show only in one mode, whether they appear in both or they does not Task 2330101 Enterprise PR: https://github.com/odoo/enterprise/pull/15191
This update makes Odoo handle company context more consistently across web screens, server calls, and attendance kiosk flows. It helps users working with multiple companies see and act on the right company information, reducing confusion and unexpected behavior.
Original PR description
#### Session multi-company API * clear access to current company(ies) * Ensure coherence between request.env.company and self.env.company in call_kw routes * Fix existing _rpc calls with routes, forgiving the user_context in params.context ... maybe more -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now avoids automatically loading translated fields that are unlikely to be used, reducing database work on large records. Key fields that are commonly displayed, such as names, website SEO content, mail templates, and VAT labels, continue to load as needed to preserve expected behavior.
Original PR description
Issue ----- Via the field prefetch mechanism, when we need a value of one field (not in cache of course), the ORM will prefetch all fields (which has the attribute to `prefetch=True`, the default…
This update improves the website shop editor so product ribbons can be adjusted more smoothly. Changes now apply automatically while editing, removing the extra validation step and making product block customization faster for website managers.
Original PR description
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
This update moves several enterprise screens to Odoo's newer multi-company handling, helping users see company-specific information more consistently. It also ensures Studio has the correct default currency even when Dashboard is not installed.
Original PR description
Enterprise counterpart of https://github.com/odoo/odoo/pull/45120
Resolved issues and error corrections
Odoo now blocks attempts to reuse an existing external identifier for a different type of record. This prevents updates from accidentally overwriting unrelated business or system records, improving data integrity during module updates or upgrades.
Original PR description
Before this commit, changing the model on an existing xml-id may lead to strange results. create any record in xml, ie: xml_id=my_xml_id, model=new_model => Odoo will create a new external_id, pointing to (new_model, id=1) change only the model in the xml, ie: xml_id=my_xml_id, model=ir.cron => Odoo will use the id of the existing external_id with the new model and points now to (ir.cron, id=1) AND REPLACE the ir.cron id=1 (autovacuum_job) with the data of the xml. This commit simply prevent that by raising when trying to recycle the same xmlid for another model. An explicit upgrade script to remove the existing xmlid and corresponding records should be write.
Issue ----- Via the field prefetch mechanism, when we need a value of one field (not in cache of course), the ORM will prefetch all fields (which has the attribute to `prefetch=True`, the default value of this attribute is `True`) for all record ids in `_prefetch_ids`. Then, for each translate fields (where translate is not a callable) the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the translated value. For big model, it leads to a simple `SELECT` with several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost in the planner time (a small cosst in the execution time) of PostgreSQL. By example, for product_template (with stock, sale and purchase installed), there are 6 LEFT JOIN to get all translate fields (5 of this fields are rarely used). Without prefetching the translate fields, there is only one LEFT JOIN (the name, which is translate but is the `_rec_name` of the model). With the 6 translate fields to fetch, the query takes 5 ms to plan and 2 ms to execute. VS with 1 translate field, it 1 ms to plan and 1.5 ms to execute. Proposed solution ----------------- Deactivate the prefetch by default for all translate fields expect if this field is the `_rec_name` of the model (which is more likely to be used). Side change note ---------------- - All translate of fields of `website.seo.metadata` should be prefetch to avoid lot of website errors (it is because, website put in cache data in sudo before reading it without sudo) - `description` (`mail.message.subtype`), `subject` (`mail.template`), `body_html` (`mail.template`) should be prefetch to avoid lot of extra query from mail module. - `vat_label` (`res.country`) should be prefetch to avoid a extra query for each website page. - Increase some queryCount (when it is legit, due to `subtitle` of `blog_post` or `description` of `event.type.ticket`, etc) task-2738029