# 常见问题

# 用户(jAccount)选取

流程平台提供了内置的用户选取功能,通过组合字段的数据类型为User、渲染类型为Suggest/Suggest2,即可在表单上提供输入用户姓名(支持拼音)、所在部门名称(支持拼音)或者代码以及学工号来快速选取用户的功能。 选取的用户以其账号(jAccount)为标识,并且同步提供了用户相关的一些属性(见User类型的属性)。

User类型选择的用户范围包括全部jAccount账号,其中既有学生、教职工等个人账号,也有集体账号等非个人账号,因此在提供用户选取功能时,开发者应该针对实际需求对选取的范围进行配置,除非有特殊理由,没有任何限制的User类型是错误的

对User类型选择的用户范围进行限制用过它的Parent、UserFilters两个属性进行,这两个属性的作用相同,区别在于UserFilter只能配置静态的过滤条件,Parent则可以配置另一个字段并将该字段的值来做为过滤条件。如果这两个属性均配置了条件,则取交集。

过滤条件的语法为:[部门代码][:岗位代码],支持多组条件用逗号分割,多组条件取并集,下表举例说明过滤条件的含义:

过滤条件 匹配的部门 匹配的岗位 说明
70000
70000:#
医学院及所有下级部门 所有身份岗 岗位过滤条件为空等价于#,表示所有身份岗
70000* 医学院及所有下级部门 所有身份岗 部门可通过后缀指定是否包含下级部门,默认为包含所有,等价于后缀为*
70000= 仅医学院本级 所有身份岗 部门后缀=表示不包含任何下级部门
70000+ 医学院及所有非独立的下级部门 所有身份岗 部门后缀+表示包含下级非独立部门,这里表示不包括附属医院
70000:* 医学院及所有下级部门 所有岗位 岗位过滤条件为*表示不限制岗位,将包含医学院的学生、教职工、附属单位职工和集体账号等
70000:BuiltInFaculty 医学院及所有下级部门 教职员工 该过滤条件选择了医学院及所有下级部门的教职工,但由于附属医院的职工不在教职工岗位上,因此实际上选择不到附属医院的用户
70000:BuiltInFaculty,70000:BuiltInAffiliated 医学院及所有下级部门 教职员工和附属单位职工 该过滤条件选择了医学院及所有下级部门的教职工和附属单位职工
:BuiltInFaculty
*:BuiltInFaculty
#:BuiltInFaculty
所有部门 教职员工 部门为空等价于#或者*,都表示不限制

特别注意,当User的Parent是Organize字段时,等价于过滤条件1,匹配的是所有身份岗,而不是所有岗位。

# 动态限定选人控件的部门和岗位

如果想根据表单当前填写人的部门,或者表单上选定人的部门,或者表单上选定的部门等表单字段来限定选人控件的部门如何做到呢?UserFilter设置是不支持填写变量的,Parent设置可以选择一个字段来限定User数据类型的选人范围,但是也只能选择一个表单的字段,如果表单上有这个部门字段,那么就可以选择这个部门字段来限定,如果部门字段是表单上的一个User控件的部门,那么需要增加一个Organize数据类型的隐藏控件,将表单上User的部门记录下来,记录的方式可以用公式,也可以用messenger,视需求和数据定。如果选人控件想限定的是只能拉取某部门下的某岗位的人,那么可以用一个String类型的隐藏字段,将部门和岗位用冒号分隔拼接起来,比如将fieldHidden的动态公式value设置为$fieldOrganize+':BuiltInStudent',那么Suggester中就只会出现指定部门的学生了。

# 带出所选取用户的部门和学工号

通过User + Suggest选取了一个用户后,该用户相关的一些属性中包含用户的部门信息,可以用来确定用户的部门。必须注意的是,交大使用多身份体系,一个用户可以同时拥有多个身份,因而可以同时属于多个部门,所以当出现带出用户部门的需求时,开发者必须意识到应当给予用户选择的途径。 同时,开发者需要关注带出的部门的级别,一般校级业务需要带出的是用户所属的顶级部门。

推荐的实现方式为:

  • 1、如用户选取中建议的,User字段上需要配置针对性的过滤条件,对选择的用户范围进行限制。
  • 2、部门字段使用的数据类型为Code,不指定代码表,渲染类型为Select。
  • 3、配置部门字段上配置dataSource为 fieldUser.indepOrganizeFiltered (假设User字段的名称为fieldUser)

属性indepOrganizeFiltered的前缀indep表示该属性的内容为顶级部门,后缀Filtered表示该属性的内容为匹配User过滤条件后的部门。特别的,当该部门字段为必填时,如果过滤后的部门仅有一项,表单前端将自动选择,用户并不需要额外操作选择,这符合大多数用户的实际情况。

User类型中和部门相关的属性包括:

属性名 说明
organize 用户按照身份岗过滤,所有的所属实际部门(不一定为顶级)
organizeFiltered 用户按照过滤条件过滤,所有的所属实际部门。如果未定义过滤条件,该属性不存在
indepOrganize 用户按照身份岗过滤,所有的所属顶级部门
indepOrganizeFiltered 用户按照过滤条件过滤,所有的所属顶级部门。如果未定义过滤条件,该属性不存在
organizeCode 用户按照身份岗过滤,所属实际部门的第一项部门的代码。不可做dataSource,不推荐使用该属性
organizeName 用户按照身份岗过滤,所属实际部门的第一项部门的名称。不可做dataSource,不推荐使用该属性

带出用户的学工号和带出部门类似,用户可能拥有多个学工号,开发者应当给予用户选择的途径。

推荐的实现方式为:

  • 1、如用户选取中建议的,User字段上需要配置针对性的过滤条件,对选择的用户范围进行限制。特别说明,仅身份岗存在学工号,如按照管理岗过滤,则无学工号
  • 2、学工号字段使用的数据类型为Code,不指定代码表,渲染类型为Select。
  • 3、配置学工号字段上配置dataSource为 fieldUser.userCodesFiltered (假设User字段的名称为fieldUser)

属性userCodesFiltered的后缀Filtered表示该属性的内容为匹配User过滤条件后的学工号。特别的,当该学工号字段为必填时,如果过滤后的学工号仅有一项,表单前端将自动选择,用户并不需要额外操作选择,这符合大多数用户的实际情况。

User类型中和学工号相关的属性包括:

属性名 说明
userCode 用户所有学工号的第一项。不可做dataSource,不推荐使用该属性
userCodes 用户所有的学工号。
userCodesFiltered 用户按照过滤条件过滤后所有的学工号。如果未定义过滤条件,该属性不存在

# 带出当前用户的部门和学工号

带出所选用户的部门的学工号类似,当前用户也可能存在多个部门和学工号,开发者应当给予用户选择的途径。 推荐的方法也类似,区别是当前用户的部门、学工号相关的信息位于全局变量,使用全局变量来为dataSource提供数据即可。

全局变量中和当前用户相关的部门和学工号变量包括:

变量名 说明
_VAR_ACTION_ORGANIZE 当前用户按照身份岗过滤后,所有实际部门的第一项。不可做dataSource,不推荐使用该属性
_VAR_ACTION_ORGANIZES 当前用户按照身份岗过滤后,所有的实际部门。
_VAR_ACTION_INDEP_ORGANIZE 当前用户按照身份岗过滤后,所有顶级部门的第一项。不可做dataSource,不推荐使用该属性
_VAR_ACTION_INDEP_ORGANIZES 当前用户按照身份岗过滤后,所有的顶级部门。
_VAR_ACTION_USERCODES 当前用户按照身份岗过滤后,所有的学工号。
_VAR_EXECUTE_INDEP_ORGANIZE 当前用户按照执行岗位过滤后,所有顶级部门的第一项。不可做dataSource,不推荐使用该属性
_VAR_EXECUTE_INDEP_ORGANIZES 当前用户按照执行岗位过滤后,所有的顶级部门。
_VAR_EXECUTE_ORGANIZE 当前用户按照执行岗位过滤后,所有实际部门的第一项。不可做dataSource,不推荐使用该属性
_VAR_EXECUTE_ORGANIZES 当前用户按照执行岗位过滤后,所有的实际部门。
_VAR_EXECUTE_USERCODE 当前用户按照执行岗位过滤后,所有学工号的第一项。不可做dataSource,不推荐使用该属性
_VAR_EXECUTE_USERCODES 当前用户按照执行岗位过滤后,所有的学工号。注意:仅身份岗包含学工号信息,如果执行岗位限定的不是身份岗,无法获取学工号信息