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.
We will now create a list view:
View Name
:To-do List View
View Type
:Tree
Model
:x_todo_item
This is how the View definition is expected to look like:
- 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.
Next, we will create the form view:
View Name:
To-do Form View
View Type
:Form
Model
:x_todo_item
- 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.
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:
View Name
: Some meaningful description, such asTo-do Items Filter
View Type
:Search
Model
:x_todo_item
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:
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 withsearch_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.