View architecture¶

Generic view¶

The architecture of a view is defined by XML data interpreted by the JavaScript framework.

For each view, there is a *.rng file defining the attributes and possible architectures.

Note

The current context and user access rights may also impact the view abilities.

Python expression¶

When evaluating node attributes, e.g. the readonly modifier, it is possible to provide a Python expression that will be executed in an environment that has access to the following variables:

The names of all fields present in the current view, containing the value of the current record, except for column_invisible in list view; relational fields are given as a list of IDs;
parent: the record that refers to the container; only inside sub-views of relational fields;
context (dict): the current view’s context;
uid (integer): the id of the current user;
today (string): the current local date in the YYYY-MM-DD format;
now (string): the current local datetime in the YYYY-MM-DD hh:mm:ss format.

Example

<field name="field_a" readonly="True"/>
<field name="field_b" invisible="context.get('show_me') and field_a == 4"/>

Example

<field name="field_a"/>
<field name="x2m">
    <!-- sub-view -->
    <form>
        <field name="field_b" invisible="parent.field_a"/>
    </form>
</field>

Form¶

Form views are used to display the data from a single record. Their root element is <form>. They are composed of regular HTML with additional structural and semantic components.

<form>
  ...
</form>

Optional attributes are added on root element <form> to customize the view.

string

string (default: '')

This view title is displayed only if you open an action that has no name and whose target is ‘new’ (opening a dialog)

create

boolean (default: True)

Disable/enable record creation on the view.

edit

boolean (default: True)

Disable/enable record editing on the view.

duplicate

boolean (default: True)

Disable/enable record duplication on the view through the Action dropdown.

delete

boolean (default: True)

Disable/enable record deletion on the view through the Action dropdown.

js_class

string (optional)

Name of the javascript component the webclient will instantiating instead of the form the view.

disable_autofocus

boolean (default: False)

Disable automatic focussing of the first field in the view.

Semantic components¶

Semantic components tie into the Odoo system and allow interaction with it. remark: (with the remark style) Placeholders are denoted in all caps.

<field>: render formatted values¶

<form>
  <field name="FIELD_NAME"/>
</form>

renders (and allow editing of, possibly) a single field of the current record. Using several times a field in a form view is supported and the fields can receive different values for modifiers ‘invisible’ and ‘readonly’. This fields have the same values but can be display differentaly. However, the behavior is not guaranteed when several fields exist with different values for modifier ‘required’. <field> can have the following attributes:

name

string (mandatory) model field name

the name of the field to render

string

string (default: string value from Field)

the label to display. By default display the field’s label coming from the field definition in the model.

id

string (optional)

the node id. Useful when there are several occurrences of the same field in the view (see label component below). Default is the field name.

widget

string (optional)

fields have a default rendering based on their type (e.g. Char, Many2one).

The widget attributes allows using a different rendering method and context. See more information in Fields

<field name="tag_ids" widget="many2many_tags"/>

options

python expression that evaluates to a dict (default: {})

JSON object specifying configuration option for the field’s widget (including default widgets)

<field name="tag_ids" widget="many2many_tags" options="{'color_field': 'FIELD_NAME', 'no_quick_create': True}"/>

groups

Comma-separated values (optional) whose choices are the Groups reference

only displays the field for specific users

<field name="fname" groups="base.group_no_one,!base.group_multi_company"/>

domain

python expression that evaluates to a Search domains (default: [])

for relational fields only, filters to apply when displaying existing records for selection

<field name="fname_id" domain="[('fname_a', '=', parent.fname_b)]"/>

context

python expression that evaluates to a dict (default: {})

for relational fields only, context to pass when fetching possible values. The default values default_FIELD_NAME (e.g. {'default_name': 'toto'}) will be used to create the linked record. OTHER_BUSINESS_KEY is every keys depending of the model/module.

<field name="fname" context="{
    'TYPE_view_ref': 'ADDON.MODEL_view_TYPE',
    'group_by': 'FIELD_NAME',
    'default_FIELD_NAME': ANY,
    'search_default_FIELD_NAME': True,
    'OTHER_BUSINESS_KEY': ANY,
  }"/>

readonly

python expression that evaluates to a boolean (default: False)

Whether the field can be modified by the user (False) or is read only (True).

<field name="fname_a" readonly="True"/>
<field name="fname_b" readonly="name_a in [fname_b, parent.fname_d]"/>

required

python expression that evaluates to a boolean (default: False)

Whether the field can be left empty (False) or must be set (True).

<field name="fname_a" required="True"/>
<field name="fname_b" required="fname_c != 3 and fname_a == parent.fname_d"/>

invisible

python expression that evaluates to a boolean (default: False)

Whether the field can be visible (False) or must be hide (True).

There are two uses for field invisible attribute:

Usability: not to overload the view and to make it easier for the user to read depending on the content;
Technical: fetched by the webclient for evaluating python expression

<field name="fname_a" invisible="True"/> <!-- necessary to evaluate invisible attribute of 'fname_b' field -->
<field name="fname_b" invisible="fname_c != 3 and fname_a == parent.fname_d"/>
<field name="fname_c"/>

nolabel

boolean (default: False)

if True, do not automatically display the field’s label, only makes sense if the field is a direct child of a group element

placeholder

string (optional)

help message to display in empty fields. Can replace field labels in complex forms. Should not be an example of data as users are liable to confuse placeholder text with filled fields

mode

Comma-separated values (default: tree) whose choices are: kanban, from, tree

for One2many, display mode (view type) to use for the field’s linked records. One of tree, form, kanban or graph. The default is tree (a list display)

help

string (optional)

tooltip displayed for users when hovering the field or its label

class

string (optional) HTML class

HTML class to set on the generated element.

The styling use the Bootstrap framework and UI icons.

Below are the common Odoo classes:

oe_inline: prevent the usual line break following fields and limit their span.

oe_left, oe_right: floats the field to the corresponding direction

oe_read_only, oe_edit_only: only displays the field in the corresponding form mode

oe_avatar: for image fields, displays images as “avatar” (square, 90x90 maximum size, some image decorations)

filename

string (optional)

for binary fields, name of the related field providing the name of the file

password

boolean (default: False)

if is True indicates that a Char field stores a password and that its data shouldn’t be displayed

kanban_view_ref

string (optional) defined by the pattern: %(ADDON.MODEL_view_TYPE)s (target the view reference)

for opening specific kanban view when selecting records from m2o/m2m in mobile environment

default_focus

boolean (default: False)

If True, defines that this field is the fields that will be focussed when the view opens. Cannot be present on more than one field of a view.

Note

Relational fields node can contain specific subviews.

<field name="children_ids">
  <tree>
    <field name="name"/>
  </tree>
  <form>
    <field name="id"/>
    <field name="name"/>
  </form>
</field>

<label>: displays other field label¶

<form>
  <div class="col col-md-auto">
    <label for="FIELD_NAME" string="LABEL"/>
    <div>
      <field name="FIELD_NAME" class="oe_inline"/>
    </div>
  </div>
</form>

when a field component isn’t placed directly inside a group, or when its nolabel attribute is set, the field’s label isn’t automatically displayed alongside its value. The <label> component is the manual alternative of displaying the label of a field. <label> can have the following attributes:

for

string (mandatory)

the reference to the field associated with the label. Can be either the name of a field, or its id (id attribute set on the field). When there are several occurrences of the same field in the view, and there are several label components associated with these field nodes, those labels must have unique for attributes (in this case referencing the id attribute of the corresponding field nodes).

string

string (default: '')

the label to display. Display the field’s label (coming from the field definition in the model) by default.

class

string HTML class (default: '')

same as for field component.

invisible

python expression (default: False)

same as for field component.

<button>: displays button to call action¶

<form>
  <button type="object" name="ACTION" string="LABEL"/>
  <button type="object" name="ACTION" icon="FONT_AWESOME"/>
</form>

<button> can have the following attributes:

icon

string (optional)

icon to use to display the button (UI icons)

<button type="object" name="remove" icon="fa-trash"/>

string

string (default: '')

if there is no icon, the button’s text
if there is an icon, alt text for the icon

<button type="object" name="action_create_new" string="Create document"/>

help

string (optional)

add a tooltip message when hover with the mouse cursor

<button type="object" name="remove" icon="fa-trash" help="Revoke"/>

context

python expression that evaluates to a dict (default: {})

merged into the view’s context when performing the button’s Odoo call

<button name="button_confirm" type="object" context="{'BUSINESS_KEY': ANY}" string="LABEL"/>

type

string chooses from object or action (mandatory)

type of button, indicates how it clicking it affects Odoo:

object: call a method on the list’s model. The button’s name is the method, which is called with the current row’s record id and the current context.
action: load an execute an ir.actions, the button’s name is the database id of the action. The context is expanded with the list’s model (as active_model), the current row’s record (active_id) and all the records currently loaded in the list (active_ids, may be just a subset of the database records matching the current search)

<button type="object" name="action_create_new" string="Create document"/>
<button type="action" name="%(addon.action_create_view)d" string="Create and Edit"/>

name

string (optional)

see type

groups

Comma-separated values (optional) whose choices are the Groups reference

same as for form field component.

invisible

python expression that evaluates to a boolean (default: False)

same as for form field component.

class

string (optional) HTML class

see class attribute from form field component.

In form view, in addition to the classic behavior, the special class oe_stat_button define a particular rendering in order to dynamically display information while being clickable to target an action.

<button type="object" name="ACTION" class="oe_stat_button" icon="FONT_AWESOME" help="HELP">
  <div class="o_field_widget o_stat_info">
    <span class="o_stat_value"><FIELD/></span>
    <span class="o_stat_text">TEXT</span>
  </div>
</button>

special

string (optional) chooses from save or cancel

for form views opened in dialogs: save to save the record and close the dialog, cancel to close the dialog without saving.

<button special="cancel" icon="fa-trash"/>

confirm

string (optional)

confirmation message to display (and for the user to accept) before performing the button’s Odoo call (also works in Kanban views).

<button name="action_destroye_gate" string="Send the goa'uld" type="object" confirm="Do you confirm the action?"/>

data-hotkey

string (optional) only one char or shift+ + one char

Define a hotkey (keyboard_shortcut similar to an accesskey) enable when alt keypress to facilitate access to the action.

<button type="object" name="action_tear" string="Tear the sheet" data-hotkey="shift+k"/>

invisible

python expression (default: False)

same as for field component.

Messaging features¶

Chatter is the communication and log tool located on most records. It allows you to email colleagues and customers directly from a record (task, order, invoice, event, note…).

The element must be a div with classname oe_chatter.

The widget is linked to specific python code of this Messaging features.

<form>
  <sheet>
    ...
  </sheet>
  <div class="oe_chatter">
    <field name="message_follower_ids"/>
    <field name="activity_ids"/>
    <field name="message_ids" options="OPTIONS"/>
  </div>
</form>

Attachment/Document preview¶

The element must be an empty div with classname o_attachment_preview.

<form>
  <sheet>
    ...
  </sheet>
  <div class="o_attachment_preview"/>
<form>

Structural components¶

Structural components provide structure or “visual” features with little logic. They are used as elements or sets of elements in form views. Placeholders are denoted in all caps.

<group>: Columns layout¶

<form>
  <group>
    ...
  </group>
</form>

Used to define column layouts in forms. By default, groups define 2 columns and most direct children of groups take a single column. <field> direct children of groups display a label by default, and the label and the field itself have a colspan of 1 each.

Children are laid out horizontally (tries to fill the next column before changing row).

<group> can have the following attributes:

col

integer (default: 2)

number of columns in a <group>

colspan

integer (default: 1)

number of columns taken by an element

string

string (default: '')

displayed a group’s title

invisible

python expression (default: False)

same as for field component.

Below is a possible structure and the representation of its rendering.

<group>
  <field name="a" string="custom"/>
  <field name="b"/>
</group>
<group string="title 1">
  <group string="title 2">
    <field name="c"/>
    <field name="d"/>
  </group>
  <group>
    <field name="e"/>
    <field name="f"/>
    <field name="g"/>
  </group>
</group>
<group col="12">
  <group colspan="8">
    <field name="h"/>
  </group>
  <group colspan="4">
    <field name="i"/>
  </group>
</group>

<sheet>: Responsive layout¶

<sheet> can be used as a direct child to <form> for a narrower and more responsive form layout (center page, margin…). Usually it contains <group>.

<form>
  <sheet>
    ...
  </sheet>
</form>

<notebook> & <page>: tabbed section¶

<form>
  <notebook>
    <page string="LABEL">
      ...
    </page>
  </notebook>
</form>

notebook defines a tabbed section. Each tab is defined through a page child element.

<page> can have the following attributes:

string

string (default: '')

the title of the tab

invisible

python expression (default: False)

same as for field component.

Can be apply on notebook and page nodes.

Below is a possible structure and the representation of its rendering.

<form>
  <notebook>
    <page string="Page1">
      ...
    </page>
    <page string="Page2">
      ...
    </page>
  </notebook>
</form>

Note

Note that notebook should not be placed within group

<newline>: new row¶

<form>
  <group>
    ...
    <newline/>
    ...
  </group>
</form>

only useful within <group> elements, ends the current row early and immediately switches to a new row (without filling any remaining column beforehand)

Below is a possible structure and the representation of its rendering.

<form>
  <group string="Title 1">
    <group string="Title 1.1">...</group>
    <newline/>
    <group string="Title 1.2">...</group>
    <group string="Title 1.3">...</group>
  </group>
</form>

<separator>: horizontal spacing¶

<form>
  ...
  <separator/>
  ...
</form>

small horizontal spacing. <separator> can have the following attributes:

string

string (default: '')

the title as a section title

Below is a possible structure and the representation of its rendering.

<form>
  <group>
    <FIELD/>
    <separator string="Title 1"/>
    <FIELD/>
    <group>
      <FIELD/>
      <separator string="Title 2"/>
      <FIELD/>
    </group>
    <group>
      <FIELD/>
      <FIELD/>
    </group>
  </group>
</form>

<header>: workflow buttons and status¶

<form>
  <header>
    <BUTTONS/>
  </header>
  <sheet>
    ...
  </sheet>
</form>

combined with <sheet>, provides a full-width location above the sheet itself, generally used to display workflow buttons and a field display as status widget.

Below is an example with the status widget with some options.

<header>
  <button string="Reset" type="object" name="set_draft" invisible="state != 'done'"/>
  <field name="state" widget="statusbar" statusbar_visible="draft,posted" options="{'clickable': 1}"/>
</header>

container for buttons¶

<form>
  <div name="button_box">
    <BUTTONS/>
  </div>
<form>

Container for specific rendering to display buttons

<form>
  <div name="button_box">
    <button type="edit" name="edit"
        icon="fa-edit" string="Button1"/>

    <button type="object" name="my_action"
        icon="fa-dollar">
      <field name="total_inv" widget="statinfo"
          string="Invoices"/>
    </button>
  </div>
  ...
<form>

container for a title¶

<form>
  <sheet>
    <div class="oe_title">
      <h1><FIELD/></h1>
    </div>
  </sheet>
<form>

Container for specific rendering to display a <field> as title.

Settings Form View¶

The settings form view is a customization of the form view. It’s used to centralize all the settings of Odoo.

This view differs from a generic form view because it has a search bar, a sidebar and accepts 3 additional tags: app, block and setting.

Example

<app string="CRM" name="crm">
    <setting type="header" string="Foo">
        <field name="foo" title="Foo?."/>
        <button name="nameAction" type="object" string="Button"/>
    </setting>
    <block title="Title of group Bar">
        <setting help="this is bar" documentation="/applications/technical/web/settings/this_is_a_test.html">
            <field name="bar"/>
        </setting>
        <setting string="This is Big BAR" company_specific="1">
            <field name="bar"/>
        </setting>
    </block>
    <block title="Title of group Foo">
        <setting string="Personalize setting" help="this is full personalize setting">
            <div>This is a different setting</div>
        </setting>
    </block>
</app>

<app>: declare the application¶

<form>
  <app string="NAME" name="TECHNICAL_NAME">
  ...
  </app>
</form>

The app tag is used to declare the application on the settings view. It creates an entry with its logo on the sidebar of the view. It also acts as delimiter when searching. <app> can have the following attributes:

string

string (mandatory)

The name of the application.

name

string (mandatory)

The technical name of the application (the name of the module).

logo

path (optional)

The relative path to the logo. If not set, the logo is created using the name parameter : /{name}/static/description/icon.png.

groups

Comma-separated values (optional) whose choices are the Groups reference

same as for field component.

invisible

python expression that evaluates to a boolean (default: False)

same as for field component.

<block>: declare a group of settings¶

<form>
  <app string="NAME" name="TECHNICAL_NAME">
    ...
    <block title="TITLE">
      ...
    </block>
    ...
  </app>
</form>

The block tag is used to declare a group of settings. This group can have a title and a description/help. <block> can have the following attributes:

title

string (optional)

The title of the block of settings, you can perform research on its text.

help

string (optional)

The description/help of the block of settings, you can perform research on its text.

groups

Comma-separated values (optional) whose choices are the Groups reference

same as for field component.

invisible

python expression that evaluates to a boolean (default: False)

same as for field component.

<setting>: declare the setting¶

<form>
  <app string="NAME" name="TECHNICAL_NAME">
    <block title="TITLE">
      ...
      <setting string="SETTING_NAME">
        ...
        <field name="FIELD_NAME"/>
        ...
      </setting>
      ...
    </block>
  </app>
</form>

The setting tag is used to declare the setting itself. The first field in the setting is used as the main field (optional). This field is placed on the left panel (if it’s a boolean field) or on the top of the right panel (otherwise). The field is also used to create the setting label if a string is not defined. The setting tag can also contain more elements (e.g. html), all of these elements are rendered in the right panel. <setting> can have the following attributes:

type

string (optional)

By default, a setting is visually separated on two panels (left and right), and is used to edit a given field. By defining type='header', a special kind of setting is rendered instead. This setting is used to modify the scope of the other settings. For example, on the website application, this setting is used to indicate to which website the other settings apply. The header setting is visually represented as a yellow banner on the top of the screen.

string

string (optional)

The text used as label of the setting. If it’s not defined, the first field is used as label.

title

string (optional)

The text used as tooltip.

help

string (optional)

The help/description of the setting. This text is displayed just below the setting label (with classname text-muted).

company_dependent

1 (optional)

If this attribute is set to “1” an icon is displayed next to the setting label to explicit that this setting is company-specific.

documentation

path (optional)

If this attribute is set, an icon is added next to the setting label, this icon is a link to the documentation. Note that you can use relative or absolute path. The relative path is relative to https://www.odoo.com/documentation/<server_version>, so it’s not necessary to hard-code the server version on the arch anymore.

groups

Comma-separated values (optional) whose choices are the Groups reference

same as for field component.

invisible

python expression that evaluates to a boolean (default: False)

same as for field component.

List¶

<tree>
  ...
</tree>

The root element of list views is <tree>1. The list view’s root can have the following attributes:

sample

boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

These fake records will have heuristics for certain field names/models. For example, a field ‘display_name’ on the model ‘res.users’ will be populated with sample people names while an ‘email’ field will be in the form ‘firstname.lastname@sample.demo’.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route

path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:

<tree banner_route="/module_name/hello" />

class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

string

string (default: '')

This view title is displayed only if you open an action that has no name and whose target is ‘new’ (opening a dialog)

create

boolean (default: True)

Disable/enable record creation on the view.

edit

boolean (default: True)

Disable/enable record editing on the view.

If the edit attribute is set to false, the editable option will be ignored.

delete

boolean (default: True)

Disable/enable record deletion on the view through the Action dropdown.

import

boolean (default: True)

Disable/enable record import data on the view.

export_xlsx

boolean (default: True)

Disable/enable record export data on the view.

editable

string (optional) chooses from top or bottom

by default, selecting a list view’s row opens the corresponding form view. The editable attributes makes the list view itself editable in-place.

Valid values are top and bottom, making new records appear respectively at the top or bottom of the list.

The architecture for the inline form view is derived from the list view. Most attributes valid on a form view’s fields and buttons are thus accepted by list views although they may not have any meaning if the list view is non-editable.

If the edit attribute is set to false, the editable option will be ignored.

multi_edit

1 (optional)

editable or not editable list can activate the multi-editing feature that allows to change the same field to the same value for multiple records in a single operation by defining the multi_edit="1"

default_group_by

string (optional) model field name

whether the list view should be grouped if no grouping is specified via the action or the current search. Should be the name of the field to group by when no grouping is otherwise specified

default_order

Comma-separated values (optional)

overrides the ordering of the model, replacing the model’s order (_order model attribute). The value is a comma-separated list of fields, postfixed by desc to sort in reverse order:

<tree default_order="sequence,name desc">
  ...
</tree>

decoration-bf

decoration-it

decoration-danger

decoration-warning

decoration-info

decoration-muted

decoration-primary

decoration-success

python expression that evaluates to a boolean (default: False)

allow changing the style of a cell’s text based on the corresponding record’s attributes:

bf for font-weight: bold
it for font-style: italic
danger, info, muted, primary, success or warning add relative bootstrap contextual color.

Define a conditional display of a record in the style of a row’s text based on the corresponding record’s attributes. For each record, the expression is evaluated with the record’s attributes as context values and if true, the corresponding style is applied to the row.

<tree decoration-danger="field_qty > field_limit">
  ...
</tree>

limit

integer (default: 80 for list view and 40 for x2many list in form view)

the default size of a page. It must be a positive integer

groups_limit

integer (default: 80 for list view and 40 for x2many list in form view)

when the list view is grouped, the default number of groups of a page. It must be a position integer

expand

boolean (default: False)

when the list view is grouped, automatically open the first level of groups if set to true. (Warning: It may be slow depending on the number of groups)

open_form_view

boolean (default: False)

display a button at the end of each records to open the record in a form view. Only useful when the view is editable.

Possible children elements of the list view are: button, field, groupby, header or control

<field>: render formatted values¶

<tree>
  <field name="FIELD_NAME"/>
</tree>

defines a column where the corresponding field should be displayed for each record. Can use the following attributes:

name

string (mandatory) model field name

the name of the field to display in the current model. A given name can only be used once per view

string

string (optional)

the title of the field’s column (by default, uses the string of the model’s field)

optional

string (optional) chooses from hide or show

if set, the visibility of the field is optional. The display can be chosen via a button in the list view. By default fields will be visible if the value is show or not visible if hide.

<field name="fname_a" optional="hide"/>

readonly

python expression that evaluates to a boolean (default: False)

standard dynamic attributes based on record values. If the value is truthy or if the evaluate expression is truthy, display the field in both readonly and edit mode, but never make it editable.

<field name="fname_a" readonly="True"/>
<field name="fname_b" readonly="name_a in [fname_b, parent.fname_d]"/>

required

python expression that evaluates to a boolean (default: False)

standard dynamic attributes based on record values. If the value is truthy or if the evaluate expression is truthy, generates an error and prevents saving the record if the field doesn’t have a value.

<field name="fname_a" required="True"/>
<field name="fname_b" required="fname_c != 3 and fname_a == parent.fname_d"/>

invisible

python expression that evaluates to a boolean (default: False)

standard dynamic attributes based on record values. Hide the field if truthy or if the evaluate expression is truthy.

Fetches and stores the field, but doesn’t display the column in the table. Necessary for fields which shouldn’t be displayed but are used by e.g. @colors or an expression.

<field name="fname_a" invisible="True"/>
<field name="fname_b" invisible="fname_c != 3 and fname_a == parent.fname_d"/>

column_invisible

python expression that evaluates to a boolean (default: False)

Fetches and stores the field, but doesn’t display the column in the table. Necessary for fields which shouldn’t be displayed but are used by e.g. @colors or an expression.

Unlike invisible, if the evaluate expression is truly the entire column invisible and is evaluate without the subtree values.

<field name="product_is_late" column_invisible="parent.has_late_products == False"/>

Note

Only in case of list sub-views (One2many/Many2many display in a form view).

groups

Comma-separated values (optional) whose choices are the Groups reference

lists the groups which should be able to see the field (removed server side if the user’s groups do not match)

<field name="fname" groups="base.group_no_one,!base.group_multi_company"/>

decoration-bf

decoration-it

decoration-danger

decoration-warning

decoration-info

decoration-muted

decoration-primary

decoration-success

python expression that evaluates to a boolean (default: False)

allow changing the style of a cell’s text based on the corresponding record’s attributes:

bf for font-weight: bold
it for font-style: italic
danger, info, muted, primary, success or warning add relative bootstrap contextual color.

Define a conditional display of a record in the style of a row’s text based on the corresponding record’s attributes.

Values are Python expressions. For each record, the expression is evaluated with the record’s attributes as context values and if true, the corresponding style is applied to the row. Here are some of the other values available in the context:

uid: the id of the current user,
today: the current local date as a string of the form YYYY-MM-DD,
now: same as today with the addition of the current time. This value is formatted as YYYY-MM-DD hh:mm:ss.

<tree decoration-info="state == 'draft'"
      decoration-danger="state == 'help_needed'"
      decoration-bf="state == 'busy'">
  ...
</tree>

widget

string (optional) chooses from handle or progressbar

alternate representations for a field’s display. Possible list view values are (among others):

handle: for sequence (or integer) fields by which records are sorted, instead of displaying the field’s value just displays a drag&drop icon to reorder records.
progressbar: displays float fields as a progress bar.

See more information in Fields

<tree>
    <field name="sequence" widget="handle"/>
    <field name="level_progress" widget="progressbar"/>
</tree>

sum, avg

string (optional)

displays the corresponding aggregate at the bottom of the column. The aggregation is only computed on currently displayed records. The aggregation operation must match the corresponding field’s group_operator

<tree>
  <field name="sent" sum="Total" />
  <field name="clicks_ratio" avg="Average"/>
</tree>

width

string/integer (for editable) (optional)

when there is no data in the list, the width of a column can be forced by setting this attribute. The value can be an absolute width (e.g. ‘100px’). Note that when there are records in the list, we let the browser automatically adapt the column’s widths according to their content, and this attribute is thus ignored.

nolabel

1 (optional)

if set to “1”, the column header will remain empty. Also, the column won’t be sortable.

Note

if the list view is editable, any field attribute from the form view is also valid and will be used when setting up the inline form view.

Note

When a list view is grouped, numeric fields are aggregated and displayed for each group. Also, if there are too many records in a group, a pager will appear on the right of the group row. For this reason, it is not a good practice to have a numeric field in the last column, when the list view is in a situation where it can be grouped (it is however fine for x2manys field in a form view: they cannot be grouped).

Below is a possible structure and the representation of its rendering.

<tree>
  <field name="name" string="My Custom Name"/>
  <field name="amount" sum="Total"/>
  <field name="company_id" invisible="1"/>
  <field name="currency_id"/>
  <field name="tax_id"/>
</tree>

<button>: display button to call action¶

<tree>
  <button type="object" name="ACTION" string="LABEL"/>
  <button type="object" name="ACTION" icon="FONT_AWESOME"/>
</tree>

<button> can have the following attributes:

icon

string (optional)

icon to use to display the button (UI icons)

<button type="object" name="remove" icon="fa-trash"/>

string

string (default: '')

if there is no icon, the button’s text
if there is an icon, alt text for the icon

<button type="object" name="action_create_new" string="Create document"/>

help

string (optional)

add a tooltip message when hover with the mouse cursor

<button type="object" name="remove" icon="fa-trash" help="Revoke"/>

context

python expression that evaluates to a dict (default: {})

merged into the view’s context when performing the button’s Odoo call

<button name="button_confirm" type="object" context="{'BUSINESS_KEY': ANY}" string="LABEL"/>

type

string chooses from object or action (mandatory)

type of button, indicates how it clicking it affects Odoo:

object: call a method on the list’s model. The button’s name is the method, which is called with the current row’s record id and the current context.
action: load an execute an ir.actions, the button’s name is the database id of the action. The context is expanded with the list’s model (as active_model), the current row’s record (active_id) and all the records currently loaded in the list (active_ids, may be just a subset of the database records matching the current search)

<button type="object" name="action_create_new" string="Create document"/>
<button type="action" name="%(addon.action_create_view)d" string="Create and Edit"/>

name

string (optional)

see type

groups

Comma-separated values (optional) whose choices are the Groups reference

same as for form field component.

invisible

python expression that evaluates to a boolean (default: False)

same as for form field component.

class

string (optional) HTML class

same as for form field component.

column_invisible

python expression that evaluates to a boolean (default: False)

same as for list field component.

Below is a possible structure and the representation of its rendering.

<tree>
  <field name="name"/>
  <button
      type="edit" name="edit"
      icon="fa-edit" title="Edit"/>
  <button
      type="object" name="my_method"
      string="Button1"
      column_invisible="context.get('hide_button')"
      invisible="amount &gt; 3"/>
  <field name="amount"/>
  <field name="currency_id"/>
  <field name="tax_id"/>
</tree>

<groupby>: custom headers when grouping¶

<tree>
  ...
  <groupby name="FIELD_NAME">
    <BUTTONS/>
    <FIELDS/>
  </groupby>
</tree>

defines custom headers (with buttons) for the current view when grouping records on many2one fields. It is also possible to add field, inside the groupby which can be used for modifiers. These fields thus belong on the many2one comodel. These extra fields will be fetched in batch.

name

string (mandatory) model field name

the name of a many2one field (on the current model). Custom header will be displayed when grouping the view on this field name.

A special button (type="edit") can be defined to open the many2one form view.

Below is a possible structure and the representation of its rendering when group the record by the selected.

<tree>
  <field name="name"/>
  <field name="amount"/>
  <field name="currency"/>
  <field name="tax_id"/>

  <groupby name="partner_id">
    <button
        type="edit" name="edit"
        icon="fa-edit" title="Edit"/>

    <field name="email"/>
    <button
        type="object" name="my_method"
        string="Button1"
        invisible="email == 'jhon@conor.com'"/>
  </groupby>
</tree>

Note

The fields inside <groupby> are only used to fetches and stores the value but are never displayed.

<header>: custom buttons in control panel¶

<tree>
  <header>
    <BUTTONS/>
  </header>
  ...
</tree>

<button>

Defines custom buttons similar to list view buttons in the control panel that perform an action/call a model’s method. The buttons which accepts an extra attribute when placed in a header:

display

string chooses from display or always (default: display)

By default, those buttons are only displayed when some records are selected, and they apply on the selection. When the attribute display is set to always, the button is available all the time, even if there’s no selection.

<header>
    <button name="toDoAlways" type="object" string="Always displayed" display="always"/>
    <button name="toDoSelection" type="object" string="Displayed if selection"/>
</header>

Below is a possible structure and the representation of its rendering.

<tree>
  <header>
    <button type="object" name="to_draft"
        string="Button1"
        invisible="context.get('hide_button')"/>
  </header>
  <field name="name"/>
  <field name="amount"/>
  <field name="currency"/>
  <field name="tax_id"/>
</tree>

<control> & <create>: customize “add a line”¶

<tree>
  <control>
    <create string="LABEL"/>
    <BUTTONS/>
  </control>
  ...
</tree>

defines custom controls for the current view. Does not support any attribute, but can have children <create>.

<create> adds a button to create a new element on the current list. It can have the following attributes:

string

string (mandatory)

The text displayed on the button.

context

python expression that evaluates to a dict (default: {})

This context will be merged into the existing context when retrieving the default value of the new record.

For example it can be used to override default values.

Below is a possible structure and the representation of its rendering.

<tree>
  <field name="name"/>
  <field name="amount"/>
  <field name="currency"/>
  <field name="tax_id"/>
  <control>
    <create string="Add a item"/>
    <create string="Add a section"
        context="{'default_type': 'section'}"/>
    <create string="Add a note"
        context="{'default_type': 'note'}"/>
  </control>
</tree>

Note

<control> makes sense if the parent tree view is inside a One2many relational field.

If any <create> is defined as children, it will overwrite the default “add a line” button.

1: for historical reasons, it has its origin in tree-type views later repurposed to a more table/list-type display

Search¶

<search>
  ...
</search>

Search views are different from other view types: they don’t display content. Although they apply to a specific model, they are used to filter another view’s content (generally aggregated views e.g. List or Graph).

The root element of search views is <search>. It takes no attributes.

Possible children elements of the list view are: field, filter, separator, group or searchpanel

<field>: field usable as filter¶

<search>
  <field name="FIELD_NAME"/>
</search>

fields define domains or contexts with user-provided values. When search domains are generated, field domains are joined with each other and with filters using the AND operator.

Fields can have the following attributes:

name

string (mandatory) model field name (mandatory)

the name of the field to filter on

string

string (optional)

the field’s label

operator

string (default: =)

by default, fields generate domains of the form [(name, operator, provided_value)] where name is the field’s name and provided_value is the value provided by the user, possibly filtered or transformed (e.g. a user is expected to provide the label of a selection field’s value, not the value itself).

The operator attribute allows overriding the default operator, which depends on the field’s type (e.g. = for float fields but ilike for char fields or child_of for many2one)

filter_domain

python expression that evaluates to a Search domains (default: False)

complete domain to use as the field’s search domain, can use a self variable to inject the provided value in the custom domain. Can be used to generate significantly more flexible domains than operator alone (e.g. searches on multiple fields at once)

If both operator and filter_domain are provided, filter_domain takes precedence.

context

python expression that evaluates to a dict (default: {})

allows adding context keys, including the user-provided values (which as for domain are available as a self variable, an array of values e.g. [id_1, id_2] for a Many2one field). By default, fields don’t generate domains.

Note

the domain and context are inclusive and both are generated if a context is specified. To only generate context values, set filter_domain to an empty list: filter_domain="[]"

domain

python expression that evaluates to a Search domains (default: False)

if the field can provide an auto-completion (e.g. Many2one), filters the possible completion results.

groups

Comma-separated values (optional) whose choices are the Groups reference

make the field only available to specific users

invisible

python expression that evaluates to a boolean (default: False)

standard dynamic attributes based on record values. Hide the field if truthy or if the evaluate expression is truthy.

<field name="fname_a" invisible="True"/>
<field name="fname_b" invisible="fname_c != 3 and fname_a == parent.fname_d"/>

Below is a possible structure and the representation of its rendering.

<search>
  <field name="name" string="My Custom Name"/>
  <field name="amount"/>
  <field name="company_id" invisible="1"/>
  <field name="currency_id"/>
  <field name="ref" filter_domain="[('name', 'like', self)]"/>
</search>

<filter>: predefined Filters¶

<search>
  <filter string="LABEL" domain="DOMAIN"/>
</search>

a filter is a predefined toggle in the search view, it can only be enabled or disabled. Its main purposes are to add data to the search context (the context passed to the data view for searching/filtering), or to append new sections to the search filter.

Filters can have the following attributes:

string

string (mandatory)

the label of the filter

domain

python expression that evaluates to a Search domains (default: False)

will be appended to the action’s domain as part of the search domain.

date

string (optional) model field name

the name of a field of type date or datetime. Using this attribute has the effect to create a set of filters available in a submenu of the filters menu. The filters proposed are time dependent but not dynamic in the sense that their domains are evaluated at the time of the control panel instantiation.

Example:

<filter name="filter_create_date" date="create_date" string="Creation Date"/>

The example above allows to easily search for records with creation date field values in one of the periods below (if the current month is August 2019).

Create Date >
  August
  July
  June
  Q4
  Q3
  Q2
  Q1
--------------
  2019
  2018
  2017

Multi selection of options is allowed.

default_period

string (optional) chooses from today, this_week, this_month, last_month, antepenultimate_month, fourth_quarter, third_quarter, second_quarter, first_quarter, this_year, last_year or antepenultimate_year

only makes sense for a filter with non empty date attribute. determines which periods are activated if the filter is in the default set of filters activated at the view initialization. If not provided, ‘this_month’ is used by default.

The attribute accepts comma separated values.

Examples:

<filter name="filter_create_date" date="create_date" string="Creation Date" default_period="this_week"/>
<filter name="filter_create_date" date="create_date" string="Creation Date" default_period="this_year,last_year"/>

context

python expression that evaluates to a dict (default: {})

a Python dictionary, merged into the action’s domain to generate the search domain

The key group_by can be used to define a groupby available in the ‘Group By’ menu. The ‘group_by’ value can be a valid field name.

<filter name="groupby_category" string="Category" context="{'group_by': 'category_id'}"/>

The groupby defined above allows to group data by category.

When the field is of type date or datetime, the filter generates a submenu of the Group By menu in which the following interval options are available: day, week, month, quarter, year.

In case the filter is in the default set of filters activated at the view initialization, the records are grouped by month by default. This can be changed by using the syntax ‘date_field:interval’ as in the following example.

Example:

<filter name="groupby_create_date" string="Creation Date" context="{'group_by': 'create_date:week'}"/>

Note

The results of read_groups grouped on a field may be influenced by its group_expand attribute, allowing to display empty groups when needed. For more information, please refer to Field attributes documentation.

name

string (optional)

logical name for the filter, can be used to enable it by default, can also be used as inheritance hook

help

string (optional)

a longer explanatory text for the filter, may be displayed as a tooltip

groups

Comma-separated values (optional) whose choices are the Groups reference

make the field only available to specific users

invisible

python expression that evaluates to a boolean (default: False)

standard dynamic attributes based on record values. Hide the field if truthy or if the evaluate expression is truthy.

<field name="fname_a" invisible="True"/>
<field name="fname_b" invisible="fname_c != 3 and fname_a == parent.fname_d"/>

Note

Sequences of filters (without non-filters separating them) are treated as inclusively composited: they will be composed with OR rather than the usual AND, e.g.

<filter domain="[('state', '=', 'draft')]"/>
<filter domain="[('state', '=', 'done')]"/>

if both filters are selected, will select the records whose state is draft or done, but

<filter domain="[('state', '=', 'draft')]"/>
<separator/>
<filter domain="[('delay', '&lt;', 15)]"/>

if both filters are selected, will select the records whose state is draft and delay is below 15.

Note

XML does not allow < to be used within XML elements, an entity reference (<) should be used instead.

Below is a possible structure and the representation of its rendering.

<search>
  <filter string="My Custom Name"
      domain="[('name', 'ilike', 'AAA')]"/>
  <filter string="My orders"
      domain="[('user_id', '=', uid)]"/>
  <filter string="Category"
      context="{'group_by': 'category_id'}"/>
</search>

<separator>: separate groups of filters¶

<search>
  <FILTERS/>
  <separator/>
  <FILTERS/>
</search>

can be used to separates groups of filters in simple search views. group is more readable.

<group>: separate groups of filters¶

<search>
  <group expand="0" string="LABEL">
    <FILTERS/>
  </group>
</search>

can be used to separate groups of filters, more readable than separator in complex search views

<searchpanel>: display a search panel¶

<search>
  <searchpanel>
    <FIELDS/>
  </searchpanel>
</search>

allows to display a search panel on the left of any multi records view.

This tool allows to quickly filter data on the basis of given fields. The fields are specified as direct children of the searchpanel with tag name field.

<field>

Fields in searchpanel can have the following attributes:

name

string (mandatory) model field name

the name of the field to filter on

select

string chooses from one or multi (default: one)

determines the behavior and display.

one (default): at most one value can be selected. Supported field types are many2one and selection.
multi: several values can be selected (checkboxes). Supported field types are many2one, many2many and selection.

groups: restricts to specific users
string: determines the label to display
icon: specifies which icon is used
color: determines the icon color

Additional optional attributes are available in the multi case:

enable_counters

default is false. If set to true the record counters will be computed and displayed if non-zero.

This feature has been implemented in case performances would be too bad.

Another way to solve performance issues is to properly override the search_panel_select_range and search_panel_select_multi_range methods.

expand

default is false. If set to false categories or filters with 0 records will be hidden.

limit

default is 200. Integer determining the maximal number of values to fetch for the field. If the limit is reached, no values will be displayed in the search panel and an error message will appear instead because we consider that is useless / bad performance-wise. All values will be fetched if set to 0.

Additional optional attributes are available according to the chosen case:

For the one case:

hierarchize
(only available for many2one fields) default is true. Handles the display style of categories :

If set to true child categories will appear under their related parent. If not, all categories will be displayed on the same level.
For the multi case:

domain:
determines conditions that the comodel records have to satisfy.

A domain might be used to express a dependency on another field (with select=”one”) of the search panel. Consider /!This attribute is incompatible with a select=”one” with enabled counters; if a select=”multi” has a domain attribute, all select=”one” will have their counters disabled.
```
<searchpanel>
  <field name="department_id"/>
  <field name="manager_id" select="multi" domain="[('department_id', '=', department_id)]"/>
</searchpanel>
```
In the above example, the range of values for manager_id (manager names) available at screen will depend on the value currently selected for the field department_id.

groupby

string (optional) model field name

field name of the comodel (only available for many2one and many2many fields). Values will be grouped by that field.

Search defaults¶

Search fields and filters can be configured through the action’s context using search_default_name keys. For fields, the value should be the value to set in the field, for filters it’s a boolean value or a number. For instance, assuming foo is a field and bar is a filter an action context of:

{
  'search_default_foo': 'acro',
  'search_default_bar': 1
}

will automatically enable the bar filter and search the foo field for acro.

A numeric value (between 1 and 99) can be used to describe the order of default groupbys. For instance if foo and bar refer to two groupbys

{
  'search_default_foo': 2,
  'search_default_bar': 1
}

has the effect to activate first bar then foo.

Kanban¶

<kanban>
  ...
</kanban>

The kanban view is a kanban board visualisation: it displays records as “cards”, halfway between a list view and a non-editable form view. Records may be grouped in columns for use in workflow visualisation or manipulation (e.g. tasks or work-progress management), or ungrouped (used simply to visualize records).

Note

The kanban view will load and display a maximum of ten columns. Any column after that will be closed (but can still be opened by the user).

The root element of the Kanban view is <kanban>, it can use the following attributes:

sample

boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route

path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:

<tree banner_route="/module_name/hello" />

class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

string

string (default: '')

This view title is displayed only if you open an action that has no name and whose target is ‘new’ (opening a dialog)

create

boolean (default: True)

Disable/enable record creation on the view.

edit

boolean (default: True)

Disable/enable record editing on the view.

delete

boolean (default: True)

Disable/enable record deletion on the view through the Action dropdown.

default_group_by

string (optional) model field name

whether the kanban view should be grouped if no grouping is specified via the action or the current search. Should be the name of the field to group by when no grouping is otherwise specified

default_order

string (optional)

cards sorting order used if the user has not already sorted the records (via the list view)

class

string (optional) HTML class

adds HTML classes to the root HTML element of the Kanban view

examples

string (optional)

if set to a key in the KanbanExamplesRegistry, examples on column setups will be available in the grouped kanban view. Here is an example of how to define those setups.

group_create

boolean (default: True)

whether the “Add a new column” bar is visible or not.

group_delete

boolean (default: True)

whether groups can be deleted via the context menu.

group_edit

boolean (default: True)

whether groups can be edited via the context menu.

archivable

boolean (default: True)

whether records belonging to a column can be archived / restored if an active field is defined on the model.

quick_create

boolean (default: True)

whether it should be possible to create records without switching to the form view. By default, quick_create is enabled when the Kanban view is grouped by many2one, selection, char or boolean fields, and disabled when not.

quick_create_view

string (optional)

Form view reference, specifying the view used for records quick creation.

records_draggable

boolean (default: True)

whether it should be possible to drag records when kanban is grouped.

Set to true to always enable it, and to false to always disable it.

groups_draggable

boolean (default: True)

whether it should be possible to resequence colunms when kanban is grouped.

Set to true to always enable it, and to false to always disable it.

Possible children elements of the kanban view are: field, progressbar or templates

<field>: render formatted values¶

<kanban>
  <field name="FIELD_NAME"/>
  ...
</kanban>

declares fields to use in kanban logic. If the field is simply displayed in the kanban view, it does not need to be pre-declared.

Fields can use the following attributes:

name

string (mandatory) model field name

the name of the field to fetch

<kanban>
  <templates>
    <t t-name="kanban-box">
      <div>
        <field name="name"/>
      </div>
    </t>
  </templates>
</kanban>

<header>: custom buttons in control panel¶

<kanban>
  <header>
    <BUTTONS/>
  </header>
  ...
</kanban>

<button>

Defines custom buttons similar to list view buttons in the control panel that perform an action/call a model’s method. The buttons which accepts an extra attribute when placed in a header:

display

string chooses from display or always (default: display)

<header>
    <button name="toDoAlways" type="object" string="Always displayed" display="always"/>
    <button name="toDoSelection" type="object" string="Displayed if selection"/>
</header>

Note

Currently, only the always option is usable because it is not yet possible to select records in a kanban view. This should happen soon.

<progressbar>: progressbar on top of columns¶

<kanban>
  <progressbar field="FIELD_NAME"/>
  ...
</kanban>

declares a progressbar element to put on top of kanban columns.

Possible attributes are:

field

string (mandatory) model field name

the name of the field whose values are used to subgroup column’s records in the progressbar

colors

JSON (mandatory)

JSON mapping the above field values to either “danger”, “warning”, “success” or “muted” colors

sum_field

string (optional) model field name

the name of the field whose column’s records’ values will be summed and displayed next to the progressbar (if omitted, displays the total number of records)

<kanban>
  <progressbar field="activity_state"
      colors="{'planned': 'success', 'today': 'warning', 'overdue': 'danger'}"
      sum_field="expected_revenue"/>
  <templates>
    ...
  </templates>
</kanban>

<templates>: template of card¶

<kanban>
  ...
  <templates>
    <t t-name="kanban-box">
      <div>
        <field name="name"/>
      </div>
    </t>
  </templates>
</kanban>

defines a list of QWeb Templates templates. Cards definition may be split into multiple templates for clarity, but kanban views must define at least one root template kanban-box, which will be rendered once for each record.

Two additional templates can be defined: kanban-menu and kanban-tooltip. If defined, the kanban-menu template is rendered inside a dropdown that can be toggled with a vertical ellipsis (⋮) on the top right of the card. The kanban-tooltip template is rendered inside a tooltip when hovering kanban cards.

The kanban view uses mostly-standard javascript qweb and provides the following context variables:

widget

the current KanbanRecord(), can be used to fetch some meta-information. These methods are also available directly in the template context and don’t need to be accessed via widget

record

an object with all the requested fields as its attributes. Each field has two attributes value and raw_value, the former is formatted according to current user parameters, the latter is the direct value from a read() (except for date and datetime fields that are formatted according to user’s locale)

context

the current context, coming from the action, and the one2many or many2many field in the case of a Kanban view embedded in a Form view

user_context

self-explanatory

read_only_mode

self-explanatory

selection_mode

set to true when kanban view is opened in mobile environment from m2o/m2m field for selecting records.

Note

clicking on m2o/m2m field in mobile environment opens kanban view

buttons and fields

While most of the Kanban templates are standard QWeb Templates, the Kanban view processes field, button and a elements specially:

by default fields are replaced by their formatted value, unless the widget attribute is specified, in which case their rendering and behavior depends on the corresponding widget. Possible values are (among others):

handle
for sequence (or integer) fields by which records are sorted, allows to drag&drop records to reorder them.
buttons and links with a type attribute become perform Odoo-related operations rather than their standard HTML function. Possible types are:

action, object
standard behavior for Odoo buttons, most attributes relevant to standard Odoo buttons can be used.

open
opens the card’s record in the form view in read-only mode

edit
opens the card’s record in the form view in editable mode

delete
deletes the card’s record and removes the card

If you need to extend the Kanban view, see KanbanRecord().

QWeb¶

QWeb views are standard QWeb Templates templates inside a view’s arch. They don’t have a specific root element. Because QWeb views don’t have a specific root element, their type must be specified explicitly (it can not be inferred from the root element of the arch field).

QWeb views have two use cases:

they can be used as frontend templates, in which case template should be used as a shortcut.
they can be used as actual qweb views (opened inside an action), in which case they should be defined as regular view with an explicit type (it can not be inferred) and a model.

The main additions of qweb-as-view to the basic qweb-as-template are:

qweb-as-view has a special case for a <nav> element bearing the CSS class o_qweb_cp_buttons: its contents should be buttons and will be extracted and moved to the control panel’s button area, the <nav> itself will be removed, this is a work-around to control panel views not existing yet
qweb-as-view rendering adds several items to the standard qweb rendering context:

model
the model to which the qweb view is bound

domain
the domain provided by the search view

context
the context provided by the search view

records
a lazy proxy to model.search(domain), this can be used if you just want to iterate the records and not perform more complex operations (e.g. grouping)
qweb-as-view also provides additional rendering hooks:
- _qweb_prepare_context(view_id, domain) prepares the rendering context specific to qweb-as-view
- qweb_render_view(view_id, domain) is the method called by the client and will call the context-preparation methods and ultimately env['ir.qweb'].render().

Graph¶

The graph view is used to visualize aggregations over a number of records or record groups. Its root element is <graph> which can take the following attributes:

sample boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

These fake records will have heuristics for certain field names/models. For example, a field ‘display_name’ on the model ‘res.users’ will be populated with sample people names while an ‘email’ field will be in the form ‘firstname.lastname@sample.demo’.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:
<tree banner_route="/module_name/hello" />
class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

type (optional): one of bar (default), pie and line, the type of graph to use
stacked (optional): only used for bar charts. Set to 0 to prevent the bars within a group to be stacked initially.
disable_linking (optional): set to 1 to prevent from redirecting clicks on graph to list view
order (optional): if set, x-axis values will be sorted by default according their measure with respect to the given order (asc or desc). Only used for bar and pie charts.
string (optional): string displayed in the breadcrumbs when redirecting to list view.

The only allowed element within a graph view is field which can have the following attributes:

name (mandatory): the name of a field to use in the view. If used for grouping (rather than aggregating)
invisible (optional): if true, the field will not appear either in the active measures nor in the selectable measures.
type (optional): if set to measure, the field will be used as an aggregated value within a group instead of a grouping criteria. It only works for the last field with that attribute but it is useful for other fields with string attribute (see below).
interval (optional): on date and datetime fields, groups by the specified interval (day, week, month, quarter or year) instead of grouping on the specific datetime (fixed second resolution) or date (fixed day resolution). Default is month.
string (optional): only used for field with type="measure". The name that will be used to display the field in the graph view, overrides the default python String attribute of the field.

The measures are automatically generated from the model fields; only the aggregatable fields are used. Those measures are also alphabetically sorted on the string of the field.

Warning

graph view aggregations are performed on database content, non-stored function fields can not be used in graph views

Pivot¶

The pivot view is used to visualize aggregations as a pivot table. Its root element is <pivot> which can take the following attributes:

sample boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

These fake records will have heuristics for certain field names/models. For example, a field ‘display_name’ on the model ‘res.users’ will be populated with sample people names while an ‘email’ field will be in the form ‘firstname.lastname@sample.demo’.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:
<tree banner_route="/module_name/hello" />
class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

disable_linking (optional)

Set to 1 to remove table cell’s links to list view.

display_quantity (optional)

Set to 1 to display the Quantity column by default.

default_order (optional)

The name of the measure and the order (asc or desc) to use as default order in the view.

<pivot default_order="foo asc">
   <field name="foo" type="measure"/>
</pivot>

The only allowed element within a pivot view is field which can have the following attributes:

name (mandatory)

the name of a field to use in the view. If used for grouping (rather than aggregating)

string (optional)

the name that will be used to display the field in the pivot view, overrides the default python String attribute of the field.

type (optional)

indicates whether the field should be used as a grouping criteria or as an aggregated value within a group. Possible values are:

row (default): groups by the specified field, each group gets its own row.
col: creates column-wise groups
measure: field to aggregate within a group
interval: on date and datetime fields, groups by the specified interval (day, week, month, quarter or year) instead of grouping on the specific datetime (fixed second resolution) or date (fixed day resolution).

invisible (optional)

if true, the field will not appear either in the active measures nor in the selectable measures (useful for fields that do not make sense aggregated, such as fields in different units, e.g. € and $).

The measures are automatically generated from the model fields; only the aggregatable fields are used. Those measures are also alphabetically sorted on the string of the field.

Warning

like the graph view, the pivot aggregates data on database content which means that non-stored function fields can not be used in pivot views

In Pivot view a field can have a widget attribute to dictate its format. The widget should be a field formatter, of which the most interesting are date, datetime, float_time, and monetary.

For instance a timesheet pivot view could be defined as:

<pivot string="Timesheet">
    <field name="employee_id" type="row"/>
    <field name="date" interval="month" type="col"/>
    <field name="unit_amount" type="measure" widget="float_time"/>
</pivot>

Calendar¶

Calendar views display records as events in a daily, weekly, monthly or yearly calendar.

Note

By default the calendar view will be centered around the current date (today). You can pass a specific initial date to the context of the action in order to set the initial focus of the calendar on the period (see mode) around this date (the context key to use being initial_date)

Their root element is <calendar>. Available attributes on the calendar view are:

string

string (default: '')

This view title is displayed only if you open an action that has no name and whose target is ‘new’ (opening a dialog)

create

boolean (default: True)

Disable/enable record creation on the view.

edit

boolean (default: True)

Disable/enable record editing on the view.

delete

boolean (default: True)

Disable/enable record deletion on the view through the Action dropdown.

date_start (required)

name of the record’s field holding the start date for the event

date_stop

name of the record’s field holding the end date for the event, if date_stop is provided records become movable (via drag and drop) directly in the calendar

date_delay

alternative to date_stop, provides the duration of the event instead of its end date (unit: day)

color

name of a record field to use for color segmentation. Records in the same color segment are allocated the same highlight color in the calendar, colors are allocated semi-randomly. Displayed the display_name/avatar of the visible record in the sidebar

form_view_id

view to open when the user create or edit an event. Note that if this attribute is not set, the calendar view will fall back to the id of the form view in the current action, if any.

event_open_popup

If the option ‘event_open_popup’ is set to true, then the calendar view will open events (or records) in a FormViewDialog. Otherwise, it will open events in a new form view (with a do_action)

quick_create

enables quick-event creation on click: only asks the user for a name (the field to which this values is saved can be controlled through rec_name) and tries to create a new event with just that and the clicked event time. Falls back to a full form dialog if the quick creation fails

quick_create_view_id

View to open when the attribute quick_create is set and the user creates an event instead of the default dialog.

create_name_field

name of the record’s field holding the textual representation of the record, this is used when creating records through the ‘quick create’ mechanism

all_day

name of a boolean field on the record indicating whether the corresponding event is flagged as day-long (and duration is irrelevant)

mode

Default display mode when loading the calendar. Possible attributes are: day, week, month, year

scales

Comma-separated list of scales to provide. By default, all scales are available. See mode for possible scale values.

create, delete

allows disabling the corresponding action in the view by setting the corresponding attribute to false

<field>

declares fields to aggregate or to use in kanban logic. If the field is simply displayed in the calendar cards.

Fields can have additional attributes:

invisible: use “True” to hide the value in the cards
avatar_field: only for x2many field, to display the avatar instead of the display_name in the cards
write_model and write_field and filter_field: you can add a filter and save the result in the defined model, the filter is added in the sidebar. The filter_field is optional and allows you to specify the field that will hold the status of the filter.
filters and color: use “True” to add this field in filter in the sidebar. You can specify a color field used to colorize the checkbox.

Model Commons¶

Model._date_name = 'date': field to use for default calendar view

Activity¶

The Activity view is used to display the activities linked to the records. The data are displayed in a chart with the records forming the rows and the activity types the columns. The first cell of each row displays a (customizable, see templates, quite similarly to Kanban) card representing the corresponding record. When clicking on others cells, a detailed description of all activities of the same type for the record is displayed.

Warning

The Activity view is only available when the mail module is installed, and for the models that inherit from the mail.activity.mixin.

The root element of the Activity view is <activity>, it accepts the following attributes:

string (mandatory): A title, which should describe the view

Possible children of the view element are:

field

declares fields to use in activity logic. If the field is simply displayed in the activity view, it does not need to be pre-declared.

Possible attributes are:

name (required): the name of the field to fetch

templates

defines the QWeb Templates templates. Cards definition may be split into multiple templates for clarity, but activity views must define at least one root template activity-box, which will be rendered once for each record.

The activity view uses mostly-standard javascript qweb and provides the following context variables (see Kanban for more details):

widget: the current ActivityRecord(), can be used to fetch some meta-information. These methods are also available directly in the template context and don’t need to be accessed via widget
record: an object with all the requested fields as its attributes. Each field has two attributes value and raw_value

Cohort¶

Enterprise feature

The cohort view is used to display and understand the way some data changes over a period of time. For example, imagine that for a given business, clients can subscribe to some service. The cohort view can then display the total number of subscriptions each month, and study the rate at which client leave the service (churn). When clicking on a cell, the cohort view will redirect you to a new action in which you will only see the records contained in the cell’s time interval; this action contains a list view and a form view.

Note

By default the cohort view will use the same list and form views as those defined on the action. You can pass a list view and a form view to the context of the action in order to set/override the views that will be used (the context keys to use being form_view_id and list_view_id)

For example, here is a very simple cohort view:

<cohort string="Subscription" date_start="date_start" date_stop="date" interval="month"/>

The root element of the Cohort view is <cohort>, it accepts the following attributes:

sample boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

These fake records will have heuristics for certain field names/models. For example, a field ‘display_name’ on the model ‘res.users’ will be populated with sample people names while an ‘email’ field will be in the form ‘firstname.lastname@sample.demo’.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:
<tree banner_route="/module_name/hello" />
class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

string (mandatory)

A title, which should describe the view

date_start (mandatory)

A valid date or datetime field. This field is understood by the view as the beginning date of a record

date_stop (mandatory)

A valid date or datetime field. This field is understood by the view as the end date of a record. This is the field that will determine the churn.

disable_linking (optional)

Set to 1 to prevent from redirecting clicks on cohort cells to list view.

mode (optional)

A string to describe the mode. It should be either ‘churn’ or ‘retention’ (default). Churn mode will start at 0% and accumulate over time whereas retention will start at 100% and decrease over time.

timeline (optional)

A string to describe the timeline. It should be either ‘backward’ or ‘forward’ (default). Forward timeline will display data from date_start to date_stop, whereas backward timeline will display data from date_stop to date_start (when the date_start is in future / greater than date_stop).

interval (optional)

A string to describe a time interval. It should be ‘day’, ‘week’, ‘month’’ (default) or ‘year’.

measure (optional)

A field that can be aggregated. This field will be used to compute the values for each cell. If not set, the cohort view will count the number of occurrences.

<field> (optional)

allows to specify a particular field in order to manage it from the available measures, it’s main use is for hiding a field from the selectable measures:

name (mandatory): the name of the field to use in the view.
string (optional): the name that would be used to display the field in the cohort view, overrides the default python String attribute of the field.
invisible (optional): if true, the field will not appear either in the active measures nor in the selectable measures (useful for fields that do not make sense aggregated, such as fields in different units, e.g. € and $). If the value is a domain, the domain is evaluated in the context of the current row’s record, if True the corresponding attribute is set on the cell.

Grid¶

Enterprise feature

Limitations¶

This view is a work in progress and may have to be expanded or altered.

only date column fields have been tested, selection and many2one are nominally implemented and supported but have not been tested, datetime is not implemented at all.
column cells are hardly configurable and must be numerical
cell adjustment is disabled by default and must be configured to be enabled
create, edit and delete ACL metadata doesn’t get automatically set on the view root due to limitations in fields_view_get post-processing (there’s a fixed explicit list of the view types getting those attributes)

Schema¶

The grid view has its own schema and additional validation in this module. The view architecture is:

<grid> (1)

architecture root element

mandatory string attribute
optional create, edit and delete attributes
optional adjustment and adjust_name attributes

adjustment can be either object or action to indicate whether a cell’s adjustment should be performed through a method call or an action execution. adjust_name provides respectively the method name and the action id.

In both cases, the adjustment parameters are provided as a grid_adjust context member, in the object case, the parameters are also provided as positional function parameters (next to an empty list of ids):

row_domain
the domain matching the entire row of the adjusted cell

column_field
the name of the column for the adjusted cell

column_value
the value of the column for the adjusted cell

cell_field
the measure field of the adjusted cell

change
the difference between the old value of the cell and the adjusted one, may be positive or negative
optional hide_line_total and hide_column_total attributes

hide_line_total
set to true to hide total line (default false)

hide_column_total
set to true to hide total column (default false)
optional barchart_total attribute

barchart_total
set to true in order to display a bar chart at the bottom of the grid, based on the totals of the columns (default false).
optional create_inline and display_empty attributes

create_inline
set to true in order to display an additional row at bottom of the grid with an Add a line button (default false). When this option is set to true, the Add a line button from the control panel is hidden. When no data is available and when display_empty is not set (so when the help content is displayed), the the Add a line button from the control panel is shown in order to let the user create a first record.

display_empty
set to true in order to keep displaying the grid when there is no data (default false). This can be useful when you want the user to be able to keep track of the current period (as dates are displayed in the columns headers). As a reminder, when no data are present and when this attribute is no set, the help content is displayed instead of the grid.

<button> (0+)

Regular Odoo action buttons, displayed in the view header

mandatory string attribute (the button label)
mandatory type attribute, either object or action

Note
workflow buttons are not supported
mandatory name attribute, either the name of the method to call, or the ID of the action to execute
optional context

The server callback is provided with all the record ids displayed in the view, either as the ids passed to the method (object button) or as the context’s active_ids (action buttons)

<field type="row"> (1+)

Row grouping fields, will be replaced by the search view’s groupby filter if any.

The order of row fields in the view provides their grouping depth: if the first field is school and the second is age the records will be grouped by school first and by age within each school.

<field type="col"> (1)

Column grouping field.

The col field can contain 0+ <range> elements which specify customisable column ranges. range elements have the following mandatory attributes

name

can be used to override the default range (the first one by default) through the grid_range context value

string

the range button’s label (user-visible)

span

symbolic name of the span of all columns to display at once in the view, may trigger pagination.

For date fields, valid spans are currently week and month.

step

symbolic name of the step between one column and the previous/next

For date fields, the only valid span is currently day.

<field type="measure"> (1)

Cell field, automatically accumulated (by read_group).

The measure field can take a widget attribute to customise its display.

Server interactions¶

Aside from optional buttons, the grid view currently calls two methods:

read_grid (provided on all models by the module) returns almost the entirety of the grid’s content as a dict:
- the row titles is a list of dictionaries with the following keys:
  
  values (required)
  this maps to a dictionary with a key per row field, the values are always of the form [value, label].
  
  domain (required)
  the domain of any record at the source of this row, in case it’s necessary to copy a record during cell adjustment
- the column titles is a list of dictionaries with at least one key:
  
  values (required)
  see row title values
  
  domain (required)
  see column domain value
  
  current (optional)
  boolean, marks/highlights a column
- the grid data as a list (of rows) of list (of cells) of cell dicts each with the following keys:
  
  value
  the numeric value associated with the cell
  
  domain
  the domain matching the cell’s records (should be assumed opaque)
  
  size
  the number of records grouped in the cell
  
  readonly (optional)
  a boolean indicating that this specific cell should not be client-editable
  
  classes (optional)
  a list of classes (as strings) to add on the cell’s container (between the cell’s TD and the cell’s potentially-editable element).
  
  In case of conflicts between this list and the base classes (prefixed with o_grid_cell_), the classes in this list are ignored.
  
  Note that the grid data is dense, if querying the database yields no group matching a cell a cell will generate an “empty” cell with default values for required keys.
- prev and next which can be either falsy (no pagination) or a context item to merge into the view’s own context to read_grid the previous or next page, it should be assumed to be opaque
read_grid_domain(field, range) (provided on al models by the module) returns the domain matching the current configured “span” of the grid. This is also done internally by read_grid, but can be useful or necessary to call independently to use with separate e.g. search_count or read_group.
adjust_grid, for which there currently isn’t a blanket implementation and whose semantics are likely to evolve with time and use cases

Server Hooks¶

read_grid calls a number of hooks allowing the customisation of its operations from within without having to override the entire method:

_grid_format_cell(group, cell_field)

converts the output of a read_group (group-by-group) into cells in the format described above (as part of “the grid data”)

_grid_make_empty_cell(row_domain, column_domain, view_domain)

generates an empty version of a cell (if there is no corresponding group)

_grid_column_info(name, range)

generates a ColumnMetadata object based on the column type, storing values either returned directly (as part of read_grid) or used query and reformat read_group into read_grid:

grouping

the actual grouping field/query for the columns

domain

domain to apply to read_group in case the column field is paginated, can be an empty list

prev and next

context segments which will be sent to read_grid for pages before and after the current one. If False, disables pagination in that direction

values

column values to display on the “current page”, each value is a dictionary with the following keys:

values: dictionary mapping field names to values for the entire column, usually just name -> a value
domain: domain matching this specific column
is_current: True if the current column should be specifically outlined in the grid, False otherwise
format: how to format the values of that column/type from read_group formatting to read_grid formatting (matching values in ColumnInfo)

ACL¶

if the view is not editable, individual cells won’t be editable
if the view is not creatable, the Add a Line button will not be displayed (it currently creates a new empty record)

Context Keys¶

grid_range

selects which range should be used by default if the view has multiple ranges

grid_anchor

if applicable, used as the default anchor of column ranges instead of whatever read_grid defines as its default.

For date fields, the reference date around which the initial span will be computed. The default date anchor is “today” (in the user’s timezone)

Gantt¶

Enterprise feature

Gantt views appropriately display Gantt charts (for scheduling).

The root element of gantt views is <gantt/>, it has no children but can take the following attributes:

sample

boolean (default: False)

Populate the view with a set of sample records if none are found for the current model. This attribute is false by default.

The user will not be able to interact with these data and they will be discarded as soon as an action is performed (record created, column added, etc.)

banner_route

path (optional)

a route address to be fetched and prepended to the view.

If this attribute is set, the controller route url will be fetched and displayed above the view. The json response from the controller should contain an “html” key.

If the html contains a stylesheet <link> tag, it will be removed and appended to <head>.

To interact with the backend you can use <a type=”action”> tags. Please take a look at the documentation of the useActionLinks (addons/web/static/src/views/view_hook.js)

for more details.

Only views extending AbstractView and AbstractController can use this attribute, like Form, Kanban, List, …

Example:

<tree banner_route="/module_name/hello" />

class MyController(odoo.http.Controller):
    @http.route('/module_name/hello', auth='user', type='json')
    def hello(self):
        return {
            'html': """
                <div>
                    <link href="/module_name/static/src/css/banner.css"
                        rel="stylesheet">
                    <h1>hello, world</h1>
                </div> """
        }

string

string (default: '')

This view title is displayed only if you open an action that has no name and whose target is ‘new’ (opening a dialog)

create

boolean (default: True)

Disable/enable record creation on the view.

edit

boolean (default: True)

Disable/enable record editing on the view.

delete

boolean (default: True)

Disable/enable record deletion on the view through the Action dropdown.

date_start (required)

name of the field providing the start datetime of the event for each record.

date_stop (required)

name of the field providing the end duration of the event for each record.

dependency_field

name of the many2many field that provides the dependency relation between two records. If B depends on A, dependency_field is the field that allows getting A from B. Both this field and dependency_inverted_field field are used to draw dependency arrows between pills and reschedule them.

dependency_inverted_field (required if dependency_field is provided)

name of the many2many field that provides the invert dependency relation than dependency_field. If B depends on A, dependency_inverted_field is the field that allows getting B from A.

color

name of the field used to color the pills according to its value

decoration-{$name}

python expression that evaluates to a boolean

allow changing the style of a cell’s text based on the corresponding record’s attributes.

{$name} can be one of the following bootstrap contextual color (danger, info, secondary, success or warning).

Define a conditional display of a record in the style of a row’s text based on the corresponding record’s attributes.

uid: the id of the current user,
today: the current local date as a string of the form YYYY-MM-DD,
now: same as today with the addition of the current time. This value is formatted as YYYY-MM-DD hh:mm:ss.

<gantt decoration-info="state == 'draft'"
      decoration-danger="state == 'help_needed'"
      decoration-bf="state == 'busy'">
  ...
</gantt>

default_group_by

name of a field to group tasks by

disable_drag_drop

if set to true, the gantt view will not have any drag&drop support

consolidation

field name to display consolidation value in record cell

consolidation_max

dictionary with the “group by” field as key and the maximum consolidation value that can be reached before displaying the cell in red (e.g. {"user_id": 100})

consolidation_exclude

name of the field that describes if the task has to be excluded from the consolidation if set to true it displays a striped zone in the consolidation line

create, cell_create, edit, delete, plan

allows disabling the corresponding action in the view by setting the corresponding attribute to false (default: true).

create: If enabled, an Add button will be available in the control panel to create records.
cell_create: If enabled and create enabled, a “+” button will be displayed while hovering on a time slot cell to create a new record on that slot.
edit: If enabled, the opened records will be in edit mode (thus editable).
plan: If enabled and edit enabled, a “magnifying glass” button will be displayed on time slots to plan unassigned records into that time slot.

Example

When you do not want to create records on the gantt view and the beginning and end dates are required on the model, the planning feature should be disabled because no record will ever be found.

offset

Depending on the scale, the number of units to add to today to compute the default period. Examples: An offset of +1 in default_scale week will open the gantt view for next week, and an offset of -2 in default_scale month will open the gantt view of 2 months ago.

progress

name of a field providing the completion percentage for the record’s event, between 0 and 100

string

title of the gantt view

precision

JSON object specifying snapping precisions for the pills in each scale.

Possible values for scale day are (default: hour):

hour: records times snap to full hours (ex: 7:12 becomes 8:00)
hour:half: records times snap to half hours (ex: 7:12 becomes 7:30)
hour:quarter: records times snap to half hours (ex: 7:12 becomes 7:15)

Possible values for scale week are (default: day:half):

day: records times snap to full days (ex: 7:28 AM becomes 11:59:59 PM of the previous day, 10:32 PM becomes 12:00 PM of the current day)
day:half: records times snap to half hours (ex: 7:28 AM becomes 12:00 PM)

Possible values for scale month are (default: day:half):

day: records times snap to full days (ex: 7:28 AM becomes 11:59:59 PM of the previous day, 10:32 PM becomes 12:00 PM of the current day)
day:half: records times snap to half hours (ex: 7:28 AM becomes 12:00 PM)

Scale year always snap to full day.

Example of precision attribute: {"day": "hour:quarter", "week": "day:half", "month": "day"}

total_row

boolean to control whether the row containing the total count of records should be displayed. (default: false)

collapse_first_level

boolean to control whether it is possible to collapse each row if grouped by one field. (default: false, the collapse starts when grouping by two fields)

display_unavailability

boolean to mark the dates returned by the gantt_unavailability function of the model as available inside the gantt view. Records can still be scheduled in them, but their unavailability is visually displayed. (default: false)

default_scale

default scale when rendering the view. Possible values are (default: month):

day
week
month
year

scales

comma-separated list of allowed scales for this view. By default, all scales are allowed. For possible scale values to use in this list, see default_scale.

templates

defines the QWeb Templates template gantt-popover which is used when the user hovers over one of the records in the gantt view.

The gantt view uses mostly-standard javascript qweb and provides the following context variables:

widget: the current GanttRow(), can be used to fetch some meta-information. The getColor method to convert in a color integer is also available directly in the template context without using widget.
on_create: If specified when clicking the add button on the view, instead of opening a generic dialog, launch a client action. this should hold the xmlid of the action (eg: on_create="%(my_module.my_wizard)d"

form_view_id

view to open when the user create or edit a record. Note that if this attribute is not set, the gantt view will fall back to the id of the form view in the current action, if any.

dynamic_range

if set to true, the gantt view will start at the first record, instead of starting at the beginning of the year/month/day.

pill_label

If set to true, the time appears in the pill label when the scale is set on week or month. (e.g. 7:00 AM - 11:00 AM (4h) - DST Task 1)

thumbnails

This allows to display a thumbnail next to groups name if the group is a relationnal field. This expects a python dict which keys are the name of the field on the active model. Values are the names of the field holding the thumbnail on the related model.

Example: tasks have a field user_id that reference res.users. The res.users model has a field image that holds the avatar, then:

<gantt
   date_start="date_start"
   date_stop="date_stop"
   thumbnails="{'user_id': 'image_128'}"
 >
 </gantt>

will display the users avatars next to their names when grouped by user_id.

Map¶

Enterprise feature

This view is able to display records on a map and the routes between them. The records are represented by pins. It also allows the visualization of fields from the model in a popup tied to the record’s pin.

Note

The model on which the view is applied should contain a res.partner many2one since the view relies on the res.partner’s address and coordinates fields to localize the records.

API¶

The view uses location data platforms’ API to fetch the tiles (the map’s background), do the geoforwarding (converting addresses to a set of coordinates) and fetch the routes. The view implements two API, OpenStreetMap and MapBox. OpenStreetMap is used by default and is able to fetch tiles and do geoforwarding. This API does not require a token. As soon as a valid MapBox token is provided in the general settings the view switches to the MapBox API. This API is faster and allows the computation of routes. A token can be obtained by signing up to MapBox.

Structural components¶

The view’s root element is <map>. It can have the following attributes:

res_partner: Contains the res.partner many2one. If not provided the view resorts to create an empty map.
default_order: If a field is provided the view overrides the model’s default order. The field must be part of the model on which the view is applied, not from res.partner.
routing: if 1 display the routes between the records. The view needs a valid MapBox token and at least two located records (i.e the records have a res.partner many2one and the partner has an address or valid coordinates).
hide_name: if 1 hide the name from the pin’s popup (default: 0).
hide_address: if 1 hide the address from the pin’s popup (default: 0).
hide_title: if 1 hide the title from the pin list (default: 0).
panel_title: String to display as title of the pin list. If not provided, the title is the action’s name or “Items” if the view is not in an action.
limit: Maximum number of records to fetch (default: 80). It must be a positive integer.

The <map> element can contain multiple <field> elements. Each <field> element is interpreted as a line in the pin’s popup. The field’s attributes are the following:

name

The field to display.

string

String to display before the field’s content. It can be used as a description.

For example here is a map:

<map res_partner="partner_id" default_order="date_begin" routing="1" hide_name="1">
    <field name="partner_id" string="Customer Name"/>
</map>

Edit on GitHub

View architecture¶

Generic view¶

Python expression¶

Form¶

Semantic components¶

<field>: render formatted values¶

<label>: displays other field label¶

<button>: displays button to call action¶

Messaging features¶

Attachment/Document preview¶

Structural components¶

<group>: Columns layout¶

<sheet>: Responsive layout¶

<notebook> & <page>: tabbed section¶

<newline>: new row¶

<separator>: horizontal spacing¶

<header>: workflow buttons and status¶

<footer>: bottom/dialog buttons¶

container for buttons¶

container for a title¶

Settings Form View¶

<app>: declare the application¶

<block>: declare a group of settings¶

<setting>: declare the setting¶

List¶

<field>: render formatted values¶

<button>: display button to call action¶

<groupby>: custom headers when grouping¶

<header>: custom buttons in control panel¶

<control> & <create>: customize “add a line”¶

Search¶

<field>: field usable as filter¶

<filter>: predefined Filters¶

<separator>: separate groups of filters¶

<group>: separate groups of filters¶

<searchpanel>: display a search panel¶

Search defaults¶

Kanban¶

<field>: render formatted values¶

<header>: custom buttons in control panel¶

<progressbar>: progressbar on top of columns¶

<templates>: template of card¶

QWeb¶

Graph¶

Pivot¶

Calendar¶

Model Commons¶

Activity¶

Cohort¶

Grid¶

Limitations¶

Schema¶

Server interactions¶

Server Hooks¶

ACL¶

Context Keys¶

Gantt¶

Map¶

API¶

Structural components¶