研究 | Odoo Connects Everything

如何提交应用和主题至Odoo Apps市场

首先得有一个Odoo官网帐号，注册
https://www.odoo.com/web/signup

登录并提交您的Git仓库地址
https://apps.odoo.com/apps/upload
如：

git@github.com:surenjie/odoo.git#8.0
https://github.com/surenjie/odoo.git#9.0

1 2	git@github.com:surenjie/odoo.git#8.0 https://github.com/surenjie/odoo.git#9.0

注意：
仓库根目录每一个应用或主题都分别对应一个子目录（多个应用和主题一起发布机制）
仓库地址末尾添加#分支名称来指定版本分支（#在URL里称为锚）
分支名称用于匹配模块的系列版本号（可多个不同版本用于对应的系统版本）

仓库管理
https://apps.odoo.com/apps/dashboard/repos
一个应用多个分支版本需要分别多次提交
每个新提交仓库默认Draft状态，需要点击Scan操作变成Active状态后
就可以在My Apps中看到自己新发布的应用了
后续应用更新先提交对应分支版本
然后My Repos中执行Scan操作即可同步市场

我想出售自己的模块？
可以在官方的的应用程序平台上出售自己的模块。只要在模块描述文件__openerp__.py里简单的增加价格和货币项{‘price’: 49.99, ‘currency’: ‘EUR’}就可以开始销售您的模块。目前支持的货币为欧元和美元。官方要求在应用程序平台上出售的模块都有一个适当的描述，完整的功能截图和整体美观大方的展示页。关于如何实现这一目标，请参考以下部分的更多信息。官方保留三无模块的下架权利

我的模块要卖多少钱？
不要担心您工作应得的价值！如果有人需要你模块的功能，他们将为它支付。在任何情况下，这会使他们节约所开发的时间，所以你不应该低估你的工作。官方认为100欧元是一个很好的起点：）

我的模块如何拥有一个友好的图标和描述？
从8.0版本开始，模块图标可放置于模块文件夹/static/description/icon.png
相关截图在模块描述文件中定义，可多个

'images': [
    'static/description/main_screenshot.png'
]

'images': [

'static/description/main_screenshot.png'

]

富文本HTML描述则来自于模块文件夹/static/description/index.html
建议参照这个官方模板
https://github.com/odoo/odoo/blob/master/addons/crm/static/description/index.html

我的模块文档如何展示？
模块文件夹/doc/index.rst文件会被自动加载为文档。它必须是一个有效的RST文件

我的模块收入如何得到？
您在官方平台上模块收入的70%将会给你。只要发给他们每售出模块和价格编号的单据。你可以在你的销售仪表盘中找到这些信息（https://apps.odoo.com/apps/dashboard/sales）。考虑到处理这些单据需要时间，请理解官方只处理累计总额不少于400欧元的单据

我的代码仓库是私有的怎么办？
要在官方平台上发布您的模块，他们需要被允许从您的私有库中读取。如果您在GitHub上，只要简单授权online-odoo用户访问即可。如果不是，您将需要授权官方的public SSH key来代替。最后不要忘记使用SSH地址来注册您的仓库好让他们确定使用SSH协议

我还有其他问题？
请直接联系官方邮箱apps@odoo.com，据说他们将会竭诚为您服务。。。

浏览器每次访问odoo自动向官方服务器发送公司database.uuid信息

Odoo是经典的Web富客户端应用，每次启动都需要预加载很多资源
但是突然有一个外域请求让人很奇怪：

Remote Address:195.154.55.54:443
Request URL:https://services.openerp.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css
Request Method:GET
Status Code:301 Moved Permanently
===============》
Content-Length:184
Content-Type:text/html
Location:https://www.odoo.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css
Server:nginx/1.6.3

Remote Address:195.154.55.54:443
Request URL:https://www.odoo.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css
Request Method:GET
Status Code:200 OK
===============》
Connection:keep-alive
Content-Length:0
Content-Type:text/css
Server:nginx/1.6.3

Remote Address:195.154.55.54:443

Request URL:https://services.openerp.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css

Request Method:GET

Status Code:301 Moved Permanently

===============》

Content-Length:184

Content-Type:text/html

Location:https://www.odoo.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css

Server:nginx/1.6.3

Remote Address:195.154.55.54:443

Request URL:https://www.odoo.com/openerp-enterprise/ab/css/2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css

Request Method:GET

Status Code:200 OK

===============》

Connection:keep-alive

Content-Length:0

Content-Type:text/css

Server:nginx/1.6.3

初步分析是一个html link标签发出的get css请求，然后通过301跳转了一次还是空白返回。虽诡异但合规，所以浏览器也没有任何报错
关键就在于这个请求的文件名：2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css
前缀其实就是系统参数里的database.uuid信息值
这就说明odoo官方其实是可以根据这个估算出每个实施项目的用户情况统计

但对于访问用户来说，虽然是异步请求，但只要没意义多一个都嫌多，特别是内网用户
经过阅读源码发现统计请求来自mail模块(Discussions, Mailing Lists, News)里的announcement.js，其几十行javascript代码随便注释下就可以搞定

刚巧最近在研究应用开发，知道前后端的模版都可以通过继承的方式来进行间接修改
那样最大的好处是官方的源码可以随时同步更新而不用担心直接修改带来的合并冲突
从前端架构的角度来说，模版的继承特性比模块类的继承特性难度大多了，查了下官方文档果然有记载模块类重载的方法

最终根据odoo8和odoo9的异同点特性不断精炼，得到如下兼容代码：

openerp.none_odoo = function(instance, local) {
    instance.web.WebClient.include({
        show_annoucement_bar: function() {
            // 8.0
            return;
        },
        show_announcement_bar: function() {
            // 9.0
            return;
        }
    });
}

openerp.none_odoo = function(instance, local) {

instance.web.WebClient.include({

show_annoucement_bar: function() {

// 8.0

return;

show_announcement_bar: function() {

// 9.0

return;

}

});

}

虽然简洁，但不能直接拿来即用，但懂应用开发的朋友绝对一看便知：）

Linux centos yum install odoo rpm postinstall scriptlet

众所周知，odoo官方提供了非常方便的yum安装源用于一键安装
只需先根据版本配置源

odoo8

yum-config-manager --add-repo=https://nightly.odoo.com/8.0/nightly/rpm/odoo.repo

1	yum-config-manager --add-repo=https://nightly.odoo.com/8.0/nightly/rpm/odoo.repo

odoo9

yum-config-manager --add-repo=https://nightly.odoo.com/9.0/nightly/rpm/odoo.repo

1	yum-config-manager --add-repo=https://nightly.odoo.com/9.0/nightly/rpm/odoo.repo

之后即可一键自动解决依赖安装

yum install -y odoo

1	yum install -y odoo

相信源码安装过的同学都一定很好奇
这么繁琐复杂的细节居然可以全部包装到一个rpm包里透明掉了
还有那么多依赖库，怎么可能yum里全部都有
带着这种疑问认真研究了下
才知道rpm包内除了相应的程序，还可能有pre和post install两个shell脚本
分别对应安装前和安装后执行
以下为8.0版本latest rpm包为例，其中文注释为本人补充方便整体理解

rpm -qp --scripts odoo_8.0.latest.noarch.rpm
postinstall scriptlet (using /bin/sh):
#!/bin/sh
#错误立即退出
set -e
#配置目录
ODOO_CONFIGURATION_DIR=/etc/odoo
#配置文件
ODOO_CONFIGURATION_FILE=$ODOO_CONFIGURATION_DIR/openerp-server.conf
#数据目录
ODOO_DATA_DIR=/var/lib/odoo
ODOO_GROUP="odoo"
#日志目录
ODOO_LOG_DIR=/var/log/odoo
ODOO_USER="odoo"
#创建系统用户及用户组
if ! getent passwd | grep -q "^odoo:"; then
    groupadd $ODOO_GROUP
    adduser --system --no-create-home $ODOO_USER -g $ODOO_GROUP
fi
# Register "$ODOO_USER" as a postgres user with "Create DB" role attribute
su - postgres -c "createuser -d -R -S $ODOO_USER" 2> /dev/null || true
# Configuration file
mkdir -p $ODOO_CONFIGURATION_DIR
# can't copy debian config-file as addons_path is not the same
echo "[options]
; This is the password that allows database operations:
; admin_passwd = admin
db_host = False
db_port = False
db_user = $ODOO_USER
db_password = False
addons_path = /usr/lib/python2.7/site-packages/openerp/addons
" > $ODOO_CONFIGURATION_FILE
#配置文件权限设置
chown $ODOO_USER:$ODOO_GROUP $ODOO_CONFIGURATION_FILE
chmod 0640 $ODOO_CONFIGURATION_FILE
# Log
mkdir -p $ODOO_LOG_DIR
chown $ODOO_USER:$ODOO_GROUP $ODOO_LOG_DIR
chmod 0750 $ODOO_LOG_DIR
# Data dir
mkdir -p $ODOO_DATA_DIR
chown $ODOO_USER:$ODOO_GROUP $ODOO_DATA_DIR
#系统服务
INIT_FILE=/lib/systemd/system/odoo.service
touch $INIT_FILE
chmod 0700 $INIT_FILE
cat << 'EOF' > $INIT_FILE
[Unit]
Description=Odoo Open Source ERP and CRM
After=network.target

[Service]
Type=simple
User=odoo
Group=odoo
ExecStart=/usr/bin/odoo.py --config=/etc/odoo/openerp-server.conf

[Install]
WantedBy=multi-user.target
EOF
#YUM中没有的Python依赖库部分
easy_install pyPdf vatnumber pydot psycogreen

rpm -qp --scripts odoo_8.0.latest.noarch.rpm

postinstall scriptlet (using /bin/sh):

#!/bin/sh

#错误立即退出

set -e

#配置目录

ODOO_CONFIGURATION_DIR=/etc/odoo

#配置文件

ODOO_CONFIGURATION_FILE=$ODOO_CONFIGURATION_DIR/openerp-server.conf

#数据目录

ODOO_DATA_DIR=/var/lib/odoo

ODOO_GROUP="odoo"

#日志目录

ODOO_LOG_DIR=/var/log/odoo

ODOO_USER="odoo"

#创建系统用户及用户组

if ! getent passwd | grep -q "^odoo:"; then

groupadd $ODOO_GROUP

adduser --system --no-create-home $ODOO_USER -g $ODOO_GROUP

# Register "$ODOO_USER" as a postgres user with "Create DB" role attribute

su - postgres -c "createuser -d -R -S $ODOO_USER" 2> /dev/null || true

# Configuration file

mkdir -p $ODOO_CONFIGURATION_DIR

# can't copy debian config-file as addons_path is not the same

echo "[options]

; This is the password that allows database operations:

; admin_passwd = admin

db_host = False

db_port = False

db_user = $ODOO_USER

db_password = False

addons_path = /usr/lib/python2.7/site-packages/openerp/addons

" > $ODOO_CONFIGURATION_FILE

#配置文件权限设置

chown $ODOO_USER:$ODOO_GROUP $ODOO_CONFIGURATION_FILE

chmod 0640 $ODOO_CONFIGURATION_FILE

# Log

mkdir -p $ODOO_LOG_DIR

chown $ODOO_USER:$ODOO_GROUP $ODOO_LOG_DIR

chmod 0750 $ODOO_LOG_DIR

# Data dir

mkdir -p $ODOO_DATA_DIR

chown $ODOO_USER:$ODOO_GROUP $ODOO_DATA_DIR

#系统服务

INIT_FILE=/lib/systemd/system/odoo.service

touch $INIT_FILE

chmod 0700 $INIT_FILE

cat << 'EOF' > $INIT_FILE

[Unit]

Description=Odoo Open Source ERP and CRM

After=network.target

[Service]

Type=simple

User=odoo

Group=odoo

ExecStart=/usr/bin/odoo.py --config=/etc/odoo/openerp-server.conf

[Install]

WantedBy=multi-user.target

EOF

#YUM中没有的Python依赖库部分

easy_install pyPdf vatnumber pydot psycogreen

可见诸多内幕与细节全都在这段脚本里完美体现了
知己知彼，剖析清楚每一行代码后，对基于源代码的个性化定制安装部署又有了新的认识

Linux Centos7 ThinkPad X1C无线网卡问题解决记录

折腾了两天，总结下问题
不知是2015款才有的问题还是前面几代内置无线网卡型号不同而不同

话说刚装Centos7系统时
安装向导顺利适配无线网卡并顺畅连接无线网络完成整个安装过程
然而在正常启动登录后，网卡是不适配的，当然除此之外其它驱动都完美适配

初步判断是安装向导自带很多无线驱动
但这些不是全都默认安装的，不过好歹知道是肯定支持的就放心了

查阅大量相关社区讨论及文档阅读后
最终发现这款型号Intel Wireless-N 7265 BN的驱动官方yum源就有：

iwl7265-firmware.noarch : Firmware for Intel(R) Dual Band Wireless-AC 7265: Series Adapters

1	iwl7265-firmware.noarch : Firmware for Intel(R) Dual Band Wireless-AC 7265: Series Adapters

由于无网络连有线口都没，只好先去台式机用yum只下载不安装

sudo yum install --downloadonly --downloaddir=/home/srj/Downloads iwl7265-firmware

1	sudo yum install --downloadonly --downloaddir=/home/srj/Downloads iwl7265-firmware

得到iwl7265-firmware-22.0.7.0-36.el7.noarch.rpm安装包后通过U盘拷贝到小C本地安装

sudo yum localinstall iwl7265-firmware-22.0.7.0-36.el7.noarch.rpm

1	sudo yum localinstall iwl7265-firmware-22.0.7.0-36.el7.noarch.rpm

重启后无线网络的小图标久别重逢了
但是好景不长就发现网络虽能连接但及其不稳定
掉包效超高，断线率也不少，经常动不动就全没了
回想安装向导时那驱动还是很稳定服务的，只能怀疑驱动版本问题了，毕竟小C内置的不是双频AC网卡，当然这要在Windows下肯定是一个大驱动全包了

接着又搜寻了许久，最终在
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi
找到了传说中Intel全系列Linux Wireless Driver下载集中地

然后根据Centos7 Kernel 3.10旧内核版本比较其实都不匹配
最终比对了下之前yum源安装的驱动

[srj@x1c firmware]$ pwd
/usr/lib/firmware
[srj@x1c firmware]$ ll|grep 7265
-rw-r--r--. 1 root root  690452 8月   9 23:40 iwlwifi-7265-8.ucode
-rw-r--r--. 1 root root  697828 8月   9 23:47 iwlwifi-7265-9.ucode

[srj@x1c firmware]$ pwd

/usr/lib/firmware

[srj@x1c firmware]$ ll|grep 7265

-rw-r--r--. 1 root root 690452 8月 9 23:40 iwlwifi-7265-8.ucode

-rw-r--r--. 1 root root 697828 8月 9 23:47 iwlwifi-7265-9.ucode

发现刚好就是iwlwifi-7265-ucode-22.24.8.0.tgz和iwlwifi-7265-ucode-25.228.9.0.tgz里的两同名文件
那要么先升级内核要么病马当活马医
立即下载解压覆盖重启解决所有问题
稳定顺畅的网络总算在新设备新系统的折腾上划了一个圆满的句号

Linux下的炉石传说

20150421炉石传说

感谢过去一年的基础积累
Linux环境炉石传说折腾成功
提前告别迟早要决裂的盗版时代
努力拥抱开源世界

SPA3102基础上的OBi110准新手入门到熟悉心得分享

如果说SPA3000/3102的精髓就是Dial Plan的话，那其实OBi110也还是它
只不过它将Dial Plan分成了DigitMap与OutboundCallRoute两大类，而这两大类又包含了embedded-digit-map
也就是说，任何SPA的Dial Plan都可以根据原则分成DigitMap部分与OutboundCallRoute部分，反之也可
就像OBi110的DisconnectTonePattern与SPA3102的Disconnect Tone一样，本质是相同的，但是需要格式转换

这样的好处是解决了原有Dial Plan承载了太多太多东西的负担，什么都在里面，之前一个复杂些的DP复制出来都要分好几行，而且维护成本很高，一不小心一个语法格式错误就挂了
于是OBi将Dial Plan的非线路网关(包括默认Line1、gw0-4及其它自定义DP网关)部分单独划分出来称之为DigitMap，这个就非常类似很多编程语言里的Regular Expressions，中文叫正则表达式，只用于匹配、转换或限制，我先称之为预处理，或者一级处理
DigitMap又继续优化为可以单独成为一种embedded-digit-map，包括系统的(Msp1、Msp2、Mpp、Mli等，详细AdminGuide P118有介绍)与User Defined Digit Maps，并且可以互相嵌套(谨慎使用防止递归)，每个(Mlabel)单独维护并做专一的事情，提高了可易阅读性，最终还使得主DigitMap变得很小且容易维护
比如我的PHONE Port DigitMap经过合理优化，最终就只有(#[012] | (MStar) | (Mpli))这些了，而Auto Attendant DigitMap也就(<0 : $1> | (MStar) | (Mpli))那样，非常容易维护，每次新增规则只需要改一个孙子级的DigitMap即可

经过DigitMap的划分，原来Dial Plan剩下的线路网关部分就自然成为了OutboundCallRoute，这个初看貌似很复杂的东西，如果你要知道其实这只是原来很熟悉Dial Plan的一部分那就很有信心去征服它了
我也将这个工作称之为后处理，或者二级处理，因为需要结合预处理才能组合成一个完整的Dial Plan，于是其也包含了embedded-digit-map，用于衔接两者的纽带，否则就只能靠一个个预先确定好的callee number号码来前呼后应了
当然关于这个，我觉得褒贬不一，还很有争论，因为细分带来的好处我例子中已经显而易见，但同时也增加了不少冗余，我就拿系统默认的也是大家最熟悉的**9来说吧，DigitMap需要有**9(Mpp)规则用于预处理OBiTalk号码的合法性，而OutboundCallRoute也需要有{(<**9:>(Mpp)):pp}规则，而其中都包含相同的DigitMap这就是冗余，而且预处理匹配了**9前缀，后处理用于消除**9前缀，本来简单一步的事情要分两步做，增加了设置的负担，与理解的难度
比如系统默认的OBiTALK Service DigitMap为(<ob>xxxxxxxxx|obxxxxxxxxx)，一开始我始终不能理解后一个规则的作用，直到后来因为上述的一二级处理机制我才慢慢明白，后个规则是给后处理用的，因为预处理已经将9位数字提前增加的前缀，这个时候如果没有后一个规则允许的话，二级处理那里是不允许通过的，这些就是所谓有很小很小弊端的地方，但总体可以用前紧后松或前松后紧的原则来避免，总之这个划分我认为是利远远大于弊的

正因为有了OutboundCallRoute，于是对应出了InboundCallRoute，这与SPA3102如何对应呢，很简单，那就是SPA PSTN Line的两个Gateway功能分别对应OBi110 SP2 Service InboundCallRoute与LINE Port InboundCallRoute的部分功能，其他两个InboundCallRoute则是独一无二无法对应的，这和SPA Line1线很单纯有关，而且OBiTALK也是横空出世的
注意对应过来的功能在OBi110这里其实是雕虫小技了，因为SPA PSTN Line线在现在看来其实就只有可怜的VoIP-To-PSTN与PSTN-To-VoIP两个小功能，这在OBi时代就不过是很简单的SP2 InboundCallRoute{li(To-PSTN-Number)}与LINE InboundCallRoute{sp2(To-VoIP-Number)}基础上的扩展，其大部分的参数细节控制都可以一一对应过来，但肯定也有一些是还不行的，比如VoIP Access List这个，用于限制安全IP地址范围的，但目前的InboundCallRoute体系里似乎就没有考虑到这点，毕竟VOIP里的号码欺骗是非常容易的，仅凭匿名或指定号码来做匹配是很不安全的
当然退一步从更高一层次的角度来看，这个也不是问题，因为同级的还有Auto Attendant，而且可以UsePIN做最后保障，可松可紧，控制方便

最后总结，OBi110按照模块划分为7个基础部分，其中
四条独立的线路，即SP1 Service、SP2 Service、OBiTALK Service、LINE Port，其基本特征是拥有InboundCallRoute而没有OutboundCallRoute
两个独立的终端，分别是PHONE Port与Auto Attendant，前者是有形的，后则是无形的，其基本特征与线路相反，拥有OutboundCallRoute而没有InboundCallRoute
一个特殊的终端，即Auto Attendant2或AA2，官方称之为local device configuration IVR，其比AA更无形，什么都没有就是它的基本特征

前面六个部分都有自己的DigitMap，特别是这么多的地方可以设置DigitMap这让初学者很畏惧，其实最关键的是终端的DigitMap，特别是有形的那个我们最常用，只要控制好了终端的DigitMap，线路的DigitMap其实是浮云
从某种角度看也可以将一紧一松的思想适用于这里，就是终端紧就线路松，反之亦然，因为一个正常的主叫通话肯定是先由终端DigitMap拨号，之后在由线路DigitMap拨出，任何一级做精确控制都是可以的
线路特有的InboundCallRoute其实就是控制将线路的来电转移到指定终端上，包括但不限于那两个基本终端，因为对于线路拨打出去的号码所对应的其实也可以理解成是一个远程终端。比如ph与li(另外一个电话的号码)，就分别为本地与远程终端，只不过前者直接连接，后者用网关桥接
终端特有的OutboundCallRoute其实就是将终端DigitMap一级处理过的拨号，再经过OutboundCallRoute二级匹配后通过线路拨打出去给其他终端，包括但不限于那四条基本线路，其实这里隐含了第五条本地线路，用于AA拨打PH或PH拨打AA，甚至特殊的AA2终端也是依靠这条本地线访问

总之，OBi110是站在SPA3000的基础上深化改良并与时俱进的，如果您还在SPA时代，请不要畏惧进入OBi时代，其实这非常简单，完全可以做到除了对您本人这个Admin外的其他使用者的透明转换，包括使用习惯，当然也许目前还有一些不足，但至少持续不断的Firmware更新让我们看到了希望，在这点上是停滞许久不前的SPA3000系列所无法比拟的