odooapp小程序快应用的原生动态化超能力

odoo除了可以配置app的ui渲染元素外,还可以用动作连接各平台原生功能,实现odoo从前端布局生成界面到用户行为响应结果又反馈回odoo后台的整个闭环模式。关于这些超级能力,大致可以分为操控类、浏览类、开放类、系统类:

操控能力主要指全局应用层面的,比如动态修改标题文字和主题颜色,以及app跳转app、小程序跳转小程序和相关返回控制。目前比较热门的私域免费小商店也可通过这种方式从各个公域流量入口引导过来。

浏览能力则是各种媒体类型直接播放和各种文档格式直接预览,其中不仅包括各种图片、音乐、视频等多媒体,还包括Word、Excel、PPT、PDF等可实时更新的在线文档。

开放能力全属于各平台赋能,不同的平台所赋予的功能细节都有所不同。比如应用级的在线客服和投诉反馈;用户级的手机号码、收货地址、发票抬头、地理位置等隐私信息获取;营销级的分享好友、分享群和发布朋友圈动态等推广能力。

系统能力有调用手机硬件的扫码、拍照、录像、振动、电话等基础功能,也有打开文件系统的各种相册、视频选择器,还有相关底层接口的联系人、消息、提示、弹框、剪贴板等操作。

odoo实施多平台差异化app小程序seo运营

odooapp后台控制方向子产品,需要先安装配套的移动应用,比如web_app、website_app、website_blog_app、website_shop_app等。这些以app为后缀的模块,都是继承在原功能模块的基础上,进行的移动化数据接口封装和实施规则注入,这让odoo一个实例就可以轻易快速的运营由多个平台上的多个app、小程序和快应用所组成的超级移动seo矩阵群。

这种odoo全网发布的基础架构主要是为互联网传播运营而生,因为不同的平台甚至不同的渠道都有不同的规则,就连最关键的名称都不一定能注册到一致,更不是所有内容都能在所有系统平台渠道一致性的出现,以及还有一些审核方面的差异化开关都需要app有这种动态热变更的能力。

实施差异化的维度分为平台级、渠道级、版本级。也就是说odoo可以控制最细的粒度是某个平台某个渠道某个版本app或小程序上所能呈现的原生渲染内容,这种内容又可以细分为参数类、主题类、菜单类、记录类、页面类、区块类、元素类、资源类,各种类别自由组合起来可以完成非常丰富的专业运营需求。

每个平台一次发布审核终身免更新,只要odoo实施变更,app小程序快应用所有平台所有渠道都会全网自动同步。在移动互联网这个细分流量的战国时代,祝愿所有企业在所有平台都有属于自己的全网通小程序app入口来承接各路流量,最终汇聚成传说中的私域流量来进行可持续的发展精细化的运营。

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设置并重启就可安排原服务下线了