In the previous chapters, we had an end-to-end overview of creating new modules for Odoo. In Chapter 2 , Building Your First Odoo Application, we built a completely new application, and in Chapter 3 , Inheritance - Extending Existing Applications, we explored inheritance and how to use it to create an extension module for our application. In Chapter 4 , Module Data, we discussed how to add initial and demonstration data to our modules.

In these overviews, we touched upon all the layers involved in building a backend application for Odoo. Now, in the following chapters, it's time to explain these several layers that make up an application in more detail: models, views, and business logic.

In this chapter, you will learn how to design the data structures that support an application and how to represent the relationships between them.

As before, we will use an example to help explain the concepts.

Odoo's inheritance features provide an effective extensibility mechanism. It allows you to extend existing third-party apps without changing them directly. This composability also enables a module-oriented development pattern, where large apps can be split into smaller features, rich enough to stand on their own.

This can be helpful to limit complexity, both at the technical level and the user experience level. From a technical perspective, splitting a large problem into smaller parts makes it easier to solve and is friendlier for incremental feature development. From the user experience perspective, we can choose to activate only the features that are really needed for them, for a simpler user interface. So we will be improving our To-Do application through additional addon modules to finally form a fully featured application.

In the previous chapter, we first created an app for personal to-dos and then extended it so that the to-dos could be shared with other people.

Now we want to take our app to the next level by improving its user interface, including a kanban board. The kanban board is a simple workflow tool that organizes items in columns, where these items flow from the left-hand column to the right, until they are completed. We will organize our Tasks into columns, according to their Stages, such as Waiting, Ready, Started, or Done

We will start by adding the data structures to enable this vision. We need to add stages, and it will be good to add support for tags as well, allowing the tasks to be categorized by subject. In this chapter, we will focus on the data models only. The user interface for these features will be discussed in Chapter 6, Views - Designing the User Interface, and kanban views in Chapter 9, QWeb and Kanban Views.

The first thing to figure out is how our data will be structured so that we can design the supporting models. We already have the central entity: the To-do Task. Each task will be in one Stage at a time, and tasks can also have one or more tags on them. We will need to add these two additional models, and they will have these relationships:

  • Each task has a stage, and there can be many tasks in each stage
  • Each task can have many tags, and each tag can be attached to many tasks

This means that Tasks have many-to-one relationship with Stages, and many-to-many relationships with Tags. On the other hand, the inverse relationships are: Stages have a one-to-many relationship with Tasks and Tags have a many-to-many relationship with Tasks.

We will start by creating the new todo_ui module and add the To-do Stages and To-do Tags models to it.

We've been using the ~/odoo-dev/custom-addons/ directory to host our modules. We should create a new todo_ui directory inside it for the new addons. From the shell, we could use the following commands:

$ cd ~/odoo-dev/custom-addons
$ mkdir todo_ui
$ cd todo_ui

We begin adding the __manifest__.py  manifest file, with this content:

{
  'name': 'User interface improvements to the To-Do app',
  'description': 'User friendly features.',
  'author': 'Daniel Reis',
  'depends': ['todo_user'] }

We should also add a __init__.py file. It is perfectly fine for it to be empty for now.

Now we can install the module in our Odoo work database and get started with the models.