odoo欧度软件帽峰山国际研学基地正式运营

odoo广州帽峰山基地挂牌,乡村振兴时代,新农村包围城市策略逐渐开始落地,欢迎来和我们一起依山傍水。。。

基地坐落于山脚萤泉谷养生文化邨,集山脉、森林、湖泊、山泉为一体,交通便利出则繁华入则桃园,是天然且理想的一线城市近郊研发与培训基地。

Odoo与PostgreSQL互相成就之序列(ir.sequence)的实现

odoo序列standard模式其实是pg数据库sequence特性的无代码应用,分别在sql层封装了db序列的创建、删除、修改、查询和预测下一号码的基础能力。然后再根据实施灵活性增强了前后缀、长度不足补0、每个日期范围使用不同序列的层级关系等扩展功能。

odoo同时也额外用select for update nowait数据锁能力来互补实现了一套无间隔的no_gap模式,用来弥补纯sequence在欧度无处不在的事务应用中不会被连带回滚的特性,牺牲一些性能换取序列绝对连号用于某些特殊高要求的场景。如业财一体化应用中的会计分录凭证编号。

odoo区块链以太坊智能合约web3.js库jsonrpc协议

odoo的前端一直都是用JSON RPC 2.0远程过程调用传送协议和后端交互的,原生也没有提供REST接口,这一点与以太坊的前端Web3.js库和对应的区块链节点链接方式真是英雄所见略同。我想这也为将来的odoo智能合约业链一体化奠定了共同的协议层基础设施:)

odoo免费合规抢注小程序名称资源储备

移动app时代,手机浏览器手工输入域名访问的频率是非常低的,这就导致域名价值没以前高了。曾几何时,拥有一个优质短域名不管做什么都是一种身份象征。现在手机用户有新需求,要么是应用市场里搜索app名称下载安装,要么直接微信、百度、支付宝、头条、抖音、QQ等国民应用里搜索小程序名称打开使用。

各个平台里的小程序名称如同域名一样,都是唯一并有归属的,且二到三个字的名称也是极其稀缺有限的,谁先注册到就是谁的。不同平台都有自己独立的注册规则,虽然都大同小异,但也有一些细节区别:主要体现在个人和企业注册的功能类目限制、不同主体所允许的最大注册数量、通用词库的范围标准严格程度:)

小程序名称注册审核下来后是需要发布内容的,不然名字资源在一定期限过后就会被平台自动回收。但是如果每个平台的小程序都需要通过传统开发定制来发布上线的话,那成本实在太高了,而第三方的saas服务商平台又很难做到同一份内容可以兼容所有平台。odoo这种开源免费且私有化部署并免开发就可以量产实施出无数个小程序的方案目前是独一无二的。

odoo天生优秀的多实例多账套多公司多网站架构:一个odoo软件可以同时运行多个实例,每个实例可以创建多个账套,每个账套又可以创建多个公司,每个公司还可以制作多个网站。过去互联网时期这是站群系统的基础设施,如今小程序时代则是全网通app的应用支撑。

整个实施发布过程分小程序平台和odoo后台两部分,首先平台里设置好odoo相关域名白名单,小程序代码里再绑定odoo多域名中规划好的一个进行上传。其次配置odooapp相关参数及多层级映射关系,最小的粒度是每一个website页面都可以对应一个独立的单页小程序。然后开始制作相关内容并在真机体验版中预览修改满意,就可以提交给客服进行人工审核,待通过后就可以正式全网发布上线了。

odoo vs uniapp

写在odoo14发布之前
时间过的真快,两年前曾自信以为12版本架构可以稳定几年,没想到odoo自我革命基因这么强,凡是跟不上时代节奏的环节,迟早都会被升级替代掉,问题是时代一直在进步呀:)

于是从odoo13开始,我就在思索与寻觅一个能和其完美互补的搭档,直到我发现并体验了uniapp,又经过将近一年的磨合实践,总算可以将两者融为一体了

如果说odoo是倚天剑,那uniapp就是屠龙刀,刀剑合力,其利断金。后台工业互联网和前端移动互联网技术强强全栈组合,就没有什么需求是不能完成的,这种能伴随一身的感觉很好

从此不管odoo年复一年的迭代发布,都对renjie.me这种互补的、对冲的、跨界的全平台组合栈技术影响甚微了

odoo12 new starting point

ODOO12新起点
终于迎来了12,也是传说中期待的双数版本号
去年这个时候是11,虽也惊喜,但毕竟是python2到3的过渡期,有历史责任包袱的产品还是需要双兼容,于是那个版本是从7持续以来第一个被忽视的版本
所以我们现在的感觉就如同当年还在Windows Mobile的odoo78910,因为专注取舍错过了整个Symbian过渡时期,然后一口气飞奔进入iOS/Android双雄争霸时代
这比喻也许有些夸张,但对定位为开源企业级应用操作系统的我们来说,还是比较合适的:)

随着新产品线开始全面拥抱odoo12已经一个月有余,目前各种感觉都很顺畅,真不愧是一个全新的高起点定制系统:
框架模式方面基本成型,落后的能淘汰的都淘汰了,缺陷的能优化的也都优化了,结构上开始趋向稳定,预计未来大版本升级会容易很多
数据库方面过去成熟稳定的PostgreSQL9低版本已经无法胜任,久违的ORM开始慢慢的启用了一些新特性,长远发展看pg10+要成为标配
XML视图方面更新了更为严谨的rng约束,各种元素及属性将不可随意添加或缺失,有效的规范了页面结构的整体质量
CSS样式方面预处理器由Less改成了与整体框架更为融洽的Scss,核心的Bootstrap库大版本也从经典的3升级到了最新的4,感觉表现层这系列折腾起码要稳定几年了
Python方面彻底进入3时代,以后可能还有一些3.7前后版本的对应兼容库问题,但总算是完全告别2时代了
JavaScript方面基本已经将odoo9以来奠定的框架基础改造至极限,虽不能说很完美,但这一路优化过来已属不易,二次可开发的地方也越多越完善,将来Hack代码的机会不多了

其他应用层面的变化太多就不一一列举了,这里就重点说一个原来的document模块要废弃了,其在表单顶部工具栏的文档附件管理已被底部的mail消息日志功能所整合替代。长远看这也是一个很好的改进,只是可惜了原来依赖该基础模块的一大波第三方模块要被迫转型升级。考虑到要适应多年以来形成的附件操作习惯突然改变,同时我们自己也有直接间接依赖的几十号各类模块需要以空间换时间的兼容使用,特此立项从12版本开始上架维护用于替代的Document Sidebar模块,该应用市场链接https://apps.odoo.com/apps/modules/12.0/document_sidebar/

document_sidebar

odoo html field summernote wysiwyg editor custom

ODOO富文本字段Summernote编辑器自定义
Summernote是一个非常简单灵活所见即所得的HTML在线编辑器,基于jQuery和Bootstrap构建,支持快捷键操作,提供大量可定制的选项

不同版本的ODOO在不同阶段都尝试过各种自定义,比如字体选择、全屏功能以及开发者模式下的源码视图,以下将根据代码odoo/addons/web_editor/static/src/js/backend.js里的默认配置为基础进行自定义调整:

summernote

odoo wechat user info sync issue

ODOO微信用户信息同步问题
Python使用http高级requests库来对接微信开放平台和公众平台非常干净利落,主要两个小问题需要注意一下:

1、用户昵称乱码
正常拉取用户信息所返回的内容编码不太友好,读取时乱码,需要显式设定lang和encoding

2、用户头像时效
如只保存头像链接,若用户更换头像,原有链接将失效,需要用Binary字段存储一份图片二进制base64编码的副本

odoo tree view disable open form content

ODOO列表视图禁止打开表单内容
正常的列表视图做为菜单动作直接打开的话,直接点击是跳转当前动作下的表单视图;还有一种是做为表单视图One2many、Many2many类型的嵌入式列表视图,直接点击打开Dialog窗口展示表单视图,一些特殊的需求场景下往往希望只将信息展示到列表即止,不用更多的详细互动:

原理就是找到相关的行点击入口,通过万能的context扩展一个独立的禁止打开参数,默认不禁止,视图里通过显式声明使用该功能:

 

odoo tree view link text url widget

原生列表视图的url组件会将链接也显式的填充到字段列,如果遇到该字段的链接特别长且参数众多,表格就会撑的很难看,这就需要量身为其定制一种纯显示链接文字的widget:

之后就可以在列表视图中直接使用诸如<field name=”content_url” widget=”link”/>形式的链接文字字段组件