OpenERP V6 Technical Improvements

OpenERP v6.0
Technical Improvements

Olivier Dony

Nom du fichier – à compléter
OpenERP v6.0 Upgrade Training – Technical Improvements 2010.12.01 – Olivier Dony

Agenda

 Part 1
• Short overview
• Search views
• Improved Tree views, aggregation, dynamic reports
• Diagram views
• Multi-company
 Part 2
• Testing framework and continuous integration
• Usability guidelines
• New R&D Process
• Web add-ons
• Miscellaneous improvements and tips


OpenERP is disruptive


OpenERP is disruptive

Disruptive product Disruptive business

• Modern • Free download
programming • Contributions and
language Community fuel the
• Modular approach product
• Fully web-based • Value created is
• Classical or cloud fairly split between
deployment Customer, Service
Provider, and
Publisher


2010 = Cornerstone for OpenERP

 During the last 5 years, OpenERP has matured
into a smart Enterprise Management
software suite, with a world-wide brand, and
a strong market demand.
 OpenERP SA now puts focus on being the
OpenERP Publisher
 OpenERP v6 focuses on ease-of-use for these
smaller companies!


Technical Goals for OpenERP v6.0

 Make OpenERP easier for smaller companies

 Global code review and simplification

 New features

 New development processes


Easier for smaller companies

 OpenERP becomes a true suite of Business
applications
• Menus and modules structure reviewed and split
• Smaller, specific applications
» account = invoicing only
» account_accountant = full financial management
 Simplified views (vs. extended)
 Business-oriented screens and filters


Business Applications


Business-oriented screens


Code Review & Simplifications

 Improved modularity
• e.g: procurement (follows), analytic, resource
 Global Code Review
• Modules rewritten: crm, hr, caldav,
• Performance improvements: lists, reports
• Lint cleanup
• Simpler aggregation/reporting objects
 Hundreds of tests
 Lots of source code lines removed


New R&D Processes

 Dedicated R&D Teams
 SCRUM methodology
 Bug qualification team
 Testing tools and test suite
 Continuous integration system: Buildbot

More on this in Part 2...


New features

 New views: search, diagram, improved lists
 Improved API – core objects
 Focus on reusable and generic features
• custom filters
• mail.gateway, caldav, resources
 Multi-company built-in

» Let's zoom in...


Search Views

 Improves over built-in search features in v5
 Always associated with other view: list, calendar, …
 Deprecates select=1, select=2 select = True
 New view type: <search>
 Two main building blocks:
• <field name='...'>
• <filter domain='...' context='...'>
 Structured with:
• <group>
• <separator>
• <newline>


Search Views


Advanced Search Views

 <fields> with embedded <filters>
 Advanced attributes for <field>:
• context=”{'country_visible':True}”
• domain=”[('country_id', '=', 'Belgium')]”
• filter_domain=”['|', ('location_to', '=', self),
('location_src', '=', self)]”
 Default values for filters and fields, via action context:
• context=”{'search_default_filter1': True}”
• context=”{'search_default_field1': 'test'}”
• context=”{'search_default_field1': lang}”
 Specific search view can be forced in caller action:
• <field name="search_view_id"
ref="view_project_project_filter"/>


Search views: toggle group-by

 context attribute of elements can toggle aggregation
of associated list views
• <filter string="Manager"
name="manager"
icon="terp-personal"
context="{'group_by':'user_id'}"/>
 Multiple group-by levels are supported
• <filter string="Manager,State"
name="manager_state"
context="{'group_by':['user_id','state']}"/>
 Order of group-by entries matters!


Improved Lists

 List views can now display buttons
• Regular <button> elements as in form views
• Action/Method/Workflow called on single record
 Columns can be toggled via context
• context = {'section_mode': True}
• <field name=”country_id”
invisible=”context.get('invisible_country')”>


Improved Lists

 List views now support aggregation aka group-by
• Simple or multiple level aggregation
• Controlled via context: e.g. search view or caller action
context = {'group_by':['field_1','field_2']}
• All contexts are combined
• Aggregated columns shown on group header
» Numeric fields summed by default
» Set group_operator in _columns to customize (avg, min, … )
 New server-side API method: read_group()

Group-by = Real-time Reporting!

 Combine group_by values to get quick and intuitive
real-time analysis
 When individual records are too low-level or
irrelevant, hide them (e.g. stock moves) :
• context = {'group_by_no_leaf': 1}


Building Reporting Objects

...

...


Diagram Views

 Workflow Editor existed in Web Client 5.0
 Transformed into generic view, available in GTK too
 New <diagram> view type
 Constructed with
• <node object=”node.model”
shape=”...”
bgcolor=”...”>
• <arrow object=”transition.model”
source=”source_field”
destination=”dest_field” >
• <field> (included in quick view)
 Objects must form a coherent graph
 <node> model must have a many2one to its container


Diagram Views


Diagram Views

 Allows graphical definition of complex structures


Multi-Company

 Now built-in in all applications
 multi_company module = demo data only
 in-depth review added specific internal operations:
• e.g. for warehouse management:
» inventory push/pull flows, transit locations
» multi-company invoice control based on push/pull flows
» More on this in functional training (tomorrow PM)


Multi-company

 Many models now have a direct or indirect link to a
company (many2one or related field)
• e.g: sale.order.line sale.order shop company
 Relevant company is assigned when creating new
records
 Special group is needed to view multi-company fields
• Useability/Multi Companies
 Users can belong to several companies, but select the
one the current context they work in, via Preferences
 Visibility of records depends on Company they belong
to, current Company of user, and Record Rules.


Multi-company

 Record rules have been improved since v5.0
 No more rule groups – directly linked to user groups
 Now controlled per mode: create/read/update/delete
 Strong security semantics between “global” and
“local” (group-specific) rules
• Global rules cannot be bypassed under any circumstance, and
always restrict the access
• Local rules are additive and grant more access

global1 AND global2 AND (local1 OR local2)


Multi-company: Security


Testing framework: YAML

 New YAML data serialization supported in v6
 Data-oriented syntax “YAML Ain't a Markup Language”
 Whitespace delimiters, Python-like
 Human-readable
• no quotes, brackets, braces, … by default
 Works very well for data, quite suited for tests
receipt: Oz-Ware Purchase Invoice
date: 2007-08-06
customer: Dorothy Gale
items:
- part_no: A4786
descrip: Water Bucket (Filled)
price: 1.47
quantity: 4


Testing framework: YAML

 Supports everything supported by XML and more
• Calling internal service such as workflows
• Arbitrary python code
 When added to the test section of the module
descriptor, tests are rolled back by default
 New logging level test for showing test results


OpenERP YAML Syntax

 OpenERP supports specific custom types:
• !record {model: res_model, id: xml_id, context: {…} }
• !python {model: res_model}
• !workflow {model:res_model, action:signal, ref: xml_id}
 And equivalents for all XML supported elements
• !act_window
• !report
• !function
• !menuitem
• !assert
• etc.


Simple YAML Example


Advanced YAML Example


YAML: Scenario Export

 base_module_record can now output YAML as well


YAML: Continuous Integration

 http://test.openobject.com (buildbot) builds each of
our hundreds of YAML tests after each commit


Usability Guidelines

 Several Guidelines sections have been added to the
online documentation (doc.openerp.com)
• Coding Guidelines
• YAML Guidelines
• Usability Book (including guidelines)
 Usability guidelines are very important for 6.0!
 Needed to maintain coherent look and feel
 Help users directly locate what they need, when they
need it, to be efficient “Don't make me think”
 Hide the complexity!


Usability Guidelines

 Integrate within Business Applications
• Note: Groups and Access Rights are per Business Application
(not per module)
 Keep menu structure “lean”, and in logical sequence
 Design Search Views
 Integrate/use the new configuration wizards
• See new res.config and res.config.installer core classes
 Add Dashboard views and real-time Reports
(group_by)


Usability: menu structure

 Most important items / First ones at top
 Reporting is at bottom
 Configuration is hidden (admin only)
 Use short, business-oriented names
 Example:
• Main application
» (Address book)
» … other items ...
» (Billing)
» (Products)
» Reporting
» Configuration


Usability: Search Views

 Filters are on top-left, grouped by context, most important
ones first
 Then search fields, same order as list columns
 Optional collapsed group for “Extended filters”
• Organized by logical context
• Add nested filter to toggle column visibility when useful
 Optional collapsed group for “Group-By”
• Buttons organized by logical context
• Usually: Persons, Document States, Places, Dates


New R&D Processes

 Agile methodology for Product development: SCRUM
 Formal Bug management and Bug handling process
• R&D teams distinct from Support/Maintenance teams
 Strong focus on
• Quality
• Peer Reviews
• Continuous testing
• Continuous improvement


Product Development Process

 Agile SCRUM sprints
 Sprint contents: Product
backlog + Launchpad
 R&D Teams:
• Web, GTK, Framework
• Addons1, Addons2, Addons3
 All code reviewed by team leaders before end-of-
sprint and merge into trunk


Bug Management Process


Bug Management Process

Unqualified Assigned


Continuous Integration


Web Add-ons

 Web client was overhauled for v6.0:
design and technology
 Web client may now have add-ons
 Web Add-ons are embedded in regular
modules
 Web Add-ons may alter the default web
client in the following areas:
• Controllers
• Templates
• Widgets


Web Add-ons: structure

 Embedded within web directory inside module
 Easy deployment
 Inspired by server-side modules, but simplified
 __openerp__.py
• name and dependencies, you may add
your own metadata
 __init__.py
• Python package, ensure that everything
that needs to be loaded within web
client is imported


Web-Addons: Controllers

 Inherit from either:
• openobject.controllers.BaseController
• openerp.controllers.SecuredController
(for logged-in controllers)
 CherryPy exposition of methods, @expose shortcut
 _cp_path to define the controller’s root
 Can Python-inherit from existing controller object to
extend
 Set same _cp_path to override existing controller


Web Add-on: Controller Example


Web Add-on: Templates Extension

 Web client uses Mako-based templates
 Add-ons can register editor objects to do text
manipulation of the “raw” mako code
 Example:


Web Add-on: Example

 See the pad module for an example


HTML in views

 Apart from web add-ons, <html> may now be
embedded in XML views
 Supported by web client
only
 See html_view module
for an example

Example:


Other Improvements

 Simpler __openerp__ structure: data, demo, test
 API:
• _defaults may be literal
• _constraints, _sql_constraints may be callables
 Security:
• safe_eval replaced built-in eval
• Private _methods() not callable via RPC
 Translations: improved and synchronized with LP
 Reporting engine more modular (e.g report_webkit)
 Performance improvements in RML reports
• <blockTable rowHeights="2cm" colWidths="11.0,7.0">
• Smarter translations, cached


Other Improvements

 Actions have new properties:
• help="Business description for this action"
• multi=True
 Simpler XML declaration for wizards actions
 res.roles => res.groups
 No more roles by default in workflows
 base_report_designer includes OOo plugin

 For more info, see:
• Updated Technical Memento (Partner Preview available)
• Technical Presentation Webinar
• Online Documentation


Development Tips

 Improved views in Admin menus, with XML IDs
 'View logs' shows XML ID now
 Debugging tooltips in GTK and Web
 new logging levels: test, debug_rpc,
debug_rpc_answer, debug_sql
 command-line instance creation: -d dbname -i base
 Test reports
 ./openerp-server.py -i sale -d mytestdb
--test-report-directory=/tmp


This document is published under the Creative Commons Attribution
License 3.0 Unported by OpenERP SA. Feel free to copy, share, or modify it.
For reference please see http://creativecommons.org/licenses/by/3.0/


OpenERP V6 Technical Improvements

More Related Content

Viewers also liked

Viewers also liked (13)

Similar to OpenERP V6 Technical Improvements

Similar to OpenERP V6 Technical Improvements (9)

More from Odoo

More from Odoo (20)

OpenERP V6 Technical Improvements

Editor's Notes