loonflow/sphinx_docs/source/q&a.rst

==============
常见问题
==============

- 为什么不使用外键

关于是否使用数据库外键，网上各有说法，各有利弊。本人基于如下几个原因所以没使用外键:1.外键属于业务逻辑，不应该吧这种
逻辑放到数据库层而加重数据库的负担 2. 使用外键会有数据的强校验，导致日常维护时会有些麻烦(后来发现其实可以使用
db_constraint=False, on_delete=False参数来关闭强校验,通知也保留外键本来的便利性, 1.0版本也有开始少量应用)
3.有些公司db规范里面就是不允许使用外键的

- 为什么没使用django rest framework

drf在未使用外键的情况下,无法发挥其价值。无显式外键时，自定义序列话返回数据需要逐条记录查询关联信息，效率非常低

- 为什么使用http api方式提供服务 而不是python三方包

1.loonflow的理念是:工单应该是嵌入到各个系统中(如oa,cmdb,运维平台、客服系统等等), 这些系统通过后端api调用loonflow。
所以loonflow只有管理界面(v0.1版本直接使用django admin,后面会重写管理界面)。后续会提供几个调用方demo供大家参考。
感谢@youshutong帮忙写的调用方demo(vue+django): https://github.com/youshutong2080/shutongFlow 
另外帮忙jimmy201602写的demo(bootstrap+django): https://github.com/jimmy201602/workflowdemo 
2.loonflow引擎功能较复杂功能较复杂不适合使用包的方式

- 为何不建议调用方前端直接调用loonflow

调用方和loonflow之前需要做权限验证，签名算法考虑到安全只能写在调用方后端;作为引擎,loonflow不提供用户登录验证功能,
只校验调用方的合法性，所以登录验证需要做在调用方自己的后端;每个调用方除了纯粹的工单的功能，还会需要一些额外的功能，
比如根据自定义字段筛选工单列表，loonflow提供了工单列表的接，但是因为loonflow的自定义字段是纵表形式存储的，
无法提供根据这些字段来筛选工单列表。如果需要自定义字段的筛选，需要调用方自己保存一份工单数据，用于筛选;
比如需要做一个项目全生命周期管理的系统，需要用到工作流。 但是还有比如发布,获取人员信息、和其他系统交互、
日志查看、项目数据统计等等功能。这些需要做在自己的后端

- 调用方是否需要保存工单的基础数据

根据情况而定，如果调用方在显示工单数据的时候需要显示更多相关信息，可以本地保存一份附属信息与loonflow中对应关系。
针对本地保存的情况，如果涉及工单流转的字段(如参与人等)，在本地修改时需要同时调用loonflow修改loonflow中保存的字段
的值(r0.2以后版本中提供了修改工单字段值的接口)

- 如何限制用户查看工单权限

默认会限制工单的查看权限(通过api获取工单详情时,只有username参数是工单相关人员时才能获取到数据)。如果需要放开限制，
可以修改工作流配置中的“查看权限校验”为否。权限配置只针对工作流的，多个类型的工作流需要单独配置

- 为何需要同步用户及部门信息到loonflow

因为工单流转涉及到较多的用户信息获取，所以需要将用户信息(包括部门)同步到loonflow的账户系统中。同步部门信息的时候，
如果发现部门被删除，建议修改部门名字，如前面加个 “已废弃:”,否则如果该部门存在某个工单的当前处理人的时候会有问题。
用户离职的情况设置is_active=0.另外用户密码请随便填写(为了不允许普通用户登录)。管理员账户请通过
python manage.py creatsuperuser来创建。只需要管理员实现一个同步脚本定时执行即可,其他调用方不用考虑此问题

- 为什么调用方demo中要保存用户信息

调用方demo可以理解为你的cmdb、客服系统、运维系统、oa系统。这些系统你可以自己管理用户信息，也可以在涉及用户方面的地方都调用接口来获取。
不同公司提供用户信息的方式不同，所以demo里面自己实现了个简单的用户管理供大家参考。

- 为什么调用方demo中的用户，也需要存在于loonflow的用户中

loonflow的工单在流转过程中，如目标状态的处理人是创建人TL，那么loonflow需要在自己的用户体系中找到这个用户所在部门，
然后获取这个部门的审批人或者tl信息

- 如何支持根据工单的自定义字段查询

loonflow只提供工单基础字段的查询，如果需要针对自定义字段的查询，请在自己系统中保存一份工单数据(注意工单处理过程中，
如果有字段修改，也需要更新自己系统中的数据)

- 工单列表支持排序

只支持根据创建时间排序。其他字段排序可以在调用方系统中保存一份数据来自己实现排序，然后只有在获取工单详情的时候调用loonflow接口

- 工单类型需要支持多级

比如需要支持“运维-权限申请-vpn权限申请”。 因为loonflow的工作流只有一级，如果需要支持多级类型,需要在调用方保存一份工单类型
与loonflow工作流关联的数据。表字段可以如下：type_id, type_name, up_type_id, loonflow_workflow_id

- 如何实现工单的评分和处理优先级功能

因为不同公司对于评分的需求不同，如评分有1星、2星、3星，满意、及格、不合格。 如优先级有高、中、低，紧急、中等、不急等等。
因此loonflow不提供通用功能。用户可以针对不同的工作流定义不同的自定义字段以表示评分或者优先级，自定义字段可以选择checkbox类型，
也可以通过字段的标签灵活处理(前端根据约定好的标签，特殊显示)。 当然如果你这边的需求非常统一，你可以给loonflow的基础表中添加一个字段，
以实现公用。不过修改此逻辑后，后续loonflow更新时需要特别注意下

- 为什么为提供拖拽生成工作流的功能

loonflow目前非商业化系统，面向用户是有一定计算机基础的人。完全拖拽只能实现非常基础的工作流的配置，复杂点的还是需要填写一些个性化的如标签来实现
定制功能。涉及定制功能的工作流配置使用当前方式效率不比拖拽低。因此拖拽生成工作流的功能优先级较低，会等其他功能都比较完善后再考虑支持

- 为什么不用migration维护表结构

django提供的migration功能建议只用于自己的开发环境。生产环境直接操作执行风险较大，在实际生产环境中涉及数据库表结构的变更一般需要dba审核，
这种审核是基于DDL语句来审核的（没理由要求DBA查看你的django modal）

- 遇到问题如何自行排查

loonflow在出现报错时会记录详细的堆栈日志，在遇到问题时，请第一时间查看日志。如果日志中没有异常，请查看浏览器控制台中各请求的返回结果

- 如何查看日志

日志默认是记录在启动loonflow进程的用户家目录中的loonflow.log, 配置在settings/config.py(从settings目录下其他simple文件复制出来)。
使用uwsgi生产环境运行时候，当前无法打印日志文件(该问题后面有空会解决下)，可以在uwsgi日志中查看。

celery任务日志路径取决于你启动celery任务时候指定的日志文件路径

- 配置工作流时，提示"DataTables warning, unkown parameter"

此问题一般是因为配置错误导致，如状态的参与人类型选择的是部门，参与人填写的部门id实际不存在

- 工作流修改后流程图无法展示

可能出现的原因是删除了某些状态，但是某些流转中的源目标状态还引用了这些状态导致

- 配置好工作流后，调用方无法列出相应的工作流

配置完工作流后需要给调用应用授权，“用户及权限-调用权限”中配置

- 工单详情中显示的信息字段很少或者没有字段信息

详见: https://github.com/blackholll/loonflow/issues/37

- 部署相关问题

详见文档"如何运行"章节

\ **有问题请优先查文档及在github上提issue，再考虑到群里(qq群:558788490)咨询, 群内问题我会每天晚上21:00-第二天8点之间答复(可能会遗漏)。
github 上issue不会遗漏。常见问题我会定期整理添加到此文档中**\