本机同时部署odoo8和odoo9等多套开发环境注意事项

自从odoo9正式发布后,odoo8就意味着迟早要跟odoo7一样进入历史
但在一段时间的过渡期内
开发者可能要维持两套版本环境方便快速调式自己的代码能否多版本兼容运行
特别是插件开发,经常一个修改就需要到两个系统更新应用测试
以下记载各个共存环节需要注意的事项

安装方式:
因为安装包是互斥冲突的,所以必须源码安装

依赖库:
相同部分(python)或特有部分(nodejs)可以全局安装,不同部分则用上篇python-virtualenv虚拟环境隔离

数据库:
最简单一个本机帐号同名的超级账户共享使用,odoo缺省配置就能连接上了
不过最好先安装8在安装9,因为9能认识8创建的数据库而忽略,但8不太认识9创建的数据库自动连接会报错
共存之后8的控制台会例行报如下警告,要洁癖只能分别配置两个数据库帐号

版本库:
odoo8和odoo9两目录分别clone对应官方git版本库的8.0和9.0分支,独立各自日常更新

插件库:
比较灵活,我的方式是与odoo目录同级,然后配置文件共同指向

配置文件:
启动时分别指定各自独立配置,各自用不同的端口

浏览器:
虽然分属不同的端口提供服务,但因为登录标识必须要写用户本地浏览器cookie如session_id,或者犹如website_lang网站默认语言这种个性化设置。但由于cookie只匹配域名及路径就是不区分端口,所以同一个浏览器只能固定某个版本调式,如果同时使用就会发生各种意想不到的混乱错误。
当然解决方案也很简单,就是将本机127.0.0.1多设置几个如localhost这种别名来给不同的odoo版本独立访问即可

 

用python-virtualenv统一管理odoo python依赖库

odoo有些python依赖库官方yum源里没有
或者有可能版本不兼容
这就需要根据版本指定安装,默认是安装到
/usr/lib/python2.7/site-packages/
主要是本机开发环境,各种基于python的系统部署一起
长期下来感觉又回到windows时代dll库混乱的悲剧
更何况odoo8和odoo9所依赖的库和版本都不尽相同
非常需要根据应用来独立管理所对应的依赖环境

安装python-virtualenv:

创建虚拟环境:

进入虚拟环境:

进入odoo目录直接安装:

也可以直接通过pip来安装(可用阿里云等提供的国内镜像快速下载):

可能会遇到一些库对virtualenv默认的setuptools的版本有要求,根据提示升级下(Centos目前yum源python-virtualenv-1.10.1-2自带的是0.9.8版本有些低):

同时附上pip、easy_install及setup.py安装获取依赖库的阿里云镜像源配置:

以后每次使用都要先通过source命令指定对应环境下的activate初始化进入
离开则直接使用deactivate命令即可回到原生环境
当然也可以通过修改odoo.py头直接指定虚拟环境的python路径来快捷运行:

 

Odoo Bootswatch Theme fonts.googleapis.com访问速度慢

Odoo8的website模块自带Bootswatch系列主题集
Odoo9则将其独立为一个theme_bootswatch主题,可见将来主题也跟应用一样市场化了

其中某些子主题依赖谷歌fonts.googleapis.com字体,国内用户全天候访问不一定友好,可以选用360网站卫士提供的CDN服务替换以达到安全或加速的效果

360网站卫士官方说明http://libs.useso.com/

主题路径
odoo8/addons/website/static/src/css/bootswatch
odoo9/addons/theme_bootswatch

全局搜索“fonts.googleapis.com”替换成“fonts.useso.com”即可解决不稳定问题
也可以举一反三直接在odoo主目录暴力搜索替换以解决其它第三方应用或主题可能存在同样的问题

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

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

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

注意:
仓库根目录每一个应用或主题都分别对应一个子目录(多个应用和主题一起发布机制)
仓库地址末尾添加#分支名称来指定版本分支(#在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
相关截图在模块描述文件中定义,可多个

富文本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开发支持国际化语言的第三方应用

英语开发并安装好应用的单语言版本
普通视图元素的string、help、sum、confirm、placeholder属性文本自动导出
QWeb模版(包括服务端和客户端两个部分),如果没有用t-translation=”off”关闭翻译,
则title、alt、label、placeholder属性文本也会自动导出
关于模型字段(Model Field),如果模型没有标注_translate = False:则string和help属性默认可导出;selection类型字段文本也可导出;translate属性设置为True,则所有存在值(values)都会导出
_constraints和_sql_constraints约束中的help、error信息会导出
其它代码里显式调用国际化字符串获取接口的参数值一同导出

管理员设置
翻译(Translations)=》导入/导出(Import / Export)=》导出翻译(Export Translations)
语言(Language)选择新语言翻译模版(New Language Empty translation template)
文件格式(File Format)选择PO File
导出应用(Apps To Export)里选择您的模块
导出(Export)=>下载《模块名.pot》文件

模块新增i18n目录
将上一步导出的文件移进去作为基准翻译模版
以此模版为基础简单的另存为其它语言文件如:zh_CN.po
或者使用PO editor等编辑软件所译即所得自动生成
还可以当前目录直接运行msginit命令默认生成操作系统对应的语言版本文件

与直接模版另存为比较多了以下三项区别:

根据语言文件内的各项原文本msgid部分翻译成对应的msgstr值
加载翻译分别选择各种语言并覆盖已存在的术语(odoo9更新模块也可达到部分效果)
选择不同的用户语言即可整体确认翻译质量

应用发布
odoo9和odoo8的翻译文件不太兼容,主要是因为各自对msgid的引用方式不同
需要分别针对不同版本的系统制作翻译文件并发布到对应分支上

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

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

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

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

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

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

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

odoo.py auto-reload dev自动重启服务ENOSPC系统错误解决

Odoo8
正常环境下直接–auto-reload参数运行缺库错误

pyinotify是一个Python模块,用来监测文件系统的变化
pyinotify依赖于Linux内核的inotify功能,是一个事件驱动的通知器,其通知接口通过三个系统调用从内核空间到用户空间
pyinotify结合这些系统调用,并提供一个顶级的抽象和一个通用的方式来处理这些功能

安装
pip install pyinotify

运行时错误:

Odoo9
正常环境下直接–dev参数运行日志警告

Watchdog是一个跨平台的Python库和shell工具,可以监视文件系统事件。超级好用,并且容易上手

安装
pip install watchdog

运行时错误:

Node
想起来当初刚玩node时也时常会遇到这个错误
不过大多直接sudo运行就可解决,简单理解权限问题也没有深究
但是odoo不能这么搞,源码限制:

还好从odoo9的报错信息里显而易见问题出自底层inotify对一般用户的限制
简单学习了下,得知其有个max_user_watches的内核参数限制普通用户一次最多关联监控个数。一般默认值8192,对于odoo这种大工程或稍大一点的node项目来说明显是不够用的

先通过如下方式验证:

然后通过su切换root身份动态更新配置值放大64倍

接着用不同版本的启动参数运行即可看到AutoReload watcher running成功了

最后还需要将动态修改的参数通过静态配置方式固化下来,否则每次重启还需要重复修改
Centos7下我不建议直接修改/etc/sysctl.conf文件配置,而是通过sysctl.d目录新建独立配置

然后重新启动或者使用

sysctl命令system参数立刻生效

Linux centos yum install odoo rpm postinstall scriptlet

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

odoo8

odoo9

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

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

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