重载的概念

开发的过程中，我们很有可能会碰到这样的场景，需要修改官方定义的某个模块中的某个方法。虽然我们可以直接修改源码达到目的，但那样会污染官方源码，不方便于维护和移植。

重载的概念就是通过继承，重写原有模块的某些方法，拦截原有的执行路径，达到修改或是改造的目的。

简单的重载

接下来，我们先看一下，如何对一个既有模块的方法进行重载的操作，还是以我们的book_store模块为例，我们先给book_store.book对象添加要给新的类方法：log_book_name

1
2
3

@api.one
def log_book_name(self):
    _logger.info(f"图书名称：{self.name}")

非常简单，就是打印一下本书的名字，然后为了方便测试，我们在使用odoorpc远程调用一下这个方法：

1
2
3
4
5
6
7
8
9

odoo = odoorpc.ODOO(host=host, port=port)
odoo.login(db, user, password)

# 调用log_book_name方法

book_obj = odoo.env['book_store.book']
book = book_obj.browse(1)

book.log_book_name()

运行测试，可以看到，当我们修改book的内容时，后台日志会输出本图书的名字。

重载

现在，我们希望能够把作者的名字也添加到日志中，但是不修改Book类的代码。这时候我们需要新建一个类，继承自Book(这里为了好区别，新建要给代码文件，名为SubModel.py):

1
2
3
4
5
6
7
8

class SubBook(models.Model):

    _inherit = "book_store.book"

    @api.one
    def log_book_name(self):
        """重载父类方法"""
        _logger.info(f"图书名称{self.name},作者：{self.author.name}")

重启升级模块儿后，通过rpc调用log_book_name方法可以看到，输出的日志已经带有作者信息了：

复用父类调用的结果

如果希望在父类方法返回的结果上进行修改，可以通过super方法进行调用，这个例子中由于父类方法并不返回值，因此只是调用了一下父类，并没有真正的复用：

1
2
3
4
5

@api.one
def log_book_name(self):
    """重载父类方法"""
    res = super(SubBook,self).log_book_name()
    _logger.info(f"图书名称{self.name},作者：{self.author.name}")

可以看到，父类方法也被调用：

私有方法不会被重载

有个例外，就是如果你的方法是私有方法(双下划线开头)，那么重载将不会起作用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Book(models.Model):
    ...
    @api.one
    def log_book_name(self):
        self.__log_book_name()

    def __log_book_name(self):
        print('Book私有方法')
        _logger.info(f"图书名称：{self.name}")

class SubBook(models.Model):
    ...
    def __log_book_name(self):
        print('SubBook私有方法')
        _logger.info(f"图书名称{self.name},作者：{self.author.name}")

将只有Book的方法会被调用，这点跟Python本身的继承表现是一致的。

多层重载

细心的朋友可能会有疑惑，如果多个子类都重载了父类的方法，那么会执行哪一个呢？下面我们就来揭晓这个问题的答案。

上面我们创建的一个子类SubBook，这里我们再次创建一个子类SubBook2，方法跟SubBook类似：

1
2
3
4
5
6
7
8
9
10

class SubBook2(models.Model):

    _inherit = "book_store.book"

    @api.one
    def log_book_name(self):
        """重载父类方法"""
        # res = super(SubBook,self).log_book_name()
        _logger.info(f"SubBook2的方法：图书名称{self.name},作者：{self.author.name}")

运行rpc脚本，输出结果如下：

由此可以看出，当有多个子类重载了同一个父类方法时，只有最后加载的那个子模块的方法会被调用。

指定重载

如果，在子类SubBook中调用了父类的方法，同时子类SubBoo2也调用父类方法，那么会出现什么结果呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class SubBook(models.Model):

    _inherit = "book_store.book"

    @api.one
    def log_book_name(self):
        """重载父类方法"""
        # res = super(SubBook,self).log_book_name()
        _logger.info(f"SubBook的方法：图书名称{self.name},作者：{self.author.name}")
        super(SubBook,self).log_book_name()

class SubBook2(models.Model):

    _inherit = "book_store.book"

    @api.one
    def log_book_name(self):
        """重载父类方法"""
        # res = super(SubBook,self).log_book_name()
        _logger.info(f"SubBook2的方法：图书名称{self.name},作者：{self.author.name}")
        super(SubBook2,self).log_book_name()

输出：

可以看到，三个方法都被调用了。因此，在子类中使用Super调用父类方法，会调用继承链上所有的重载方法。

那么，我们如何只通过子类SubBook2调用父类方法，而不触发SubBook中的同名方法呢?

答案是SubBook2中直接条用SubBook的父类方法：

1

super(SubBook,self).log_book_name()

细心的朋友一定注意到了，odoo中的方法经常会看到由api装饰的方法，这是Odoo从8.0起引入的新的编程API，那么为什么要引入新API呢，这要从更早的历史说起。

7.0之前的API

当年那是Odoo还叫OpenERP的时代，OpenObject对象的方法通常都需要带着几个固定的参数：cr,uid,ids,context等等，写起来很繁琐，比如下面的例子：

1
2

def btn_import(self,cr,uid,ids,context=None):
    ...

到了8.0，可能Odoo官方的开发人员也觉得这样写起来太繁琐了，于是乎，他们引入了新API，封装在api.py文件中，主要有一下几种类型：

• model
• multi
• one
• constrains
• depends
• onchange
• returns

下面我们就这几种类型进行详细的介绍。

one

作用： 表示被封装的方法接受单一的对象，用于处理一些单个对象的方法。
返回值： [None](部分不负责的教程里说不返回值)
v7版本写法： def funct(self,cr,uid,ids,context)

举例：
视图文件中添加一个按钮，对应的触发方法：

1
2
3

@api.one
def button_test(self):
    self.name = "xxx"

multi

作用：表示被封装的方法接收一个集合对象，正好与one对应。
返回值： 被封装方法的返回值
v7版本写法： model.method(cr, uid, ids, args, context=context)

multi典型的用法即odoo对象的write方法：

1
2
3
4

@api.multi
def write(self, vals):
    res = super(Book, self).write(vals)
    return res

这里的self是一个集合对象，vals是待更新的字段和值的字典，这里的例子我们没有用到self，只是调用了父类的write方法，将vals写入到数据库中。如果我们要修改某个值，需要对self进行迭代，然后更新字段的值。

model

作用：self代表一个记录集合，但内容与记录集无关，只是与model类型相关。
返回值： 被装饰方法的返回值
v7版本写法： model.method(cr, args)

典型应用是对象的create方法：

1
2
3

@api.model
def create(self,vals):
    return super(Book,self).create(vals)

self是个对象集合，但是creat方法内部却与self这个集合没有关系，只是用了self的model类型，将vals的值进行创建操作。

contrains

作用：给某个字段添加限制条件
v7版本：是通过_constrains属性关联验证方法的方式实现

到了新API，不需要添加_constrains属性了，直接给校验方法添加constrains装饰即可。

1
2
3
4
5
6

age = fields.Integer(string="age")  

＠api.constrains('age')
def _check_age(self):
    if self.age<16:
        raise ValueError(_('Age must be older than 16'))

这样就限制了age字段只能输入比16大的数据。

另外一种constrains

odoo支持另外一种添加限制的方式，即通过sql约束的方式。方法是在odoo类对象中添加_sql_constrains属性，值是一个包含了元组的列表，元组的三个值分别是约束名，约束条件和警告信息，看一个例子：

1
2
3
4
5
6
7
8

_sql_constraints = [
    ('name_description_check',
     'CHECK(name != description)',
     "The title of the course should not be the description"),
    ('name_unique',
     'UNIQUE(name)',
     "The course title must be unique"),
]

这样做的好处是，在数据库层面就限制了数据的校验，而不是在代码层面的校验，显然效率会更高。缺点是在添加限制之前，数据库中不能存在违反约束的数据，否则约束会添加失败。

depends

depends主要用于compute方法，v8当中已经取消了function字段，对于任何fields都可以通过添加compute属性动态赋值。depends就是用来标该方法依赖于哪些字段的装饰。

1
2
3

@api.depends('date')
def _get_book_age(self):
    self.age = (datetime.now().date() - self.date).days

对于compute方法来说，加不加depends装饰的区别在于，加了depends的方法会在依赖的字段发生改变时重新计算本字段的值，而不加depends的方法只在触发的第一次调用，也就是说不会持续更新。

returns

returns的用法主要是用来指定返回值的格式，它接受三个参数，第一个为返回值的model，第二个为向下兼容的method，第三个为向上兼容的method。

第一个参数如果是对象本身，则写’self’,如果是其他对象，则写其他对象名如：@api.returns(‘ir.ui.view’)。

例如：

1
2
3
4
5
6

@api.multi    @api.returns('mail.message', lambda value: value.id)
def message_post(self, **kwargs):
    if self.env.context.get('mark_so_as_sent'):
        self.filtered(lambda o: o.state == 'draft').with_context(tracking_disable=True).write({'state': 'sent'})
        self.env.user.company_id.set_onboarding_step_done('sale_onboarding_sample_quotation_state')
    return super(SaleOrder, self.with_context(mail_post_autofollow=True)).message_post(**kwargs)

returns主要用于确保新旧API返回值的一致，并不常用。

odoo支持继承，可以方便地像python语言中的继承拓展既有的对象属性，这篇第一部分将介绍Odoo中的继承，搜索也是Odoo中常见的操作之一，第二部分将介绍Odoo中的搜索逻辑。

继承

这里我们还是沿用前面的书店模块，之前我们有了图书这个模型，现在我们希望书店能够上架一种新的图书-电子书，电子书区别于纸质书的特点就是无需纸张，但是需要规定电子书的格式，比如常见的epub,mobi,awz3等等，因此，我们需要在前边的图书模型上进行拓展，又不能影响既有图书的属性，怎么办，这就需要用到了继承，我们可以新建一个电子图书的模型，继承自图书，新增电子书属性。

继承的方式

odoo的继承不是像python的继承直接在class的括号中添加继承类，而是在类属性_inherit中添加，如上面的例子，代码就可以写成下面的样子：

1
2
3
4
5

class eBook(models.Model):
    _inherit = "book_store.book"

    etype = fields.Selection(selection=[('mobi', 'Mobi'), ('epub', 'Epub'), (
        'awz', 'Awz3')], string='电子书格式', default='epub')

需要注意的是，上面的这种方式，在实际数据库中还是同一张表的扩展，也就是说，这种方式不能实现我们前面所说的效果。这种继承方式的使用场景是继承自odoo官方模块，为原有模块进行扩展而不修改源码，这样可以保持官方代码的干净，避免带来污染。如果想要使用另一张表，则需要给新模型起一个新的名字：

1
2
3
4
5
6

class eBook(models.Model):
    _inherit = "book_store.book"
    _name = "book_store.ebook"

    etype = fields.Selection(selection=[('mobi', 'Mobi'), ('epub', 'Epub'), (
        'awz', 'Awz3')], string='电子书格式', default='epub', help='')

这样的数据库中就会多出一张表，包含所有的book_store_book表中的字段，并且还有ebook对象新增的字段：

两种方式各有优缺点，请读者根据实际情况灵活运用。

多继承

Odoo也支持多继承，方法是把_inherit的值变成一个要继承的列表：

1
2
3
4
5
6

class sBook(models.Model):
    _inherit = ["book_store.book","book_store.ebook"]
    _name = "book_store.sbook"

    etype = fields.Selection(selection=[('mobi', 'Mobi'), ('epub', 'Epub'), (
        'awz', 'Awz3')], string='电子书格式', default='epub', help='')

继承的顺序从左到右

属性继承

Odoo还有另外的一种继承方式，不指明要继承的对象，而是指定本对象的某个Many2one的字段继承自一个其他对象，被继承的该对象的字段自动加载到本对象中，并且当其中任何一方的值发生变化时，都会同步到另一方中，这里把这种继承方式命名为属性继承。说的比较抽象，接下来我们举个栗子：

新建对象会员图书(sbook)，但是此对象不继承任何一个对象，只是在属性中添加一个对电子图书(ebook)的Many2one关联字段，并在_inherits属性中声明这个字段：

1
2
3
4
5
6
7

class sBook(models.Model):
    
    _name = "book_store.sbook"
    _inherits = {'book_store.ebook': 'ebook_id'}

    ebook_id = fields.Many2one(
        'book_store.ebook', string='ebook', ondelete='restrict', required=True, help='')

_inherits属性是个字典，key为Many2one字段中外关联的对象名，value为Many2one的字段名。然后我们为sBook对象编写一个视图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<record model="ir.ui.view" id="book_store.slist">
      <field name="name">会员图书列表</field>
      <field name="model">book_store.sbook</field>
      <field name="arch" type="xml">
        <tree>
          <field name="name"/>
          <field name="author"/>
          <field name="date"/>
          <field name="price"/>
        </tree>
      </field>
    </record>

    <record id="book_store.sbook_form" model="ir.ui.view">
      <field name="name">会员图书</field>
      <field name="model">book_store.sbook</field>
      <field name="arch" type="xml">
        <form string="图书详情" class="">
          <sheet>
            <h1>
              <field name="name" invisible="0"/>
            </h1>
            <group>
              <field name="ebook_id"/>
              <field name="author" invisible="0"/>
              <field name="date" invisible="0"/>
              <field name="price" invisible="0"/>
              <field name="ref" invisible="0"/>
            </group>
          </sheet>
        </form>
      </field>
    </record>

    <record model="ir.actions.act_window" id="book_store.saction_window">
      <field name="name">会员图书</field>
      <field name="res_model">book_store.sbook</field>
      <field name="view_mode">tree,form</field>
    </record>

然后升级模块，可以看到如下图：

好像没有什么特别之处。。。别急，我们来修改一下会员图书的名字，将其改为”流浪地球-最终版”，并把作者改回”刘慈欣”:

发现了没有，ebook属性的名字，随着我们会员图书的名字的改名而改名，并且ebook的作者字段也变成了我们所选的”刘慈欣”。

这就是Odoo中比较著名的模板继承方式，典型的应用就是官方模块中的产品模板和产品的关系，在Odoo原生模块中，有一个对象叫做product.template，顾名思义就是产品模板，指的是一系列产品的通用模板属性。而在销售、采购和仓储的实际运用中，使用的是叫product.product的对象，这个才是真正的产品。product.product和product.template的关系就是我们上面所说的属性继承的关系，product.pruduct中一个many2one的字段product_tmpl_id关联的就是product.template，当product.template中的属性发生变化时，没有被重写（注意，product.product对象中有些字段覆盖了product.template中的字段）的属性就会跟着变化，形成了一种有趣的引用关系。关于这点，读者可以到产品中修改一下属性进行体会。

搜索

Odoo中最常用的搜索就是位于Form页面右上角的搜索框了，搜索框的逻辑包括过滤、分组，基本的操作可以通过XML文件配置出来，有些比较高级的搜索需要通过代码的方式实现。

基本搜索

默认情况下，搜索框只有一个搜索对象的name字段的功能：

如果想要搜索其他字段，就需要在filter中自行选择要搜索的字段和需要的操作符，进行过滤搜索：

可供选择的操作符包括如下几种：

• 包含
• 不包含
• 等于
• 不等于
• 已设置
• 未设置

这样基本可以满足用户的需求。

这里可选字段包括了本对象中所有可存储的字段，也就是在数据库中可搜索的字段，对于compute类型的字段来说，不可以搜索，也就不会出现在备选字段中。

用户可以点击favorites进行收藏，将当前的筛选条件进行保存，以供下次搜索使用。

自定义搜索

基本搜索满足了用户的基本搜索需求，但是不够简洁快速，如果想要更快捷的方式，就需要自定义搜索条件了。自定义搜索条件，基本可以通过配置XML文件实现，下面就详细介绍一下这几种搜索方式。

Filter

顾名思义，Filter就是过滤，具体的定义规则就是在XML文件中定义一个search视图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<record id="book_store_search_view" model="ir.ui.view">
      <field name="name">图书搜索</field>
      <field name="model">book_store.book</field>
      <field name="arch" type="xml">
        <search string="图书搜索">
          <field name="author"/>
          <field name="date"/>
          <field name="price"/>
          <separator/>
          <filter name="liu_book" string="大刘小说" domain="[('author','=','刘慈欣')]" />
          <separator/>
          <group expand="0" string="Group By">
            <filter name="author" string="按作者分组" domain="[]" context="{'group_by':'author'}"/>
          </group>
        </search>
      </field>
    </record>

search结点中的三种标签：

• field: 按字段搜索，即你输入值以后，下拉进行筛选：
  

• filter: 按照预定的domain进行过滤：
  

• group: 根据字段进行分组：
  
  分组的做法是在context属性的中传入’group_by’的字段值。

计算字段的搜索

在Odoo中还有一类字段，是不存储在数据库中的，而是通过计算的方式在需要显示的时候计算出来的值。这类字段通常会使用compute属性，compute对应的是一个方法，这个方法在字段被显示和调用时调用。

沿用以前的模块，我们给book模型添加一个书龄的属性，该属性是由计算出来的：

1
2
3
4
5

age = fields.Integer('书龄', compute="_get_book_age", search="_search_ages")

@api.depends('date')
def _get_book_age(self):
    self.age = (datetime.now().date() - self.date).days

在form页面中会显示出该书的书龄：

你在filter工具中是看不到该字段的，那么我们如何对书龄进行搜索呢？

这里需要用到我们前面说过的一个字段的一个属性，search，search是用来重载字段被搜索时的方法的。搜索书龄，我们可以这么写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@api.model
def _search_ages(self, operator, operand):
    """search方法"""
    if operator not in ('>', '>=', '<', '<=', '='):
        return []
    if type(operand) not in (float, int):
        return []
    start_date = datetime.now().date() - timedelta(days=operand)
    ops = {
        ">": "<",
        ">=": "<=",
        "<": ">",
        "<=": ">=",
        "=": "="
    }
    return [('date', ops[operator], start_date)]

search方法接收两个参数，一个操作符，一个是操作数，操作符根据字段的类型不同而不同，我们这里是integer类型，所对应的操作符就是大于小于和等于等操作符。search方法的返回值是一个domain对象，也就是有元组组成的列表。odoo会根据domain对记录进行过滤，并显示结果，最后的效果图如下：

。

前面一篇文章，我们介绍了如何从无到有地创建一个模块，本篇将介绍Odoo中常见得几种字段类型和基本的视图类型。

字段类型

由于Odoo使用了自己编写的ORM框架，因此它有着自己的一套与数据库映射的关系逻辑，简单地说就是由简单字段关系和复杂字段关系组成的。简单的字段关系比如Char,Integer,Float等，复杂字段关系如Many2one，Many2many等。下面就常见的几种字段类型进行简要的介绍。

通用字段属性

有些属性是字段共同拥有的，如下表：

Char

字符类型，对应数据库中varchar类型，除了通用类型外接收另外两个参数：

• size: 字符长度，超出的长度将被截断
• trim: 默认True，是否字段值应该被去空白。

Text

文本类型，对应数据库中的text类型，不限长度，没有额外的参数。

Html

Html类型，用于存储一段HTML代码，对应数据库中的text类型，接收下面几个参数：

• sanitize：是否过滤安全字符(默认True)
• sanitize_tags： 是否过滤的html标签（只接收白名单列表标签，默认True）
• sanitize_attributes： 是否过滤的html属性（只接收白名单列表属性，默认True）
• sanitize_style： 是否过滤style属性(默认False)
• strip_style： 是否去除style属性中的空白(默认False)
• strip_classes:是否去除class属性中的空白（默认False)

Date

日期类型，对应于数据库中的date类型，该字段包括如下几个特有属性：

• today: 当前日期
• context_today： 返回客户端时区的当前时间
• to_date: 将时间值转换为date类型的时间
• to_string: 将时间值转为文本

Datetime

时间类型，对应于数据库中的timestamp类型，该字段包括如下几个特有属性：

• now: 当前时间
• today: 当前日期
• context_timestamp： 客户端时区的当前时间戳
• to_datetime：将时间值转换成datetime类型
• to_string： 将时间值转成文本

Binary

二进制文件类型，接收三个参数：

• prefetch: 默认False
• context_dependent：默认True
• attachment：默认False，是否作为附件存储

二进制文件作为附件存储时存在服务器指定的文件夹路径中，否则存在数据库中，对应的数据库类型为bytea.

Selection

下拉选择类型，多选一类型，不同于Many2one类型，Selection类型在数据库中对应的类型是int4或varchar类型。

除了通用的属性，另外接收2个参数：

• selection： 可选的范围值，值和名称组成的元组列表。
• validate: 默认True，是否写入时校验。

Selection包含如下的属性或方法：

• get_values: 返回可选的值列表。

Reference

引用类型(继承自Selection)，对应数据库类型varchar，Reference字段不同于Many2*类型的地方在于Many2*类型的字段的comodel是固定的，而Reference可以提供一种动态的选择。

比如，我们给模型book添加了一个ref字段，类型为Reference，关联两种类型，一个出版商，一个作者，那么ref字段就可以供用户在使用的时候自行选择绑定的记录：

Many2one

多对一类型，对应于数据库中的类型是int4，相当于数据库主表中的外键。可选的参数如下：

• comodel_name： 被关联的对象
• domain： 过滤条件
• context： 上下文
• ondelete： 删除时的选项，可选set null(本字段设置null)，restrict(严格控制，只有先删除本字段才允许删除)和cascade(级联删除本字段关联的所有记录)。
• auto_join： 当字段被搜索时是否自动聚合，默认为False
• delegate: 当设置为True时，关联对象的所有字段将在本字段变得可用。

One2many

一对多类型，返回值是一个关联对象的集合。接收的参数列表如下：

• comodel_name： 关联对象名称
• inverse_name： 在Many2one对象中的字段名 默认为None
• domain： 过滤条件
• context： 上下文
• auto_join： 当字段被搜索时是否自动聚合，默认为False
• limit： 读取的条数限制
• copy: 是否允许拷贝（默认False)

定义一个One2many对象时，要在关联的对象中定义一个Many2one的字段类反过来关联本对象。比如，一个出版商签约了多个作者，那么出版商和作者就是一对多的关系（当然也可以定义为多对多的关系），用代码表示出来就是下面这个样子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class Author(models.Model):

    _name = 'book_store.author'

    name = fields.Char('名称', help='作者名称')
    age = fields.Integer('年龄')
    publisher_id = fields.Many2one(
        'book_store.publisher', string='签约出版商', ondelete='no action', required=True, help='')


class Publisher(models.Model):

    _name = "book_store.publisher"

    name = fields.Char('名称', help='出版商名称')
    signed_authors = fields.One2many(
        'book_store.author', 'publisher_id', string="签约作者")

对于One2many和Many2many对象，有几种特殊的操作，就是在关联对象中创建或是修改本对象时的操作：

• (0,0,{values}) 根据values里面的信息新建一个记录。
• (1,ID,{values})更新id=ID的记录（写入values里面的数据）
• (2,ID) 删除id=ID的数据（调用unlink方法，删除数据以及整个主从数据链接关系）
• (3,ID) 切断主从数据的链接关系但是不删除这个数据
• (4,ID) 为id=ID的数据添加主从链接关系。
• (5) 删除所有的从数据的链接关系就是向所有的从数据调用(3,ID)
• (6,0,[IDs]) 用IDs里面的记录替换原来的记录（就是先执行(5)再执行循环IDs执行(4,ID）

举例来说，就是我希望在按钮的触发事件中同时创建一个出版商和多个作者，而不是一步一步地创建，就可以这么写：

1
2
3
4
5
6
7
8

@api.one
def btn_test(self):
    """测试方法"""
    _logger.info(f"测试创建出版商和作者")
    self.env['book_store.publisher'].sudo().create({
        "name": "超新星出版社",
        "signed_authors": [(0, 0, {'name': '本杰明 巴顿', 'age': 90}),(0,0, {'name': '刘天然', 'age': 28})]
    })

Many2many

多对多类型，参数列表如下：

• comodel_name：关联对象名
• relation：关系表名
• column1：本对象的关联字段名
• column2：关联对象的关联字段名
• domain： 过滤条件
• context： 上下文
• limit: 读取条数限制

与One2many类似，但不同的是参数中多了一个relation，用来存储多对多关系的表名，需要注意的是，relation，column1和column2可以不提供，odoo会根据model名称自动生成，但是需要保证column1和column2是不同的值。

Id

integer类型，对应数据库中的int4，一般不需要定义。

视图类型

上面讲述了字段的列表，接下来我们看一下常见的视图类型。

最常见的视图有如下几种：

• form视图
• tree视图
• kanban视图
• graph视图
• gatt视图
  …

因为视图是前端展示用的，所以视图的种类多种多样，odoo也可以支持自定义视图，这就给了开发人员很大的灵活拓展性。每种视图的结构不一样，这里只介绍最常见的form和tree视图。

form 视图

一般的视图都是在record节点中，由arch结点包裹：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<record id="book_store.book_form" model="ir.ui.view">
      <field name="name">图书</field>
      <field name="model">book_store.book</field>
      <field name="arch" type="xml">
        <form string="图书详情" class="">
          <header>
            <button type="object" name="btn_test" string="测试按钮"/>
          </header>
          <sheet>
            <h1>
              <field name="name" invisible="0"/>
            </h1>
            <group>
              <field name="author" invisible="0"/>
              <field name="date" invisible="0"/>
              <field name="price" invisible="0"/>
              <field name="ref" invisible="0"/>
            </group>
          </sheet>
        </form>
      </field>
    </record>

form视图就包括，header、sheet等部分，然后group节点可以对field进行分组，字段field的属性用来控制field的显示。

tree视图

把form视图代码中的form替换成tree就成了我们的列表视图，这里称之为列表视图是因为tree视图并不是真正的”树视图”,真正的树视图是可以展开的。

1
2
3
4
5
6
7
8
9
10
11
12

<record model="ir.ui.view" id="book_store.list">
      <field name="name">图书列表</field>
      <field name="model">book_store.book</field>
      <field name="arch" type="xml">
        <tree>
          <field name="name"/>
          <field name="author"/>
          <field name="date"/>
          <field name="price"/>
        </tree>
      </field>
    </record>

tree视图相对比较简单，一般就是对本对象要显示的属性的罗列，外加一些权限显示的控制。

其他类型的视图，读者可以在官方自带的模块中找到例子，这里就不列举了。

Odoo的视图层是个复杂的系统，其中的关于视图的定义，展示逻辑等都相对比较复杂，等有机会再另起一篇进行讨论。

本教程示例代码

name get方法

name_get方法在odoo中用于获取模型的显示名称，当在form窗口中打开一个model时，会被调用，返回值为一个包含id和名称的元组组成的列表。

1
2
3
4
5

@api.multi
    def name_get(self):
        values = super(Demo, self).name_get()
        _logger.info(f"name_get方法返回的结果:{values}")
        return values

调用返回的结果：

name_search方法

name search方法接受4个参数：

• name: 被搜索的关键字
• args: 限定条件domain
• operator: 操作符，可选的参数有：=,!=,>,>=,<,<=,like,ilike,in,not in,child_of,parent_left,parent_right
• limite: 搜索结果的条数。

name search在Many2*类型的模型上显示时被调用，返回结果是由id和repr的文本组成的元素列表。

从结果上看，name_search方法并没有返回一个带文本的列表，而是一个延迟计算的函数，这是因为，在原生name_search方法中调用了lazy_name_get方法导致的，从这里也可以看出name_search和name_get方法的关系，即，由name_search方法限制条件过滤，然后再把结果传给name_get方法进行显示。

低阶_name_search方法

其实在更底层的层面上，还有一个_name_search方法，与name_search方法不同的是_name_search方法接受额外的一个参数：name_get_uid，这个参数的作用是指定一个调用_search和lazy_name_get方法的用户ID，用来解决当前用户权限不足的问题。

比如当前我有一个模型osc.person，没有任何一个组有权限访问，正常访问会试如下的界面：

当我们给_name_search方法传一个uid=1进去的时候：

1
2
3
4
5
6

@api.model
    def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
        _logger.info(f"私有name search方法被调用，参数：{name,args,operator}")
        res = super(Person, self)._name_search(name, args, operator, limit, 1)
        _logger.info(f"结果：{res}")
        return res

就可以正常显示了。

为什么要重写一个教程

google搜了一下互联网上目前还没有一份真正实用，免费的中文教程。曾经在博客园写过几篇，但是没能坚持下来，现在正好有时间，就争取写一个图文并茂，力求面面俱到的教程吧，也权当是对自己知识的一个重新梳理。

章节目录

1. 第一章 环境的搭建及入门
2. 第二章 字段类型和基本视图类型
3. 第三章 继承与搜索
4. [第四章 新API的介绍]
5. [第五章 重载]
6. [第六章 动作]

关于Odoo

笔者接触odoo已经有四五年的时间了，从最初的OpenERP 7到现在的odoo 12，中间有过一段时间的远离，现在机缘巧合下又重新出发。Odoo是一个优秀的开源ERP框架，有这诸多的优点，部署简单、开发迅速、可扩展性好，当然一个事物有有点就必定会有缺点，缺点就是语言小众(Python：怪我咯？)，资料奇少，最重要的一点也是最致命的一点就是它真的只是一个框架，虽然有众多的第三方模块加成，但是真的无法做到开箱即用，这也就对它的潜在使用者造成了门楷，看起来美好，像用起来却不得不找专业的公司实施或者招一个懂行的人进行开发。

Odoo的国内市场，目前（2019）有了一个领航人，浪潮集团，可能会对国内的生态带了一些积极的影响。但是就目前的态势来看，浪潮的思路也是做SAAS模式。个人并不看好这种模式，Odoo社区版虽然免费，但实施起来却需要相当的持续的投入，这对企业的长远来说并不算是一个性价比高的选择。笔者曾经供职的一家企业，在2014年开始使用Odoo，后来因为技术的支持不到位（也许有资金层面的原因），现在据说已经退回到金蝶用友的软件了。对于国内一些靠Odoo实施生存的企业来说，个人也持悲观模式，其实Odoo入华已经年头不少了，从6.0（2012）开始国内就有先驱开始做这块的市场，现在7年已经过去了，依旧没有看到一家能够壮大的专业实施公司。这里边需要思考的东西挺多，当官方都吃不饱(甚至跑过来跟代理商抢饭吃)的时候，处在下游的公司就更难说活得美好了。

个人觉得，Odoo最好的使用模式，是公司或者集团内部，由IT团队进行支持开发，然后不断迭代，内化成自己公司的内部一套ERP系统是最合适的。IT团队懂技术，产品团队优化需求，再经过持续迭代和优化，最终能够成为一套不错的解决方案。因为IT团队本身就是需要投入，这样就能将成本摊平，提高软件使用的性价比。本系列教程也是从技术层面出发，希望能多的人能够了解到这套系统的架构，从中学到一些不错的思路，而对于商业化层面的东西，我只能说，偶尔兼个职也是不错的。

环境的搭建

关于Odoo的环境搭建，其实这里不想说太多了，网上关于如何搭建的教程真的挺多了。这里只提供一下笔者开发的模式。

个人使用的开发模式是，VM虚拟机+VSCode的方式，VM虚拟机安装Ubuntu系统，通过deb包的方式进行Odoo的安装，然后通过VM挂在共享文件夹，这样就可以实现在Win下开发，在Ubuntu上进行调试的模式。

关于调试，这是使用的命令行的方式，需要输出的时候就可以Print或者logger一下。

需要详细安装步骤的，请参考这里

第一个模块

本系列教程将告诉大家如何做一个书店，所以我们将给这个模块命名为book_store。模块的命名一定要体现出模块的用途，且不要跟已有的模块名重名，所以在模块前加上公司名是一个不错的选择。

1

odoo scaffold book_store .

这个命令是odoo提供的脚手架，scaffold是命令，后面跟模块名和模块路径，执行完命令的结果如下：

• controllers文件夹主要是一些HTTP请求相关的业务逻辑。
• models是模型文件夹，业务的模型都放在这里。
• security 权限相关的文件。
• views 视图文件夹，关于界面布局的逻辑在这里。
• __init__ 熟悉python的都懂，不说了
• __manifest__ 9.0之前叫__openerp__.py，Odoo模块必须的文件，包含必要的模块信息。

接下来我们修改一下模块的信息，修改__manifest__.py文件，如以下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# -*- coding: utf-8 -*-
{
    'name': "book_store",

    'summary': """
        demo module for tutorial.""",

    'description': """
        This module is writing for who wants learn odoo developments.
    """,

    'author': "KevinKong",
    'website': "http://mixoo.cn",

    # Categories can be used to filter modules in modules listing
    # Check https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/data/ir_module_category_data.xml
    # for the full list
    'category': 'tutorial',
    'version': '0.1',

    # any module necessary for this one to work correctly
    'depends': ['base'],

    # always loaded
    'data': [
        'security/ir.model.access.csv',
        'views/views.xml',
        # 'views/templates.xml',
    ],
    # only loaded in demonstration mode
    'demo': [
        'demo/demo.xml',
    ],
    "application": True
}

关于这个字典里的属性，注释中大多都解释了。写完这个，我们可以验证一下Odoo是否能够正确加载我们的模块。

模块的路径需要写到配置文件中，如果是笔者这种安装方式，配置文件在/etc/odoo/odoo.conf

启动odoo后，打开debug模式(URL/web?debug)，在应用-更新本地模块中点击更新：

然后再搜素book_store:

这样就说明odoo正确的加载了我们的模块。

第一个模型

模型对应的是数据库中的数据表，但是模型的概念比表跟多，很多属性不存储在数据库中。

我们新建一个书的模型，首先，书有多种属性，这里我们先写如下几种：

• 名称
• 作者
• 日期
• 定价

名称是Char类型，作者这里先设置为Char类型，日期是Datetime，定价就是Float。

1
2
3
4
5
6
7

class Book(models.Model):
    _name = 'book_store.book'

    name = fields.Char('名称', help='书名')
    author = fields.Char('作者', help='作者')
    date = fields.Datetime("出版日期", help="日期")
    price = fields.Float("定价", help="定价")

然后我们需要给这个模型设置一个界面，编辑views文件夹下的view.xml文件，添加如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

<odoo>
  <data>
    <!-- explicit list view definition -->

    <record model="ir.ui.view" id="book_store.list">
      <field name="name">图书列表</field>
      <field name="model">book_store.book</field>
      <field name="arch" type="xml">
        <tree>
          <field name="name"/>
          <field name="author"/>
          <field name="date"/>
          <field name="price"/>
        </tree>
      </field>
    </record>

    <record id="book_store.book_form" model="ir.ui.view">
      <field name="name">图书</field>
      <field name="model">book_store.book</field>
      <field name="arch" type="xml">
        <form string="图书详情" class="">
          <sheet>
            <h1>
              <field name="name" invisible="0"/>
            </h1>
            <group>
              <field name="author" invisible="0"/>
              <field name="date" invisible="0"/>
              <field name="price" invisible="0"/>
            </group>
          </sheet>
        </form>
      </field>
    </record>


    <!-- actions opening views on models -->
    
    <record model="ir.actions.act_window" id="book_store.action_window">
      <field name="name">图书</field>
      <field name="res_model">book_store.book</field>
      <field name="view_mode">tree,form</field>
    </record>
   

    <!-- server action to the one above -->
    <!--
    <record model="ir.actions.server" id="book_store.action_server">
      <field name="name">book_store server</field>
      <field name="model_id" ref="model_book_store_book_store"/>
      <field name="state">code</field>
      <field name="code">
        action = {
          "type": "ir.actions.act_window",
          "view_mode": "tree,form",
          "res_model": self._name,
        }
      </field>
    </record>
    -->

    <!-- Top menu item -->

    <menuitem name="浪矢书店" id="book_store.menu_root"/>

    <!-- menu categories -->

    <menuitem name="书店" id="book_store.menu_book" action="book_store.action_window" parent="book_store.menu_root"/>
    <menuitem name="分类" id="book_store.menu_category"  parent="book_store.menu_root"/>

    <!-- actions -->
    <!--
    <menuitem name="List" id="book_store.menu_1_list" parent="book_store.menu_1" action="book_store.action_window"/>
    <menuitem name="Server to list" id="book_store" parent="book_store.menu_2" action="book_store.action_server"/>
    -->
  </data>
</odoo>

XML文件写完以后，在应用-模块中点击升级模块对模块进行升级。

当修改了py文件时，需要重启odoo进程，而修改了xml等静态文件则需要升级模块。

升级完成后，进入odoo发现没有我们写完的menu。这是因为，我们只创建了model却没有给任何一个组赋予访问这个模型的权限，因此我们无权查看这个模块的界面。

给book模型添加权限，编辑security文件夹中的ir.model.access.csv文件，csv文件从左右到依次是，id，名称，模型id，组ID，读权限，写权限，创建权限、删除权限。

其中模型是model_加上模型名组成的，其中的点号要换成下划线。

1
2

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_book_store_book,book_store.book,model_book_store_book_store,base.group_user,1,1,1,1

然后我们重新升级模块。

就可以看见我们自定义的菜单出来了：

点击菜单我们可以创建图书：

和查看图书列表：

这样我们的第一个模块就完成了。

开发者调试模式

正常情况下，代码文件发生改变需要重启odoo进程或升级模块，对开发者来说，频发的Ctrl+C和upgrade有时候比较费事，Odoo提供了一种免重启的模式，当代码文件发生变化时自动重载并更新视图文件，大大简化了开发的步骤。

启动这个模式的命令是在启动odoo的命令后添加一个–dev参数:

1

odoo -c /etc/odoo/odoo.conf --dev=all

注意：可能会碰到下面的错误：

1

'inotify' module not installed. Code autoreload feature is disabled

这是因为缺少依赖库inotify, 使用pip命令安装即可：

1

pip install inotify

对于odoo，国内很少能看到较为规范的自动化运维流程，基本还停留在人工手动更新的时代，相对于互联网时代难免显得有些落后了，本篇文章将以gitlab的ci/cd功能为蓝本，介绍一个自动化运维odoo开发的可操作流程。

为什么是Gitlab

关于CI/CD，像github等都有自己的一套工具，但是由于github的私有仓库还是有人头的限制，所以这里我们选择了没有人数限制的gitlab。至于国内一些git仓库，鉴于一些众所周知的原因，不(最)做(好)推(不)荐(用)。

创建Gitlab的仓库

Gitlab注册免费，仓库免费，且没有数量限制，这里我们创建一个Project，命名为demo.

然后把自己的代码上传到git仓库中：

创建Runner

Runner，就是运行你项目代码的容器，有两种，一种是gitlab官方提供的共享Runner，有运行次数限制。另一种是自己创建的本地Runner，没有次数限制。因为我们要运行的是odoo，环境搭建相对复杂，这里就使用自己创建的Runner而不用共享Runner了。

在Settings-CI/CD-Runner中，关闭共享Runner，并创建自己的Runner。Gitlab中有关于创建Runner的详细教程，这里不再赘述，需要注意的是推荐使用包安装而不是源码安装的方式进行，因为源码安装可能会有众多坑需要趟。

创建完Runner并启动后，可以在gitlab中看到就绪的Runner:

创建.gitlab-ci.yml文件

.gitlab-ci.yml文件是gitlab进行CI/CD操作的脚本文件，关于yml文件的写法请参考gitlab文档。

这里举例说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

stages: 
  - test
  - deploy

unit:
  tags:
    - OSC
  stage: test
  script: 
    - odoo --test-enable -d odootest -u osc_demo --workers=0 -c /etc/odoo/odootest.conf --log-level=test --stop-after-init


deloy:
  tags:
    - OSC
  stage: deploy
  script:
      - sudo cp -rf $CI_BUILDS_DIR/Z4ysM4if/$CI_CONCURRENT_PROJECT_ID/orssica/osc_demo /home/ubuntu/odoo/odoo-dev/custom/addons/
      - sudo service odoo restart

• stages: 表明pipline的阶段，一般为build,test,delpoy三个。
• unit和deloy是我们自定义的两个job，gitlab支持编写无数个job。
• tags：指明要运行这个job的Runner标签，这里的OSC代指得就是我们之前创建得Runner.
• script: 要运行的脚本命令，这里我们在unit这个job中运行单元测试，然后再deploy这个job中拷贝代码，重启odoo服务。

如果发现job被挂起，并提示说没有可用的Runner，那么你需要使用tags明确的指出使用哪个Runner来运行。

编写Odoo的单元测试

Odoo的单元测试写法可以参考官网教程.

需要注意的是，你可能会发现，自己写的测试脚本并不能运行，这里需要在你的脚本里添加tag：

1
2
3

@tagged('post_install', '-at_install')
class TestDemos(TransactionCase):
    ...

然后使用命令：

1

odoo --test-enable -d odootest -u osc_demo --workers=0 -c /etc/odoo/odoo.conf --log-level=test --stop-after-init

来测试你的测试脚本是否可能正常运行。

运行Runner

一切就绪以后，我们就可以提交一次代码来验证了，随便在代码中修改一下，然后提交推送到gitlab中，然后我们可以看到：

这里我们看到，由于unittest发生的错误，后边的部署就没有运行。修正单元测试中的错误以后，再次运行脚本就可以了。

分支保护

master肯定不希望被开发人员进行推送的代码，这样会会影响线上程序的稳定，因此我们改变了一下流程，变成了，开发人员只允许推送的v分支，只有合并到master的时候才进行测试和部署代码。

首先，我们需要把master分支保护起来，在settings-respository-Protected Branches中，设置为master分支只允许合并，不允许推送。

然后修改.gitlab-ci.yml文件为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

stages: 
  - test
  - deploy

unit:
  tags:
    - OSC
  stage: test
  only:
    - master
  script: 
    - odoo --test-enable -d odootest -u osc_demo --workers=0 -c /etc/odoo/odootest.conf --log-level=test --stop-after-init

deloy:
  tags:
    - OSC
  stage: deploy
  only:
    - master
  script:
      - sudo cp -rf $CI_BUILDS_DIR/Z4ysM4if/$CI_CONCURRENT_PROJECT_ID/orssica/osc_demo /home/ubuntu/odoo/odoo-dev/custom/addons/
      - sudo service odoo restart

往master上推送就会发现被拒绝：

然后再界面上进行合并分支操作，就会触发自动部署。

总结

这里仅仅是通过gitlab的一个小例子来说明，对于Odoo的开发也是可以规范化正规化的，像其他CI/CD的工具（Jenkins)肯定也是可以的，等有时间我们再来说一下，如何用Jenkins来实现Odoo的自动化部署。

在ubuntu 18.04使用apt的方式进行安装时，出现了如下的错误：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

The following packages have unmet dependencies:
 odoo : Depends: python3-gevent but it is not going to be installed
        Depends: python3-jinja2 but it is not going to be installed
        Depends: python3-lxml but it is not going to be installed
        Depends: python3-mako but it is not going to be installed
        Depends: python3-pil but it is not going to be installed
        Depends: python3-psutil but it is not going to be installed
        Depends: python3-psycopg2 but it is not going to be installed
        Depends: python3-reportlab but it is not going to be installed
        Depends: python3-libsass but it is not going to be installed
        Recommends: python3-pyldap but it is not installable
        Recommends: python3-qrcode but it is not installable
        Recommends: python3-vobject but it is not installable
E: Unable to correct problems, you have held broken packages.

看来是依赖版本不符，解决方案如下：

去网站下载相应的版本，使用dpkg -i 命令进行手动安装。

新写了一个模块，然后安装过程中出现了一个非常诡异的问题，只要我的模块中放入图标，升级后，必然白屏，打开chrome的console一下，有如下输出：

后来经过查找，找到最终的问题，是因为manifest文件中的demo和qweb节点为空导致的。

1
2
3
4
5
6

'demo': [
        '',
],
'qweb': [
    "",
],

由于odoo有的时候的报错提示不能准确的错误信息，提供的只是表面现象，因此这就提醒我们在写代码的过程中，不要留有空白的节点，包括XML中，不需要的就删掉，不要留有空节点。

安装或升级模块时，报如下错误：

1

Element odoo has extra content: record, line x

这个错误的原因不是报错表面上的原因，并不是你的record写的不对，而是你的xml中有潜在的错误，但是odoo并不能给你准确的指明。

按照一下步骤进行排查：

1. 数据模型引用是否正确，init文件中引用model了吗？
2. XML中的节点是否拼写正确，例如field写成feild，这都是不容易被发现的错误。

3. 是否有空白的XML节点，比如:

   1	<field name="help" type="html"></field>

   这样也是会导致错误的。