Creating views

We have created the To-do Items Model and made it available in the user interface with a Menu Item. Next, we will be creating the two essential views for it—a list (also called a tree) and a form.

List views

We will now create a list view:

1. In Settings, navigate to Technical | User Interface | Views and create a new record with the following values:

• • View Name: To-do List View
  • View Type: Tree
  • Model: x_todo_item

This is how the View definition is expected to look like:

2. In the Architecture tab, we should write XML with the view structure. Use the following XML code:

<tree>
  <field name="x_name" />
  <field name="x_is_done" />
</tree>

The basic structure of a list view is quite simple—a <tree> element containing one or more <field> elements for each of the columns to display in the list view.

We can do a few more interesting things with list views, and will explore them in more detail in Chapter 10, Backend Views – Design the User Interface.

Form views

Next, we will create the form view:

1. Create another View record, using the following values:

• • View Name: To-do Form View
    
  • View Type: Form
  • Model: x_todo_item

If we don't specify the View Type, it will be auto-detected from the view definition.

2. In the Architecture tab, type the following XML code:

<form>
  <group>
    <field name="x_name" />
    <field name="x_is_done" />
    <field name="x_work_team_ids" 
           widget="many2many_tags" 
           context="{'default_x_is_work_team': True}" />
  </group>
</form>

The form view structure has a root <form> element, containing elements such as <field>, among others that we will learn about in Chapter 10, Backend Views – Design the User Interface. Here, we also chose a specific widget for the work team field, to be displayed as tag buttons instead of a list grid.

We added the widget attribute to the Work Team field, to have the team members presented as button-like tags.

By default, relational fields allow you to directly create a new record to be used in the relationship. This means that we are allowed to create new Partner directly from the Work Team field. But if we do so, they won't have the Is Work Team? flag enabled, which can cause inconsistencies.

For a better user experience, we can have this flag set by default for these cases. This is done with the context attribute, used to pass session information to the next View, such as default values to be used. This will be discussed in detail in later chapters, and for now we just need to know that it is a dictionary of key-value pairs. Values prefixed with default_ provide the default value for the corresponding field.

So in our case, the expression needed to set a default value for the partner's Is Work Team? flag is {'default_x_is_work_team': True}.

That's it. If we now try the To-Do menu option, and create a new item or open an existing one from the list, we will see the form we just added.

Search views

We can also make predefined filter and grouping options available, in the search box in the upper-right corner of the list view. Odoo considers these view elements also, and so they are defined in Views records, just like lists and forms are.

As you may already know by now, Views can be edited either in the Settings | Technical | User Interface menu, or from the contextual Developer Tools menu. Let's go for the latter now; navigate to the to-do list, click on the Developer Tools icon in the upper-right corner, and select Edit Search view from the available options:

Since no search view is yet defined for the To-do Items Model, we will see an empty form, inviting us to create the first one. Fill in these values and save it:

1. View Name: Some meaningful description, such as To-do Items Filter
2. View Type: Search
3. Model: x_todo_item
4. Architecture: Add this XML code:

<search>
 <filter name="item_not_done" 
         string="Not Done" 
         domain="[('x_is_done', '=', False)]" />
</search>

If we now open the to-do list from the menu, so that it is reloaded, we will see that our predefined filter is now available from the Filters button below the search box. If we type Not Done inside the search box, it will also show a suggested selection.

It would be nice to have this filter enabled by default, and disable it when needed. Just like default field values, we can also use context to set default filters.

When we click on the To-do menu option, it runs a Window Actions to open the To-do list view. This Window Actions can set a context value, signaling the Views to enable a search filter by default. Let's try this:

1. Click on the To-do menu option to go to the To-do list.
2. Click on the Developer Tools icon and select the Edit Action option. This will open the Window Actions used to open the current Views. In the lower-right corner, there is a Filter section, where we have the Domain and Context fields.

The Domain allows to set a fixed filter on the records shown, which can't be removed by the user. We don't want to use that. Instead, we want to enable the item_not_done filter created before by default, which can be deselected whenever the user wishes to. To enable a filter by default, add a context key with its name prefixed with search_default_, in this case {'search_default_item_not_done': True}.

If we click on the To-do menu option now, we should see the Not Done filter enabled by default on the search box.