After having spent quite some time on the form view, we'll now have a quick look at how to define list views. Internally, they are called tree views in some places and list views in others, but, given there is another construction within the Odoo view framework called tree, we'll stick to the wording list here.
- Define your list view:
<record id="tree_all_customers" model="ir.ui.view"> <field name="model">res.partner</field> <field name="arch" type="xml"> <tree colors="blue: customer and supplier; green:customer; red: supplier"> <field name="name" /> <field name="customer" invisible="1" /> <field name="supplier" invisible="1" /> </tree> </field> </record> - Tell the action from the first recipe to use it:
<record id="action_all_customers_tree" model="ir.actions.act_window.view"> <field name="act_window_id" ref="action_all_customers" /> <field name="view_id" ref="tree_all_customers" /> <field name="sequence">5</field> </record>
You already know most of what happens here. We define a view, this time of type tree, and attach it to our action with an ir.actions.act_window.view element. So the only thing left to discuss is the tree element and its semantics. With a list you don't have many design choices, so the only valid children of this element are the field and button elements. They follow the same semantics as earlier, save for the fact that there are a lot less choices for widgets – the only really interesting choices are progressbar, many2onebutton, and handle. The first two behave like their form namesakes. handle is specific to list views. It is meant for integer fields and renders a drag handle that the user can use to drag a row to a different position in the list, thereby updating the field's value. This is useful for sequence or priority fields.
What is new here is the colors attribute in the tree element. It contains rules which font color is chosen for the row, given in the form color: Python code, separated by semicolons. The first match wins, so what the previous view does is to render partners who are both supplier and customer in blue, customers in green, and suppliers in red. In your Python code, you can use the fields you named in the view definition, which is why we have to pull the customer and supplier fields too. We made them invisible because we only need the data and don't want to bother our users with those two extra columns. The possible colors are those that HTML defines, so you can either use names or a hex string.
For numeric fields, you can add an attribute sum that causes this column to be summed up with the text you set in the attribute as a tooltip. Less common are the attributes avg, min, and max, that display the average, minimum, and maximum respectively. Note that these four only work on the records currently visible, so you might want to adjust the action's limit (see above) in order for the user to see all the records immediately.
Analogous to the colors attribute in the tree element is the fonts attribute. With it, you can choose to have a record be bold, italic, or underline (sic). On the right part of a font definition, you can run the same Python expressions as previously. There is a subtle difference though. Here, the last definition wins if multiple expressions apply to a row.
A very interesting attribute for the tree element is editable. If you set this to top or bottom, the list behaves entirely different than before. Without it, clicking a row opens a form view for the row. With it, clicking a row makes it editable inline, with the visible fields rendered as form fields. This is particularly useful in embedded list views, which are discussed later in this chapter. The choice is if new lines will be added on the top or bottom of the list.
By default, records are ordered according to the _order property of the displayed model. The user can change ordering by clicking a column header, but you can also set a different initial order by setting the default_order property in the tree element. The syntax is the same as in _order.
Tip
Ordering is often a source of frustration for new developers. As Odoo lets PostgreSQL do the work here, you can only order by fields that PostgreSQL knows about and also only the fields that live in the same database table. So if you want to order by a function or a related field, be sure to set store=True. If you need to order by a field inherited from another model, declare a stored related field.
The create, edit, and delete attributes of the tree element work the same as for the form element described earlier. They also determine the available controls if the editable attribute is set.