odoo多版本兼容纯前端app小程序

odooapp纯前端方向子产品,不需要安装任何后台应用模块,也就自然规避了odoo年复一年的大版本更新迭代所带来的变化问题。同一个app可以同时对接多个版本的odoo,也可以多个小程序连接到同一个实例的odoo,各版本之间的兼容性全部在前台分支解决,这样架构上就可以支持所有odoo版本。

这种odoo万能客户端模式几乎所有竞品都在采用,包括官方的闭源app也是这套路,接口起点都是从调用rpc的common服务version方法开始,只不过官方仅仅根据所返回的odoo详细版本号信息就限制了开源社区版的使用,并没有严格检测所谓的企业版商业授权。

标准odoo原生api直连就可以编译app的方式,如果应用在website领域是非常创新有竞争力的,能让很多从odoo8年代开始就建设好的各种存量网站、博客、商城、问卷、活动、课程、自由表单等互联网在线应用,不作任何改动和配置,就可以直接发布出绑定其odoo域名ip的多系统app和多平台小程序,一步跨入移动互联全网通时代。

当然website系列模块很多信息都是以页面html为格式的整体输出结果,并没有规范的json数据接口,这就有必要将常用于服务端的爬虫技术移植到客户端应用,通过对odoo渲染生成的模板页面进行实时结构化数据分析,剥离出各种标准的菜单、页眉、页脚、区块等样式结构和文本、图片、视频、地图、链接等元素内容,就可以输入给各种移动框架的渲染引擎,来动态生成原生的手机app交互界面。

odooapp客户端小程序产品开发策略

odoo通用移动端的研发适配是一项长期的系统工程,多少年来国际国内不少个人和组织都尝试开发过,但往往都是起个头打个水漂后就停留在欧度历史长廊里了。这些结果,renjie.me也假设性地分析过,可能是基础设施的日常迭代太过枯燥或者技术债务的不断积累达到瓶颈,也可能是相关的项目结束以及没有持续稳定的现金流烧不起这看不到头的吞金巨兽:)

之前还有一个共性就是大家都只是围绕着OpenERP的业务层次进行定位,app仅仅是原有内部管理系统在移动互联网上的延伸和扩展,没有也能将就用web。从技术角度,只是用平台原生的新语言和UI重写替换了标准web模块里的js逻辑、css样式和qweb界面,有些甚至还是用的h5混合开发技术来冗余重构。

针对上述种种问题,odooapp的产品开发决定走一条从外部全网推广包围核心erp业务的不寻常路。即优先实现website系列模块的public功能对接创新,最后才会对内部业务模块的user应用进行兼容支持。这个策略从非主流的浅水区开始,业务场景相对单纯有趣更独特,且odoo所改即所见的热更新优势更容易在互联网流量营销这个新领域发挥到炉火纯青高境界。

odooapp客户端小程序快应用框架

odoo是一个庞大的国际分工产业链,各种背景的爱好者都可以在这个链条中找到自己的归属。经过七年之痒的磨练,renjie.me也总算找到适合的基础研究方向,准备用剩余的人生以工匠精神的态度打磨再造odoo全网通client,这是一个漫长的目标和计划,接下来会坚持分享心路和成果。

c/s架构新瓶装旧酒,万变不离其宗,都是用odoo标准的jsonrpc2.0协议接口进行所有网络通讯。只不过全端开发选型已从最早的GTK、后发的QT到了移动互联网时代的uniapp框架,其最大的特色就是还支持中国国情的小程序和快应用发布。

未来理论上所有odoo原生业务、第三方应用、一二三次开发的定制系统都能天然结合这个强大的基础设施来编译出所需平台的app。从低代码平台角度,踏在odoo巨人的肩膀上,可轻松即时动态地实施出一款免开发的全平台客户端功能应用。从软件开发工具包角度,基于封装odoo底层api和前端渲染引擎的半成品sdk,可高效省心的定制开发odoo私有扩展个性化app。

odoo list view dynamic row selection field

ODOO列表视图动态行选择字段
由于框架模型限定了选择字段是需要事先定义的,也就是选择下拉内容是确定且固定的,对应成列表视图则是每一行都是相同有限的选择

物料颜色和规格集

比如以上这种每一个物料都有自己的颜色和规格明细组合,这与odoo原生的产品变体刚好相反,后者是由产品属性及值自动生成所有排列组合的变体,前者则根据实际有限的明细反推出其属性集合

物料颜色规格选择

最后体现在一些行业应用中,比如鞋服箱包产品款式的BOM配色配码,其颜色尺码的表头是由产品基础属性组成动态列,而颜色规格的配置行则是根据所选物料的不同集合来动态限定范围选择列,间接实现每一行的Many2one和Selection字段都是独立定义

odoo dingtalk pc and mobile client auth common template

ODOO阿里钉钉桌面和移动客户端免登认证通用模板
钉钉的免登接口是先要通过基于前端H5的JSAPI获取到code后才能进行后台服务端校验,但其PC端和手机端开发很可能是两个不同风格的小团队耦合而成,所以调用接口需要整合一下才能对外透明,也难怪后台应用针对两端的首页都可以分别进行配置:

odoo form view edit mode disable auto focus

ODOO表单视图编辑模式禁用自动聚焦
表单创建的时候默认会自动聚焦到第一个输入框,这是人性化易用性的设计,用户不用手动点鼠标主动聚焦,直接输入内容即可,比如名称
表单编辑的时候往往第一个输入框都是已经有内容的,特别是第一个最近的字段是必填项居多,这个时候自动聚焦的意义就没有新建时候大

虽然意义不大但也不影响什么,直到最近集成一个二代身份证读卡器的硬件产品,为了兼容多平台多浏览器无控件无插件,只好使用最干净绿色的USB HID输入方案。这个时候新建的自动聚焦刚好可以和二代证的自动填充完美配合,但是编辑的时候由于仅聚焦不全选会导致二次读卡的情况下内容是追加而不是覆盖。这种场景下自动聚焦就显得多余,迫切需要在编辑模式下关闭且使用原生的窗口监听来实现最新读卡信息覆盖同步:

odoo document management system

ODOO文档管理系统
自从开始玩上官方应用市场,一直坚持平均一个月推出一款应用,日积月累也慢慢形成了移动互联网流行的应用矩阵,同时也对海外客户的国际化需求和口味风格异同都有了不少的了解

今天突然发现上个月发布的一款文档管理系统今天已经进入下载排名十强,目前位于第八个的样子,这可是破记录了,因为之前最高也就是在第二页徘徊而已。曾经也羡慕过那些霸榜应用,现在看来只要坚持总会摸索到爆款痛点:)

论市场优秀应用,我认为至少要同步官方的节奏,不仅要支持最新的三个版本,更要兼容企业版,当然最重要的还是开源免费,而开发者所收获的则是国际的规范的扎实的基础能力

https://apps.odoo.com/apps/modules/10.0/document_management_system/
document_management_system

mongodb主主同步在线迁移

默认配置路径/etc/mongod.conf

原服务需要开启master和noauth
master = true
#auth = true
#noauth = true

新服务需要开启master和slave
#author = renjie
master = true
slave = true
#原服务IP和端口
source = 20.10.06.23:27017

重启原服务后再开启新服务即可自动开始全量同步
期间原服务还有数据增删改操作也会一并同步过来
直到所有相关调用都切换为新服务之后,即可关闭slave设置并重启就可安排原服务下线了

odoo china baidu maps api

odoo原生内置google maps,导致中国大部分区域不仅无法正常使用,用户浏览器一直加载到超时还拖慢了网站整体

相关源码:

可见针对联系人扩展了静态地图和外链地图两个接口,其参数都是通过模块自身的国家、邮编、城市、街道等地址相关字段构成

了解上诉原理之后,参照百度地图开放平台API,梳理出相近接口的参数异同点后,完全可以改造成具有中国特色的odoo maps

核心代码:

最后顺便将其整合到odoo开源模块Website China Features里,有需要可直接从官方应用市场下载使用
https://apps.odoo.com/apps/modules/9.0/website_china_features/