You already know most of what happens here. We define a view, of the tree type this time, 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. These follow the same semantics as earlier, except that there are fewer choices to make regarding 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 are the decoration attributes (*) in the tree element. This contains rules as to which font and/or color is chosen for the row, given in the form of decoration-$name="Python code". All matches turn into the corresponding CSS class, so the previous view renders partners that are both suppliers and customers in brown, customers in a bold font, and suppliers in red. In your Python code, you can only use the fields you named in the view definition, which is why we have to pull the customer and supplier fields too. We made these invisible because we only need the data and don't want to bother our users with the two extra columns. The possible classes are decoration-bf (bold), decoration-it (italic), and the semantic bootstrap classes, decoration-danger, decoration-info, decoration-muted, decoration-primary, decoration-success, and decoration-warning.