com.kingdee.eas.base.permission.app.util.BizObjectOrgUtil.getBizOrgPropertyName(ctx, new com.kingdee.bos.util.BOSObjectType("4A44F49F"));
问题背景:任务委托的配置和理解看起来很简单,但一旦遇到委托不生效的问题如果不真正理解匹配逻辑,就无从下手。
于是这篇文章我们讲清楚这块逻辑,让任务委托不生效的问题定位不再困难。
任务委托三大要素:
1、流程定义
2、委托人+受托人
3、组织范围
分析:
1、流程定义,委托人,受托人这些在配置上一眼可以看到,一般不会有疑问,这里就不做赘述。
2、重点就在于组织范围的匹配,匹配逻辑:
先取业务单据的主业务组织字段,如果有,就取主业务组织字段对应单据主业务组织类型的 组织;
如果没有,就取上下文中的 对应单据主业务组织类型 的组织。
基于以上的逻辑,一些问题思考如下:
1、业务单据需要指定主业务组织字段名
由于本身上下文的生成就有一定规则,比如工作流中的上下文就取 模拟流程发起人登录之后的上下文,那么组织信息就是流程发起人的默认组织。然而流程发起人的上下文跟任务委托配置的组织显然是不相关的,且是不可控的,所以我们建议业务单据必须重写主业务组织字段方法指定主业务组织字段名。
这个问题需要业务开发处理,常见问题为SHR的单据info类默认都没重写方法 getBizOrgPropertyName();
举例:
如何检查业务单据的主业务组织字段是什么?
//1、根据单据id查询到bostype
//2、根据bostype查实体的主业务组织字段(查询分析器-选中下面这段脚本-点 执行服务端脚本)
2、业务单据 的主业务组织字段 跟 其主业务组织类型 要匹配
如:某SHR单据 的主业务组织类型是HR组织,指定的主业务组织字段是单据的行政组织,然而这个行政组织字段实际不是HR组织,导致组织匹配不上。
这种问题就要修改单据实体的主业务组织类型为Admin(行政组织)。
3、以上问题都搞定了就肯定能找到我们要匹配的组织了,然后会取该组织的长编码flongnumber来判断是否在任务委托配置的组织范围内即可。
如:那某HR单据举例,如果单据的主业务组织类型是Admin,主业务组织字段名是adminOrg,则我们找到的组织就是行政组织表(t_org_admin)中该组织,如果要找该组织是否是任务委托配置的组织的下级,就是从其flongnumber中去匹配就知道了。