我们都知道odoo的自定义搜索功能比较实用，可以将所有存储类型的字段作为搜索条件，大多数情况下是比较好用的。今天要说的是当企业用了一段时间并自定了很多字段的情况下，字段列表将会变得非常长，这时候就会出现一个另用户比较头疼的痛点，想找一个字段太麻烦了，要盯着屏幕看好久。

这个时候我们就希望用户能够像快速编辑那样，通过输入部分名称，自动匹配到要搜索的字段，从而实现快速选择，节省用户查找时间。
因此，我们编写了Filter_Autocomplete模块，安装此模块以后，用户即可在自定义搜索栏实现模糊匹配，迅速找到自己想要的字段。

此模块目前支持 13.0和 10.0，已在笔者商店上架，欢迎选购。

##

du: 计算出单个文件或者文件夹的磁盘空间占用。
sort: 对文件行或者标准输出行记录排序后输出.
head: 输出文件内容的前面部分.

组合使用，查找某个文件夹下面的最大的10个文件夹：

1

du -ak / |sort -r -n|head -10

本文基于odoo 13.0 企业版

时间来到了2020年，传闻13.0中原生集成了生产模块的外协加工功能，今天我们就来一探究竟。

启用外协设置

首先，我们需要先启用外协设置，在设置-操作-外协：

启用外协之后，我们在BOM的选项中会有一个Subcontracting的选项：

我们在创建BOM的时候选择该选项，并将选中要生产该产品的外包厂。

采购或直接从外包厂收货

odoo原生的设计支持两种外包模式，一种是从外包厂直接采购成品回来，另外一种是直接从外包厂将成品（半成品）收货。

从外包厂采购成品

我们先来看如何操作直接从外包厂采购成品回来。

首先，创建一个采购单，供应商选BOM中设置好的的外包厂：

单击确认，采购单会自动生成如下单据：

这个单据不同于我们普通的采购单，向导界面中显示的要消耗的原材料。从技术的角度上将，普通入库单中显示的是stock.move或者stock.move.line，而这里显示的是mrp.product.produce.line。

单击保存，系统将自动生成如下的库存移动：

原材料

subcontracting location—->production location

成品

production location —-> subcontracting_location
subcontracting location —–> stock

subcontracting location 是挂载在Partner Location下面的内部库位。

当我们完成收货，将会看到成品位于Stock库位，并且会消耗掉subcontracting location中相应的原材料数量。

直接从外包厂收货

直接从外包厂进货意味着不需要创建采购单，我们直接在入库单里手动创建一个入库单即可：

剩下的步骤同采购入库相同。

原本的设计

客户的需求是要将供应商发来的货物运送到质检仓库进行质检，将不合格的产品退回给供应商退换货，换回来的货依旧要走质检流程。因此，设计的流程如下图:

本文适用于12.0

在使用库存过程中如果操作不是很严格，会出现下面的错误消息：

1

It is not possible to unreserve more products of xxxxx than you have in stock.

出现该问题的原因就是本来应该属于次单据的保留数量被非法占有或移动走了。

解决方案就是找到xxxx对应的stock_move 将其模型中的product_qty字段的数量重置为0即可。

1

update stock_move_line set product_qty = 0 where id = ;

添加可用库存的必要性

odoo当前版本(12,13)中的产品信息中有在手数量和预测数量，在手数量指的是当前库存中实际存在的库存数量，预测数量指的是包含即将入库和即将出库的一个库存预测值。预测数量 = 在手数量 + 即将入库数量 - 即将出库数量。即将在这里的意思当然就是尚未完成的状态。

但是在实际使用的过程中，我们往往还关心另一个很重要的参数，可用数量。可用数量 = 在手数量 - 已预留数量。遗憾的是odoo官方并未提供这个字段。因此，我们需要手动实现它。

odoo的库存模型stock.quant中已经有了在手数量quantity和已预留数量reserved_quantity，因此可用数量的值可以通过定义一个计算字段available_qty：

1
2
3
4
5
6
7

avaliable_qty = fields.Float(
        "可用库存", compute="_get_avaliable_qty", store=True)

@api.one
@api.depends("quantity", "reserved_quantity")
def _get_avaliable_qty(self):
    self.avaliable_qty = self.quantity - self.reserved_quantity

实际效果

事情的起因是这样的，公司的odoo系统使用了多公司，集团零售门店部门使用的是B公司，供应链系统使用的是A公司，某天B公司的采购报告，下不了采购单，提示res.company对象因为Rule的问题，没有访问权限。从后台日志中可以看到，B在下单的时候试图访问A公司的资料。

既然是安全规则的问题，那么我就去看了一下公司对象的设置，一切正常。奇怪的是B公司的采购明明只有B公司的访问权限，为什么要去访问A公司的资料呢？

根据前端提示的报错代码，定位到了，B公司采购在下单的时候使用了A公司的供应商税。问题又来了，B公司下采购单，为什么要访问A公司的税种呢？后来发现，A公司的采购税居然在B公司下可见，显然，税的访问设置出了问题。

我们找到税率的安全规则，看到了如下的访问设置:

1

[(1,'=',1)]

显然，这里的设置是不对的，改为

1

[('company_id','child_of',[user.company_id.id])]

即恢复正常。

结论

从上面的过程中，我们可以反思Odoo是如何处理多公司条件下的税种隔离方案，靠的就是安全规则，不同公司的人看到的税种不一样。而对于成本价，odoo的处理方式是另外一种，改天再细谈。

感谢OCA为我们提供了基础模块

做后台的同学一定听说过swagger的大名，现在改名叫OpenApi了，简单说就是一个提供了方便测试的接口界面。跟我们做对接的人，打开界面就能轻松地知道如何正确的调用我们的接口和接收返回值。

网上比较多的是flask和swagger结合的例子，如果我们想要在odoo中实现类似的REST Swagger模式，我们可以按照下面的方式进行。

安装依赖

本文依赖于OCA的一个模块base_rest，读者可以自行搜索，也可以关注odoohub回复base_rest获取下载链接。

编写接口

由于odoo自带的jsonrpc并不能满足我们的需求(我们不可能给第三方系统的人提供一种类似res.partner的对象，并给他们解释对象的意思)，因此，我们需要重新定义一些业务接口。

定义一个新的Service

我们把新的API接口定义为一个Service，继承base.rest.service这个对象，并定义好usage、description等属性。

1
2
3
4
5
6
7
8

class AladinService(Component):
    _inherit = "base.rest.service"
    _name = "aladin.service"
    _usage = "Aladin"
    _collection = "base.rest.aladin.services"
    _description = """
        阿拉丁业务API
    """

定义接口

rest_api借助cerberus(Cerberus是一个用于Python的轻量级且可扩展的数据验证库)来验证我们输入的字段值。

一个典型的get接口可以写成下面这样：

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

@skip_secure_response
def get(self, _id, size):
    """
    Get partner's image
    """
    field = "image"
    if size == "small":
        field = "image_small"
    elif size == "medium":
        field = "image_medium"
    status, headers, content = self.env["ir.http"].binary_content(
        model="res.partner", id=_id, field=field, env=self.env
    )
    if not content:
        raise MissingError(_("No image found for partner %s") % _id)
    image_base64 = base64.b64decode(content)
    headers.append(("Content-Length", len(image_base64)))
    response = request.make_response(image_base64, headers)
    response.status_code = status
    return response

其中方法的描述会自动加载到swagger的方法描述中。

定义API路径

在controller中，定义API接口的路径：

1
2
3
4

class BaseRestDemoPrivateApiController(main.RestController):
    _root_path = "/base_rest_demo_api/private/"
    _collection_name = "base.rest.demo.private.services"
    _default_auth = "user"

base_rest提供了基本的权限认证，基于odoo自身的账户设置。_default_auth的可选值有public和user。两个值会被加载到controller的auth参数中，以用来标识验证方法。

这并非当前流行的验证方式，可惜的是oca并没有提供oatuh的验证机制。因此，笔者在实际的应用过程中，借鉴了另外的一个模块restapi的方式。

页面展示

安装模块后，我们可以在Odoo中的模块界面中看到一个swagger的图标：

点击进入swagger api界面：

odoo用来管理微信公众号是非常合适的，今天我们就来介绍一下正在开发中的微信公众号模块的主要功能。后续功能正在添加中，欢迎持续关注。

菜单管理

最基础的功能就是将微信公众号的菜单管理系统接入到odoo中。

在odoo中的新增、编辑和删除菜单都会自动同步到微信公众号中。

粉丝管理

我们同样可以把关注公众号的用户信息同步到odoo中。

消息记录

我们这里把用户发送的消息存储了起来，方便归档查询使用。

素材管理

通过素材管理，用户可以在odoo系统内完成对公众号图片、语音、视频信息的上传、删除等管理功能。
配合自动回复，可以实现灵活丰富地回复效果。

自动回复

公众号的一大功能就是自动回复，根据不同的事件类型回复不同的内容。

支持输入Python代码，在页面中灵活定制返回内容，不用再每次都修改源代码了。

多媒体回复

自动回复可以使用多媒体文件进行回复了。

演示系统地址: demo13.mixoo.cn
账号 odoohub 密码 odoohub
演示公众号:

我们都知道，odoo中的图片支持两种存储方式，一种是将图片存储在数据库中，另外一种是存储在本地文件中。项目小时，这两种方式其实都没有什么问题，但是随着项目的扩大，一旦使用了集群，这种静态文件的增长会让问题变得棘手。于是，一直在思考有没有一种方式，可以将图片放到现在比较流行的云存储上面。之前写过一片关于AWS S3自动上传媒体文件的文章，今天我们就来实现另外一种图片模块，让用户输入URL地址，然后显示出对应的图片来。

这里主要用到了自定义字段的技术，下面就大体描述一下整个开发的过程和其中碰到的坑。

创建字段类型

我们希望能够在odoo中创建一种新的字段类型，这种字段类型在只读模式下表现为图片，当用户编辑时，变为一个输入框，当用户输入URL后，自动将URL关联的图片显示出来。

首先，我们需要创建一个新的字段类，该类是Field类的子类：

1
2
3
4
5

from odoo import fields

class ImageURL(fields.Field):
    type = "imageurl"
    column_type = ('varchar', 'varchar')

我们给字段类型定义为imageurl，暗示本字段在编辑模式下表现为input输入框，在只读模式下表现为图片。

创建Widget

odoo中的每种字段类型都有与之匹配的widget，我们这里主要拿Input控件来进行改造，因此widget继承自InputField:

1
2
3
4
5

var ImageURLField = InputField.extend(TranslatableFieldMixin, {
        className: "o_field_image",
        tagName: 'span',
        supportedFieldTypes: ['char']
}

widget创建完，必须要注册到registry才能在view中加载。registry就像一个钩子，将你创建的widget与具体的前端view关联起来。

1

registry.add('imageurl', ImageURLField);

渲染图片

我们的字段的行为有连个特点，只读模式下为图片，编辑模式下为输入框。这个需要用到渲染函数_render, _render内部调用了_renderReadonly和_renderEdit方法。

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

_renderReadonly: function () {
    var url = this.value;
    var $img = $(qweb.render("FieldBinaryImage-img", { widget: this, url: url }));
    // override css size attributes (could have been defined in css files)
    // if specified on the widget
    var width = this.nodeOptions.size ? this.nodeOptions.size[0] : this.attrs.width;
    var height = this.nodeOptions.size ? this.nodeOptions.size[1] : this.attrs.height;
    if (width) {
        $img.attr('width', width);
        $img.css('max-width', width + 'px');
    }
    if (height) {
        $img.attr('height', height);
        $img.css('max-height', height + 'px');
    }
    this.$('> img').remove();
    this.$el.prepend($img);
}

这里我们借用了BinaryImage部件的代码，因为我们想让图片在只读模式下表现的跟BinaryImage行为一致。

在没有重载_renderEdit方法时，ImageURL在只读模式下没有值，原因是其内部的值是图片，无法正确显示。因此，我们这里需要将字段的值重新赋给输入框。

1
2
3

_renderEdit: function () {
    this.$el.val(this.value);
 }

最终效果