Worktile审批

1. 本课程是Worktile的一部分。

2. 演示

1. 分组管理

2. 模板管理

3. 审批表单设计
   表单设计器是个拖拉拽的可视化编辑器，本身就是个简易版的零代码应用开发工具，包括三部分：可选控件、表单主体及表单和控件属性设置。
   属性包括：属性类型，属性名，提示文字，是否必填等。
   单选框、复选框、下拉列表有选项列表。
   明细是个特殊控件容器，可包含其他控件。明细里面的数字类型的控件还可以有“是否参与明细统计”，“是否条件流程因素项”两项属性。

重点、难点：

1. 拖拽使用的是Sortable.js。
   列表之间拖拽的要点有相同的组名（group name），可选控件列表的组的拉取选项（group pull）用的是clone，表示被拽出列表时是克隆一份给表单主体而不是被拽离走了，同时组不可添加新控件（put: false）。group: { name: "group", pull: "clone", put: false }。
   嵌套列表推荐配置：{ fallbackOnBody: true, swapThreshold: 0.65 }。
   onSort函数要分是表单主体里控件间排序还是从可选控件里拉进来一个控件，拉进来时参数里有个pullMode是clone（对应前面的拉取选项clone），

2. 把控件从一个位置拖到新的位置时，是先把它从原来的位置（oldIndex）移除，在插入到新位置（newIndex）
   $f.x.属性.splice($l.e.newIndex, 0, $f.x.属性.splice($l.e.oldIndex, 1)[0])

3. 单击选中一个表单控件时配置控件属性路径：$v.审批表单.属性 = "属性." + $index；而明细里的控件属性路径则是：$v.审批表单.属性 = "属性." + $parent.$index + ".属性." + $index，它们是被嵌套在明细控件内的，为了不触发外层事件用$event.stopPropagation()阻止事件传播
   编辑控件各属性时添加onChange事件，即使是空事件也会随着输入或勾选而实时更新/（渲染）表单主体对应控件从而有更好的编辑体验。

4. 控件有多种类型，每种类型的表现形式和属性都不同，所以要根据不同的类型用渲染条件来控制显示哪种类型的控件。大家可根据实际需求进一步丰富控件列表。

5. 重新渲染
   表单主体是用一个挂载组件包装的，当添加新控件或控件排序时给$v.F5属性一个新值使表单重新渲染。
   明细里的属性列表也如此，但使用另一个变量$v.F5明细仅重新渲染明细的属性。

不同类型审批，审批流程及每个流程的审批人不同

1. 自由流程
   提交人可以自由选择审批由几步组成，每个阶段需要谁来审批，灵活性比较强，适合复杂程度不高且审批流程不定的审批，但不利于审批流程的规范性。

2. 固定流程
   无论申请条件如何，审批流程都是固定，适合复杂程度不高但流程固定的审批。

3. 分条件设置流程
   最常用的审批流程，当申请条件不同时，需要不同的审批流程和审批人，如：报销金额低于5000时只需要1级主管审批即可，报销金额在5000至10000时，需要添加2级主管审批，大于10000时则需要在添加boss审批。

4. 审批知会人
   审批中不需要某些成员参与审批流程，但需要让TA知晓这个审批。

重点、难点：

1. 部门栏是公司的组织架构，可按部门分级添加一个或多个审批人。“部门主管”是个未确定的变量，会在发起审批时得到替换成具体人员。

2. 分条件设置流程中可通过表达式定义某种条件下的审批流，如招聘人数或报销金额越多需要参与审批的人也越多层级越高。注意条件的连续性，不要留下空挡。

1. 填写申请表单

2. 实时计算明细统计

3. 实时计算审批人
   获取部门主管

4. 提交审批
   验证表单必填项。
   生成审批编号

重点、难点：

1. 明细统计分为合计与总计
   合计是某个待统计字段之和，总计是各待统计字段合计之和。
   累加用：reduce("$acc + $x", 0)

2. 条件流程中根据前面编好的条件表达式（$x.条件）从审批流程列表中找到符合条件的流程。一个要点是执行条件表达式是要把申请表单内容（$f.申请）传进去作为执行环境；另一个要点是找到流程的审批人列表需要克隆一下赋给申请表单的待审批人，因为接下来的审批改成会更改此待审批人（如替换部门主管，转交审批人）而我们并不想影响到原流程中的审批人。
   $f.申请.待审批人 = 审批流程.find('exc($x.条件, $f.申请)').审批人.clone()

3. 页面onReady里定义了“找部门主管”函数，申请表单挂载时执行，条件流程中输入数字时也会执行。
   难点是递归调用“$exp.部门主管”，部门从上往下一级级递归寻找直到到达申请人所在部门时被stopIf()停止。每次递归都把当前部门传给表达式执行环境。

4. 审批编号是申请年月日+4位数的序列号。序列号是每天从1开始的唯一数，每次申请都从数据库增加（$inc）1得到。

5. 提交审批时从待审批人列表把第一个审批人移出来作为当前审批人，并发送即时消息给TA。

1. 当前状态

2. 申请人

3. 审批详情
   各类型数据展示
   明细及其合计、总计

4. 审批流程

5. 知会人

6. 评论

7. 查阅记录

重点、难点：

1. 分类报销可以把审批详情较全面地展示，它外层的是个table元素的数据组件，里面由4个tbody，但它控制的是第二个用来展示明细的数据组件，第一个tbody是空的，用来占位，第三个用来展示属性列表，第四个放在最下面用来显示总计。
   值得玩味的是第二个用来展示明细的数据组件没有配置HTML元素，即它本身并不会渲染成HTML元素，而是为了控制它第一个子元素的渲染，即循环展示明细列表（第二个子元素用来展示合计），而每个明细又有多项属性，再次使用数据组件，而明细里还有数组型属性要用到数据组件（比如上传多个附件）。
   这是个嵌套使用数据组件极致展示复杂数据的例子。

2. 审批流程中的数据组件控制的是第二个li，由审批流、当前审批人、待审批人合并得来，第一个li固定放申请人，不受数据组件控制。
   这里的【审批流】是已经参与审批动作的人，可能包含撤销人（申请人自己）和被转交人。每次动作都往审批流中推入相关信息：$push: { "x.审批流": { 谁: $c.me._id, 时间: date(), 动作, 意见 } }

3. 评论的input并不是用来输入的，而是点击时（onFocus时让$v.modal.评论 = true）弹出含有textarea的评论表单，点击其他地方能收回评论表单是因为在更高层的地方（modal-detail-main）把$v.modal.评论置空。

4. 审批模态窗里有个挂载组件，非申请人每次打开审批模态窗时都往【审批查阅】添加一条查阅记录，

5. 为了减少审批的信息量，把审批评论和审批查阅都保存到关联xtk表中，以审批._id作为key。在各类审批列表场景中都不读取评论和审批查阅，打开审批模态窗时在上面的挂载组件里默认读取评论，但依旧不读取审批查阅。

1. 同意审批

2. 拒绝审批

3. 转交审批

4. 撤销审批

5. 评论审批

6. 查阅审批

1. 我申请的

2. 我审批的

3. 知会我的

4. 即时消息通知

5. 发送到聊天

重点、难点：

1. 获取最新数据/重新渲染
   待审在不同的人之间流转，信息变化快速。除了希望等待“我”审批的申请用即时消息通知到“我“以外，还希望在审批页面时能收到跟“我”相关的【待审批】申请。
   待审批数：在根节点有个挂载组件，用$v.F5作为key表达式，每当$v.F5变化时（提交、撤销、同意、拒绝、转交审批）都会重新拉取“我”相关的待审批数量
   审批列表：审批列表的table用一个以$v.tab + $v.F6为key表达式挂载组件包装。当在左侧导航栏（我申请的、我审批的，知会我的）或右上角标签栏（待审批、已审批）切换时都会重新拉取最新审批列表。