First thing is to create a new module adding our kanban views to to-do tasks. In a real-world work, situation using a module for this would probably be excessive and they could perfectly well be added directly in the todo_ui module. But for a clearer explanation, we will use a new module and avoid too many, and possibly confusing, changes in already created files. We will name it todo_kanban and create the usual initial files as follows:
$ cd ~/odoo-dev/custom-addons $ mkdir todo_kanban $ touch todo_kanban/__init__.py
Now, edit the descriptor file todo_kanban/__openerp__.py as follows:
{'name': 'To-Do Kanban',
'description': 'Kanban board for to-do tasks.',
'author': 'Daniel Reis',
'depends': ['todo_ui'],
'data': ['todo_view.xml'] }Next, create the XML file where our shiny new kanban views will go and set kanban as the default view on the to-do task's window action, as shown in the following:
<?xml version="1.0"?>
<openerp>
<data>
<!-- Add Kanban view mode to the menu Action: -->
<act_window id="todo_app.action_todo_task" name=" To-Do Tasks" res_model="todo.task" view_mode="kanban,tree,form,calendar,gantt,graph" context="{'search_default_filter_my_tasks': True}" />
<!-- Add Kanban view -->
<record id="To-do Task Kanban" model="ir.ui.view">
<field name="name">To-do Task Kanban</field>
<field name="model">todo.task</field>
<field name="arch" type="xml">
<!-- Empty for now, but the Kanban will go here! -->
</field>
</record></data>
</openerp>Now we have in place the basic skeleton for our module. The templates used in kanban views and reports are extended using the regular techniques used for other views, for example using XPATH expressions. See Chapter 3, Inheritance – Extending Existing Applications, for more details.
Before starting with the kanban views, we need to add a couple of fields to the to-do tasks model.
The two fields that are frequently used in kanban views are priority and kanban state. Priority lets users organize their work items, signaling what should be addressed first. Kanban state signals whether a task is ready to move to the next stage or is blocked for some reason. Both are supported by selection fields and have specific widgets to use on forms and kanban views.
To add these fields to our model, we will add a todo_kanban/todo_task.py file, as shown in the following:
from openerp import models, fields
class TodoTask(models.Model):
_inherit = 'todo.task'
priority = fields.Selection(
[('0', 'Low'), ('1', 'Normal'), ('2', 'High')],
'Priority', default='1')
kanban_state = fields.Selection(
[('normal', 'In Progress'),
('blocked', 'Blocked'),
('done', 'Ready for next stage')],
'Kanban State', default='normal')Let's not forget the todo_kanban/__init__.py file that will load the preceding code:
from . import todo_model
The kanban view architecture has a <kanban> top element and the following basic structure:
<kanban>
<!-- Fields to use in expressions... -->
<field name="a_field" />
<templates>
<t t-name="kanban-box">
<!-- HTML Qweb template … -->
</t>
</templates>
</kanban>The <templates> element contains the templates for the HTML fragments to use—one or more. The main template to be used must be named kanban-box. Other templates are allowed for HTML fragments to include in the main template.
The templates use standard HTML, but can include the <field> tag to insert model fields. Some QWeb special directives for dynamic content generation can also be used, like the t-name used in the previous example.
All model fields used have to be declared with a <field> tag. If they are used only in expressions, we have to declare them before the <templates> section. One of these fields is allowed to have an aggregated value, displayed at the top of the kanban columns. This is done by adding an attribute with the aggregation to use, for example:
<field name="effort_estimated" sum="Total Effort" />
Here the sum for the estimated effort field is presented at the top of the kanban columns with the label text Total Effort. Supported aggregations are sum, avg, min, max, and count.
The <kanban> top element also supports a few interesting attributes:
default_group_by: This sets the field to use for the default column groups.default_order: This sets a default order to use for the kanban items.quick_create="false": This disables the quick create option on the kanban view.class: This adds a CSS class to the root element of the rendered kanban view.
Now let's have a closer look at the QWeb templates to use in the kanban views.
For the vignette kanban QWeb templates, the skeleton looks like the following:
<t t-name="kanban-box">
<div class="oe_kanban_vignette">
<!-- Left side image: -->
<img class="oe_kanban_image" name="..." />
<div class="oe_kanban_details">
<!-- Title and data -->
<h4>Title</h4>
Other data <br/>
<ul>
<li>More data</li>
</ul>
</div>
</div>
</t>You can see the two main CSS classes provided for vignette style kanbans: oe_kanban_vignette for the top container and oe_kanban_details for the data content.
The complete vignette kanban view for the to-do tasks is as follows:
<kanban>
<templates>
<t t-name="kanban-box">
<div class="oe_kanban_vignette">
<img t-att-src="kanban_image('res.partner',
'image_medium', record.id.value)"
class="oe_kanban_image"/>
<div class="oe_kanban_details">
<!-- Title and Data content -->
<h4><a type="open">
<field name="name" />
</a></h4>
<field name="tags" />
<ul>
<li><field name="user_id" /></li>
<li><field name="date_deadline" /></li>
</ul>
<field name="kanban_state"
widget="kanban_state_selection"/>
<field name="priority" widget="priority"/>
</div>
</div>
</t>
</templates>
</kanban>We can see the elements discussed until now, and also a few new ones. In the <img> tag, we have the special t-att-src QWeb attribute. It can calculate the image src content from a database stored field. We will be explaining this and other QWeb directives in a moment. We can also see the usage of the special type attribute in the <a> tag. Let's have a closer look at it.
In QWeb templates, the <a> tag for links can have a type attribute. It sets the type of action the link will perform so that links can act just like the buttons in regular forms. So in addition to the <button> elements, the <a> tags can also be used to run Odoo actions.
As in form views, the action type can be action or object, and it should be accompanied by a name attribute, identifying the specific action to execute. Additionally, the following action types are also available:
The card kanban can be a little more complex. It has a main content area and two footer sub-containers, aligned to each of the card sides. A button opening an action menu may also be featured at the card's top-right corner.
The skeleton for this template looks like the following:
<t t-name="kanban-box">
<div class="oe_kanban_card">
<div class="oe_dropdown_kanban oe_dropdown_toggle">
<!-- Top-right drop down menu -->
</div>
<div class="oe_kanban_content">
<!-- Content fields go here... -->
<div class="oe_kanban_bottom_right"></div>
<div class="oe_kanban_footer_left"></div>
</div>
</div>
</t>A card kanban is more appropriate for the to-do tasks, so instead of the view described in the previous section, we would be better using the following:
<t t-name="kanban-box">
<div class="oe_kanban_card">
<div class="oe_kanban_content">
<!-- Option menu will go here! -->
<h4><a type="open">
<field name="name" />
</a></h4>
<field name="tags" />
<ul>
<li><field name="user_id" /></li>
<li><field name="date_deadline" /></li>
</ul>
<div class="oe_kanban_bottom_right">
<field name="kanban_state"
widget="kanban_state_selection"/>
</div>
<div class="oe_kanban_footer_left">
<field name="priority" widget="priority"/>
</div>
</div>
</div>
</t>So far we have seen static kanban views, using a combination of HTML and special tags (field, button, a). But we can have much more interesting results using dynamically generated HTML content. Let's see how we can do that using QWeb.