Odoo Changelog — 2020-07-24

Friday, July 24, 2020

3 changes · master

Improvements(3)

Enhancements to existing features

[IMP] web: show server action as list view button

Coremasterwebbaseaccountcrmcrm_smshr_expenselunchmrppurchasestockMedium

Odoo can now show selected server actions as buttons directly in the list view control panel instead of hiding them in the action menu. This makes common actions faster to access across areas such as accounting, CRM, expenses, manufacturing, purchasing, stock, and lunch.

Original PR description

PURPOSE

We want to enable the framework to define some of those server
actions in the controlpanel, same as buttons like
'create/edit/discard' buttons.

SPECIFICATION

- added a display_in_controlpanel Boolean field in
  ir.actions.server
- server action with this field having true value will be shown as 
  button in list view and that also displayed when user selects the 
  record from the list view and that action will not be shown in action menu

LINKS

PR https://github.com/odoo/odoo/pull/52425
Task 2246383

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

#list view#actions#control panel#productivity

[IMP] core: smaller and faster field cache

PR #54878

CoremastercorewebsiteMedium

Odoo’s internal field cache was reorganized to use less memory and speed up common operations across many records. This should improve overall performance and resource usage without changing user-facing workflows.

Original PR description

Consider a context-dependent field and two possible cache structures for storing the data of that field for N records and K context keys.  The common use-case is to assume that N is much larger than K.  We look at how many dicts are used in each cache structure, where we label dicts with N entries as "large", and dicts with K entries as "small".
    
         Structure                 | Number of dicts
        ---------------------------+-------------------
         cache[field][id][key]     | 1 large + N small
         cache[field][key][id]     | 1 small + K large
    
It is known that "small" dicts have a large relative overhead when compared to "large" dicts.  Given this fact, the second cache structure will generate less memory overhead.  Here are numbers for N=16, showing the size in bytes taken by the cache structure.  Larger values of N lead to larger size differences, always in favor of the second structure.
    
         Structure             |  K=1 |  K=2 |  K=3 |  K=4 |  K=5 |  K=6
        -----------------------+------+------+------+------+------+------
         cache[field][id][key] | 4488 | 4488 | 4488 | 4488 | 4488 | 6536
         cache[field][key][id] |  888 | 1536 | 2184 | 2832 | 3480 | 4256
    
Moreover, some memory operations are performed on many records and a single context key.  Those operations are clearly simpler and faster with the second cache structure.

[MERGE] *: rewrite search panel with OWL

PR #10096

Enterprisemasteraccount_accountantdocumentsdocuments_spreadsheetmrp_mpsstock_barcodeweb_dashboardweb_enterpriseMedium

The search panel has been modernized across enterprise apps to align with Odoo's newer interface framework, improving consistency and maintainability. Documents search, mobile search layouts, and dashboard filtering were updated so users get a more consistent search and filtering experience across devices.

Original PR description

In https://github.com/odoo/odoo/pull/49899, the old SearchPanel widget has been converted to an OWL component and the class Model (module addons/web/static/src/js/model.js) has been refactored to…

In https://github.com/odoo/odoo/pull/49899, the old SearchPanel widget has been converted to an OWL component and the class Model (module addons/web/static/src/js/model.js) has been refactored to support multiple extensions. In the present PR, we bring several corresponding changes in enterprise, mainly:

- in documents: the extension of the search panel had to be adapted.
  The logic regarding the rendering and the interactions has been given to
  a newly created DocumentsSearchPanel component while the data logic has been transferred
  to a new model extension, the DocumentsSearchPanelExtension.

- in web_dashboard: a small model extension has been created for the dashboard view
  in order to handle the clicks on aggregates having a domain attribute.
  That model extension manages the domain to add to the global query and the additional facet
  to display in the search bar when such an aggregate is clicked on. It was done previously in
  the control panel model in a rather unsatisfactorily way.

- for the mobile mode: the mobile version of the search panel has been adapted
  and the search view layouts used by both the search panel and control
  panel have been merged to increase consistency and maintainability.
  This includes a few DOM modifications in the control panel mobile XML
  and SCSS files as well as a major refactor of the mobile search panel
  layout.

Task ID: 2228968

PURPOSE We want to enable the framework to define some of those server actions in the controlpanel, same as buttons like 'create/edit/discard' buttons. SPECIFICATION - added a display_in_controlpanel Boolean field in ir.actions.server - server action with this field having true value will be shown as button in list view and that also displayed when user selects the record from the list view and that action will not be shown in action menu LINKS PR https://github.com/odoo/odoo/pull/52425 Task 2246383 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Consider a context-dependent field and two possible cache structures for storing the data of that field for N records and K context keys. The common use-case is to assume that N is much larger than K. We look at how many dicts are used in each cache structure, where we label dicts with N entries as "large", and dicts with K entries as "small". Structure | Number of dicts ---------------------------+------------------- cache[field][id][key] | 1 large + N small cache[field][key][id] | 1 small + K large It is known that "small" dicts have a large relative overhead when compared to "large" dicts. Given this fact, the second cache structure will generate less memory overhead. Here are numbers for N=16, showing the size in bytes taken by the cache structure. Larger values of N lead to larger size differences, always in favor of the second structure. Structure | K=1 | K=2 | K=3 | K=4 | K=5 | K=6 -----------------------+------+------+------+------+------+------ cache[field][id][key] | 4488 | 4488 | 4488 | 4488 | 4488 | 6536 cache[field][key][id] | 888 | 1536 | 2184 | 2832 | 3480 | 4256 Moreover, some memory operations are performed on many records and a single context key. Those operations are clearly simpler and faster with the second cache structure.

In https://github.com/odoo/odoo/pull/49899, the old SearchPanel widget has been converted to an OWL component and the class Model (module addons/web/static/src/js/model.js) has been refactored to support multiple extensions. In the present PR, we bring several corresponding changes in enterprise, mainly: - in documents: the extension of the search panel had to be adapted. The logic regarding the rendering and the interactions has been given to a newly created DocumentsSearchPanel component while the data logic has been transferred to a new model extension, the DocumentsSearchPanelExtension. - in web_dashboard: a small model extension has been created for the dashboard view in order to handle the clicks on aggregates having a domain attribute. That model extension manages the domain to add to the global query and the additional facet to display in the search bar when such an aggregate is clicked on. It was done previously in the control panel model in a rather unsatisfactorily way. - for the mobile mode: the mobile version of the search panel has been adapted and the search view layouts used by both the search panel and control panel have been merged to increase consistency and maintainability. This includes a few DOM modifications in the control panel mobile XML and SCSS files as well as a major refactor of the mobile search panel layout. Task ID: 2228968