odoo是一个庞大的国际分工产业链，各种背景的爱好者都可以在这个链条中找到自己的归属。经过七年之痒的磨练，renjie.me也总算找到适合的基础研究方向，准备用剩余的人生以工匠精神的态度打磨再造odoo全网通client，这是一个漫长的目标和计划，接下来会坚持分享心路和成果。
c/s架构新瓶装旧酒，万变不离其宗，都是用odoo标准的jsonrpc2.0协议接口进行所有网络通讯。只不过全端开发选型已从最早的GTK、后发的QT到了移动互联网时代的uniapp框架，其最大的特色就是还支持中国国情的小程序和快应用发布。
未来理论上所有odoo原生业务、第三方应用、一二三次开发的定制系统都能天然结合这个强大的基础设施来编译出所需平台的app。从低代码平台角度，踏在odoo巨人的肩膀上，可轻松即时动态地实施出一款免开发的全平台客户端功能应用。从软件开发工具包角度，基于封装odoo底层api和前端渲染引擎的半成品sdk，可高效省心的定制开发odoo私有扩展个性化app。
odoo自媒体系统是部署在客户拥有产权的主机或者阿里云、腾讯云的服务器资源上，日期内容无限发布无限编辑。如同宅基地自建房，有天有地装修风格灵活自如，当然不能违法是底线：）其依托odoo全网通技术将相配套的客户端小程序载体植入到各个自媒体平台，后续源源不断的内容自动化同步输入，最终打通了封闭的自媒体世界和外部资讯内容的长连接。
微信公众号、头条抖音号、百度百家号、阿里大鱼号、腾讯企鹅号等自媒体平台号则是一个个独立的SaaS账号，不同的平台都有不同的规则约束，发文数量和内容时效都有不少限制，媒体内容都存储于平台，多个平台需要自己同步。如同商业地产中的租赁户，受各种物业运营管理约束，删帖屏蔽都是小惩罚，底线是不要被封号。
最后总结两者各有绝对优势，前者主站中心化、后者独立分布式。不能互相取代，最好是互补搭配使用，将最优质的创作内容以最小化的成本进行最大化的传播、分享和搜索。
没有自媒体之前的年代，网站博客是主要的内容营销推广工具，对应大odoo系统的就是website_blog模块，常用于企业新闻、个人动态、品牌故事、知识传播、专题报道等应用场景。每篇博文都是一个网页，有唯一的网址，独立的seo配置，可以被谷歌、百度、360、搜狗、必应等搜索引擎抓取识别并收录。
随着移动互联网时代的到来，各大流量巨头纷纷开通了自媒体号，其封闭的搜索和推广只认自家平台号。创作者为了能够全网发布，各种平台的订阅号注册维护成了标准操作。这在PC年代也就是超大型社区论坛的站内基础功能，各种论坛多账号之间的日常发贴回复则是现在各种媒体号信息同步发布的前身。
进入移动互联网后半场存量竞争后，微信小程序的成功让后来者无不一一效仿，甚至华为小米等硬件厂商也组队快应用联盟加入混战，国内的大前端领域总算迎来独有的辉煌。如果说自媒体是平面的结构化信息，那小程序就是立体的信息化互动，自媒体和小程序不是替代而是互补关系，不仅可以流量协作，组合成自媒体小程序矩阵更是强强联合。
未来自媒体小程序的流行取决于全网通系统成熟化和平台私有搜索和推荐引擎大众化。前者解决技术低成本免开发部署odoo开箱即用，后者解决平台超国民待遇，如使用欧度博客后台发布的信息通过各自平台前端小程序转换成原生内容就和公众号、头条号、百家号、大鱼号、企鹅号等内容一样会被搜索爬虫无差别收录并推送到用户面前。
目前字节跳动、百度、微信平台已经实现了自家小程序页面级的收录和搜索排名支持，其中今日头条和手机百度的推荐信息流里更是频繁出现由自媒体小程序提供的素材内容，而微信也开放了自媒体小程序内容页面直接分享朋友圈的私域流量功能。
原生H5响应式设计自适配是成本最低的，企业版自带主题开箱即用，社区版使用第三方比如OCA组织的web_responsive模块搭配使用效果也很好。各种应用场景广泛兼容，缺点是PC大屏幕菜单不够直观有些人可能不习惯，以及手机浏览器也要加载并执行完整个odoo富客户端框架才能显示过于笨重，体验一般毕竟只是个Web页面。
官方App套壳封装则是进阶之路，UI主题风格虽然不变，但可以在H5的基础上多出一些原生能力替代，比如多套odoo系统用户切换，日期时间下拉框选择控件、消息提醒等功能体验都有所提升。安卓和苹果系统版本都有，缺点就是还没开源无法基于原生能力部分进行扩展开发。
企业微信、钉钉、飞书、WeLink等移动互联网开放平台的集成，odoo整体可以作为其子系统，也可以将各个功能模块平移成各个子应用。其中组织架构和消息通知的互联互通是核心，更多上层应用的一体化整合需要根据需求和成本来定制。优势是有很多开源的通用性模块可参考借鉴和经验交流，取长补短强强联合，最终的用户体验一定是最佳的，毕竟一个国民APP就可完成所有功能。缺点则是odoo就变成没有存在感的纯后台管理和服务支撑了，当然还有一些封闭式的内网环境也不适合。
第三方用RPC协议对接的产品级APP，比如MERP是综合全能型，还有一种是模块应用级对接。这和官方App配置差不多，服务端协议域名端口用户名密码设置正确就可以用了，但是体验完全不同，因为接口只传输必要的数据，界面则是本地化原生控件动态渲染，整体流畅度比HTML页面好太多。缺点就是商业软件没法定制，以及Web前端界面的一些深度二次开发在这里没法体现。
完全定制开发的项目级APP，可以用成本最高性能最好的Android和iOS各端原生开发，也可以先用当下流行轻量级的Vue、React框架重构整个odoo前端UI层，然后用Hybrid混合模式打包成双端应用，更可以用符合中国国情的uniapp、Taro等多端开发框架统一发布微信百度支付宝头条抖音360QQ等战国时代小程序平台的应用需求。
完美理想终身事业型的史诗级APP，吸收上述所有方案经验和精华，不仅支持odoo所有版本，更支持桌面端、平板端、手机端的主流操作系统全部平台的应用程序、APP、小程序、快应用。完全协议原生渲染，包括初始化应用名称、界面主题以及首页、页眉、页脚、菜单等内容都由odoo动态配置实时下发全网通客户端生成。其最大缺点就是如果没有网络将只有一个空白雪花页，优势则颠覆了传统应用的开发方式，只要用odoo最传统的ERP实施理念即可以免开发的拥有自己独一无二的全平台动态同步APP。。。
TinyERP远古时期，是没有Web版的，也就是用Client客户端的，就如同现在手机App一样是需要每台电脑都安装的，俗称C/S架构模式，一般每次升级版本服务端和客户端都需要同步更新。现在看起来很不方便，但是当年这种采用GTK+XMLRPC的解决方案已经是很优秀了，不仅能跨平台支持，还有完整的协议来动态呈现菜单、执行动作、渲染视图及反馈交互。
OpenERP上个世纪，与时俱进的引入了B/S架构Web版，但还保留Client到最后7.0版本才无奈抛弃，毕竟鱼与熊掌很难兼得：Web端的快速革新始终受限于Client端的兼容性，因为动态协议虽美丽，但协议自身还需要不断迭代加强，这是日新月异Web世界与保守稳定Client王朝之间的结构性矛盾。现在renjie.me看来这次革命很及时，又一次走在历史的正确道路上，否则现在估计会有基于WebKit内核的客户端版本。
Odoo改革开放，在HTML5浏览器统一天下的趋势和潮流下，姓open姓erp已不重要了，综合卓越的、基础扎实的、业务饱满的，版权干净的，且历史包袱和技术债务都不重的，完全可以冲击企业级操作系统的宝座，其轻快的日日发新版本腾飞，生态又由与日俱增的appstore应用市场和开源社区保驾护航，使得各种层次的企业级应用开发者都可以在odoo上找到自己的归属与定位。截止目前其在企业应用操作系统的地位犹如Android+iOS合体遥遥领先：所谓的社区版就如安卓开放的架构并自带原生的应用，任何组织都可以基于这个成熟的开源基础设施来打造自己的企业级甚至行业级业务系统，而官方企业版不就是那个封闭的苹果巨人及其相关付费app吗：）
写在odoo14发布之前
时间过的真快，两年前曾自信以为12版本架构可以稳定几年，没想到odoo自我革命基因这么强，凡是跟不上时代节奏的环节，迟早都会被升级替代掉，问题是时代一直在进步呀：）
于是从odoo13开始，我就在思索与寻觅一个能和其完美互补的搭档，直到我发现并体验了uniapp，又经过将近一年的磨合实践，总算可以将两者融为一体了
如果说odoo是倚天剑，那uniapp就是屠龙刀，刀剑合力，其利断金。后台工业互联网和前端移动互联网技术强强全栈组合，就没有什么需求是不能完成的，这种能伴随一身的感觉很好
从此不管odoo年复一年的迭代发布，都对renjie.me这种互补的、对冲的、跨界的全平台组合栈技术影响甚微了
ODOO列表视图序号后端解决方案
市场上很多是基于前端二次开发的，比如在列表头增加首列做为序号列，由于需要对列表的页面结构进行一些覆盖式的修改，导致不同版本之间的兼容性很差，且同类型模块之间也很容易冲突
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
''' author: i@renjie.me ''' class Sequence(models.AbstractModel): _name = 'renjie.sequence' _description = u'序号类' sequence = fields.Integer(u'序号', default=0) @api.model def search_read(self, domain=None, fields=None, offset=0, limit=None, order=None): res = super(Sequence, self).search_read(domain, fields, offset, limit, order) if fields and "sequence" in fields: index = offset for rec in res: index += 1 rec["sequence"] = index return res @api.multi def read(self, fields=None, load='_classic_read'): res = super(Sequence, self).read(fields, load=load) if fields and "sequence" in fields: index = 0 for rec in res: index += 1 rec["sequence"] = index return res |
上述代码将虚拟序号的功能封装为标准抽象模型，适用于模块按需继承给视图直接使用即可
ODOO一对多对多混合字段模型
原生的One2many和Many2many已经可以解决大部分模型之间的关系映射，但在一些特殊场景下还是需要混合两者优点形成一个新的关系模型
如生产制造相关的部件与工序：一个部件是由多个工序所组成，而其工序之间还有调整顺序等要求；一个工序可以在多个部件里的不同位置所引用，也可以在同一个部件里不同顺序多次引用
标准的一对多模型桥接做映射可以自定义明细行顺序、独立参数。缺点是只能一个个添加，无法直接打开被桥接的模型进行操作
标准的多对多模型直接做映射可以批量选择、直接编辑。缺点是不可重复且没有顺序及独立参数，后续基本没有可扩展的灵活性
混合的一对多对多模型则是结合上述两者各自优势进行互补以达到可用性层面的最佳用户体验
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/
ODOO集成Excel xls和xlsx文件读写库
开源物以类聚角度LibreOffice Calc的ods格式是整合电子表格的最佳选择，但由于Excel尾大不掉还有着2003及之前xls格式和2007及之后xlsx格式的历史问题
存储：原生Binary字段是最合适的，但不管最终是文件存储还是数据库存储，程序上都是以base64库的encodestring编码和decodestring解码进行出入
前端：SheetJS库可以用来做附件和报表的预览应用及所见即所得数据的快速结构化导出
后端：xlrd+xlwt、XlsxWriter、OpenPyXL三大Python库各有所长又相互制衡反垄断，根据场景自由组合起来可以做各种类型复杂应用。StringIO和BytesIO可用于中转处理过程中的内存临时存储，避免了要生成和清理文件的麻烦