Chapter 10: Backend Views – Designing the User Interface

This chapter describes how to create views to implement the user interface for business applications. The Odoo user interface starts with the menu items and various actions being executed on menu clicks, so these are the first components we will learn about.

The most used view type is the form view, and there are a few elements we must learn about, from organizing the disposition of the elements in the view to understanding all the options that are available for fields and buttons.

Some other frequently used views include list views and search views. Finally, other view types are available that are useful for specific purposes, such as the pivot and graph views. An overview of these will be provided toward the end of this chapter.

The following topics will be covered in this chapter:

• Adding menu items
• Understanding window actions
• Exploring the form view's structure
• Using fields
• Using...

Technical requirements

We'll continue working with the library_checkout add-on module. The model layer for it is already complete; now, it needs the view layer for the user interface.

The code in this chapter is based on the code that we created in Chapter 8, Business Logic – Supporting Business Processes. The necessary code can be found in this book's GitHub repository at https://github.com/PacktPublishing/Odoo-15-Development-Essentials, in the ch10 directory.

Adding menu items

Menu items are the starting point for user interface navigation. They form a hierarchical structure, where the top-level items represent applications, and the level below is the application main menu. Further sub-menu levels can be added.

Menu items with no sub-menus are actionable and can trigger an action that tells the web client what to do, such as opening a view.

Menu items are stored in the ir.ui.menu model and can be browsed via the Settings | Technical | User Interface | Menu Items menu.

The library_app add-on module created a top-level menu for the library books, while the library_checkout add-on module added the menu items for the checkouts and checkout stages. These are both implemented in library_checkout/views/library_menu.xml.

This is the XML for the checkout menu item:

    <menuitem id="menu_library_checkout"
              name="...

Understanding window actions

A window action on a menu gives the web client instructions on what to do, such as opening a view, and can be used in menu items or buttons in views.

Window actions identify the model to use and the views to present in the user interface. They can also filter the available records using a domain filter and can set default values and filters using the context attribute.

Window actions are stored in the ir.actions.act_window model and can be browsed by going to the Settings | Technical | Actions | Window Actions menu.

The library_checkout/views/library_menu.xml file contains the definition for the window action that's used by the checkout menu item:

    <record id="action_library_checkout" 
            model="ir.actions.act_window">
        <field name="name">Checkouts</field...

Adding options to the Action context menu

Window actions can also be used from the Action menu button, available at the top of form views, and also in list views when records are selected:

Figure 10.1 – The Action context menu

This menu is contextual because the action will apply to the record or records currently selected.

To have an action available in the Action menu, two more fields have to be set on the window action:

• binding_model_id is a reference to the model to use the action for; for example, <field name="binding_model_id" ref="model_library_checkout" />.
• binding_view_types can be used to limit the option's visibility to specific view types, such as form or list; for example, <field name="binding_view_types">form,list</field>.

An example of this has already been implemented in the library_checkout module, in the wizard/checkout_mass_message_wizard_view.xml file. This...

Exploring the form view structure

Form views are the main way users can interact with data records. Form views can either follow a simple layout or a business document layout, similar to a paper document. In this section, we'll learn how to design these business document views and how to use the elements and widgets that are available.

In Chapter 8, Business Logic – Supporting Business Processes, we created a library checkout model and prepared a basic form for it. We will revisit and enhance it in this section.

The following screenshot shows what the form view will look like when we're done:

Figure 10.3 – The enhanced Checkouts form view

You can refer to this screenshot while we gradually add the different elements throughout this chapter.

Using business document views

Historically, organizations use paper forms to support their internal processes. Business application models support digital versions of these paper forms...

Using fields

Inside a form or list view, fields widgets are the way to present and edit data from model fields.

View fields have a few attributes available to them. Most of these attribute values have defaults that are taken from the model definition, but these can be overridden in the view.

Here is a quick reference for the common field attributes:

• name is the field name in the model and identifies the field that's being rendered by this element.
• string is the label text to be used. It overrides the model definition.
• help provides some tooltip help text that's shown when the mouse is hovered over the field.
• placeholder provides suggestion text to be displayed inside the field.
• widget sets a specific widget to be used to render the field. The available widgets will be discussed later in this section.
• options is a JSON data structure that's used to pass additional options to the widget. The values to use depend on the widget being used...

Using buttons

Buttons allow the user to trigger actions, such as opening another view or running business logic in a server function. They were introduced previously in this chapter, when we discussed the form header, but they can also be added anywhere in form and list views.

Buttons support the following attributes:

• string is the button text label, or the HTML alt text when an icon is used.
• type is the type of action to perform. Possible values include object, to call a Python method, or action, to run a window action.
• name identifies the specific action to perform, according to the chosen type: either a model method name or the database ID of a window action to run. The %(<xmlid>)d formula can be used to translate an XML ID into the necessary database ID when the view is being loaded.
• args is used when type="object" is used to pass additional parameters to the method call.
• context sets the values on the context. This could be used in the...

Adding dynamic view elements

View elements can dynamically change their appearance or behavior, depending on the field values. Field values can be dynamically set values of domain filters on other form fields through the onchange mechanism. These features will be discussed next.

Using onchange events

The onchange mechanism allows us to trigger server logic while the user is modifying data on an unsaved form. For example, when setting the product field, a unit price on the same form can be automatically set.

In older Odoo versions, the onchange events were defined at the view level, but since Odoo 8, they are declared directly on the model layer, without the need for any specific view markup. This can be done with methods that use the @api.onchange('field1', 'field2', ...) decorator. It binds onchange logic to the declared fields. The onchange model methods were discussed in more detail in Chapter 8, Business Logic – Supporting Business Processes...

Exploring list views

List views are probably the most used view type, closely followed by form views. List views present records as lines and data fields as columns. By default, they are read-only, but they can also be made editable.

The list view's basic definition is simple. It is a sequence of field elements inside a <tree> element. library_checkout already contains a simple list view, in the views/checkout_view.xml file, that looks like this:

  <record id="view_tree_checkout" model="ir.ui.view">
    <field name="name">Checkout Tree</field>
    <field name="model">library.checkout</field>
    <field name="arch" type="xml">
      <tree>
        <field name="request_date" />
      ...

Exploring search views

At the top right of the view, there is a search box with a few buttons underneath it, including Filters and Group By. When you're typing in the search box, you will see suggestions regarding the field to be searched.

The search options that are proposed are configured in the search view. The current search view can be inspected using the developer menu and by choosing the Edit ControlPanelView option.

Search views are defined through the <search> view type. It can provide the following types of elements:

• <field> elements to add filter options when typing in the search box.
• <filter> elements to add predefined filters under the Filters and Group By buttons.
• A <searchpanel> element, to include a navigation tree on the left-hand side of the user interface.

  Changes in Odoo 13

  The <searchpanel> widget for the list and Kanban views was introduced in Odoo 13 and is not available in earlier versions.

To add...

Understanding the other available view types

The form and list views are essential user interface components, but other than them, a few other specific view types can be used.

We're already familiar with the three basic views: form, tree, and search. Beyond these, the following view types are also available in Odoo Community Edition:

• kanban presents records as cards that can be organized in columns to create Kanban boards.
• activity presents a summary of scheduled activities.
• calendar present records in a calendar format.
• graph presents data as a graphical chart.
• pivot presents data as an interactive pivot table.
• qweb is used to declare QWeb templates to be used in reports, Kanban views, or web pages. However, this is not a web client-supported view type like forms and lists are.

Kanban views will be presented in depth in Chapter 11, Kanban Views and Client-Side QWeb, so they won't be addressed here.

Changes in Odoo 14

The diagram...

Summary

Well-designed views are key for a good user experience. Applications need to support the business logic, but an easy-to-use user interface is also important to help users navigate efficiently through the business processes and minimize errors.

The Odoo web client provides a rich set of tools to build such user interfaces. This includes a menu system, several view types, and different field widgets to choose from.

Adding menu items is the first step, and these use window actions to let the web client know what views should be presented.

Most of the user interaction will happen on form views, and it is important to understand all the elements that can be used there. We started by presenting the general structure that form views are expected to follow, as well as the elements to be added to each.

This includes the header section, the title fields, the other form fields, a possible notebook section with pages, and a final messaging area.

Record data is presented...

Further reading

The following reference materials complement the topics that were described in this chapter:

• The official Odoo documentation:
  • On actions: https://www.odoo.com/documentation/15.0/developer/reference/backend/actions.html
  • On views: https://www.odoo.com/documentation/15.0/developer/reference/backend/views.html
• The Font Awesome icon index: https://fontawesome.com/v4.7.0/icons/