标签归档：django-lb-workflow

Carrot Box流程管理平台

django-lb-workflow 我开发的一个Django流程引擎APP。设计之初是以使用便捷性为目标，自带了完整的模板，希望可以方便的集成到已有系统。尽管已经将django-lb-workflow做到尽量的易用，但距离真正的开箱即用还有一段距离。

Carrot Box是一个完整的Django易用，带了权限管理、部门、角色等必要模块，真正的做到开箱即用。通过对Carrot Box的定制可以方便的改造为OA、工单系统、CRM等业务系统。

Carrot Box的主要特点：

  • 是一个完整的应用，可以直接跑起来，开箱即用。
  • 自带HR模块，支持部门、角色的定义。支持按照部门、角色设置权限。
  • 带了几个范例流程，方便熟悉系统。
  • 包含一个代码生成器的使用范例，用于熟悉如果快速的创建一个自定义流程。
  • simplewf模块使用范例，以纯配置的方式添加新流程。

Carrot Box范例站点

之前的django-lb-workflow范例站点已经切换到 Carrot Box。

地址： http://wf.haoluobo.com/

管理员账号：admin 密码：password

切换为其他用户： http://wf.haoluobo.com/impersonate/search

退回管理员账号： http://wf.haoluobo.com/impersonate/stop

将Carrot Box跑起来：

make init-pyenv
make init
make run

django-lb-workflow 近期更新

前几天又看了一下Django的Class-based views，想着django-lb-workflow的一些设计似乎还需要优化一下，于是又去折腾了一下django-lb-workflow。

Class-based views提高了代码的复用性，但过多的Mixin和继承层次让代码变的不那么容易理解。而且在面对一些“特殊”需求时会变的有些别扭。

一个列表界面搭配一个查询表单是一个很常见的操作，但想要在Django默认的ListView里添加这个查询Form并不太容易。在ListView里通过重载get_queryset方法修改查询内容。通过重载get_context_data修改context内容。按照我的理解合理的方式应当是在get_queryset函数中创建form，在form校验成功后使用form的参数作为查询条件返回查询后的queryset。但get_queryset无法直接同get_context_data函数打交道，必须先将 self.form = form 在到get_context_data中通过self.form来获取form信息。这个过程变的非常不直观和奇怪。最终我还是选择不直接继承ListView，在自定义的ListView中重载get函数，在get函数中处理form和查询。

主要更新

  • 增加“添加会签人”的功能。只有在被加签的人处理完成后，流程才可以流转到下一节点。
  • 去掉 django-el-pagination，使用Django自带的分页功能。
  • 为简化系统使用，增加 simplewf 模块。对于只有一个事项名称和内容的流程，可以不写任何代码，只需要在系统中配置流程节点。

待解决的一些问题

做了上面一些更新后，对这个项目又开始有些倦怠了。下面的这些问题可能要等到下次再对这个项目提起兴趣的时候了。

  • 流程的查看、编辑等权限通过在settings里配置校验函数实现。事实上并不太直观，操作性上也不是特别好。更合理的方式还是将权限控制这部分也放到 Class-based views 中，可以通过Minxin灵活配置。注：Django REST framework权限部分的设计比较完善，相关代码可以直接移植过来。
  • 目前还不支持Django 3.0。Django 3.0移除了部分兼容性代码，导致系统跑不起来。
  • 文档…

为django-lb-workflow增加Pipenv

不知道是否是有项目在用（或是计划使用）django-lb-workflow，最近陆陆续续的收到一些issue。其中大多是咨询django-lb-workflow如何使用，也有些windows平台下的bug，还有就是因为python第三方库版本问题导致跑不起来的。
我使用virtualenv来创建虚拟环境，并使用pip（requirements.txt）管理第三方依赖。在指定依赖时通常都只会指定所需的最低版本，过一段时间不维护依赖就要出问题。
近年来Pipenv开始流行，目前看来很有希望成为今后python项目的标配。
Pipenv为您的项目创建和管理Python虚拟环境，并通过Pipfile 和 Pipfile.lock这 两个文件来管理项目中的Python依赖包。对我来说Pipenv的Pipfile.lock提供了对所有依赖层级的Python包的版本锁，可以有效的避免由于requirements.txt过于简单导致的第三方库版本问题。
希望用了Pipenv后，因为第三方库版本问题导致程序跑不起来的问题可以不再出现。

开始写lbworkflow的文档

文档是一个开源项目很重要的一个组成部分，在我看来一个没有文档的开源项目不是一个合格的项目。最近开始给 django-lb-workflow 写文档。

对我来说喜欢写代码多过写文档，特别是在我英文不灵光的情况下。工作流本身就是一个挺复杂的东西，也不知道最终写出来的文档别人能不能看懂。

目前文档只完成了很小的一部分。里面有一个简单的例子，照葫芦画瓢应当也基本能知道怎么使用了。
文档地址： http://django-lb-workflow.rtfd.io/

lbworkflow预览版

django-lb-workflow 是我开发的一个工作流组件。目前还有很多工作要做，不过主体功能已基本可以使用了。在我看来还远没有到可以发布的阶段，不过还是很想先宣传一下，也希望能收到一些反馈。

关于为啥要挖这个坑，以及一下想法可以见之前的博客： 挖了一个新坑-Django的工作流引擎

演示项目地址：
http://wf.haoluobo.com/
管理员用户：
用户名：admin 密码：password
登陆后快速切换用户：
http://wf.haoluobo.com/impersonate/search/
http://wf.haoluobo.com/impersonate/stop/
流程配置信息查看：
http://wf.haoluobo.com/admin/lbworkflow/

目前还处于零文档的情况，用法只能先看代码了。
测试用例里是一个请假的演示：
https://github.com/vicalloy/django-lb-workflow/tree/master/lbworkflow/tests/leave

挖了一个新坑-Django的工作流引擎

Python和Java相比资源的丰富程度还是要差非常多。就如工作流引擎，Java下商业和开源实现都非常多，Python的就要少很多。因为工作的关系，当初将Python下的开源工作流引擎研究了一遍，始终没有找到合适的解决方案。最终系统中的工作流模块还是自己开发的。

近来决定挖个新坑，开源一个工作流引擎。我希望这是一个认真的开源项目，也希望这个项目能帮忙有相关需求的人解决具体问题。作为一个认真的开源项目，除保证代码质量外，单元测试，文档也都将是必须的。预计这个项目的工作量会有些大，前前后后应当会持续挺长一段时间，希望不要烂尾了。

目前已经开始码代码了，如果感兴趣可以先过去看看： https://github.com/vicalloy/django-lb-workflow

关于这个项目

  • 基于Django且完全不考虑移植到其他框架。
    • 如果考虑移植性系统要复杂很多，也很难保证易用性。
  • 采用半可配置方案以平衡开发及使用的便利性。（注：“半可配置”是我自己取的名字）
    • 数据模型，表单布局，数据校验规则，特殊处理采用编码方式实现。
      • 这部分如要做灵活可配置，配置工具的开发会非常复杂，且配置项非常多，在具体配置的时候也会很麻烦。
      • 这部分功能在开发后改动的情况较少，使用代码实现要灵活的多。
    • 流程节点，审批人，流转关系采用配置方式实现。在管理后台直接通过管理界面进行配置。
      • 根据公司规定，组织结构的变更流程的流转规则，审批人的变动较为频繁，使用代码实现很不灵活，也不方便。
      • 流程节点及节点间的流转这对各类型的流程来说操作都是比较一致的，比较容易采用配置的方式实现。
      • 使用配置实现可以方面的自动画出流程图。
    • 代码生成器
      • 提供代码生成器，只需要完成数据模型的编码，代码生成器会自动生成流程的提交/查看/报表等所有框架代码。