010213 人员信息集管理

产品定位

功能实现可视化人员信息集管理，满足人员信息的子集管理、应用范围、权限分配的要求。

功能路径：组织人事-->人员信息集管理；组织人事-->人员信息集分配

功能特性

•   实现人员信息集的集中管理：之前人员信息、入职管理的子集都是在base模板中配置childs部分实现，没有一个功能集中管理。人员信息集管理功能就是一个集中管理人员信息集的功能，包括主集和子集信息，该功能的配置将代替人员信息（Employee）、入职管理、信息采集（PreEmployee）的base部分的配置，由系统根据使用场景动态生成。该功能理论上可以覆盖Employee和PreEmployee的所有子集配置场景，标准产品中包括：人员信息管理、我的资料（manager、owner、employee）、入职管理（专员端、员工端）、信息采集（专员端、员工端）。

•   满足组织的子集差异化：之前人员信息的子集不支持不同组织的差异化配置，比如集团企业下，某下级公司有特殊的子集需求，之前是无法实现的，即租户内所有人员的子集信息是相同的（不包括模板拆分或其他二开手段）。使用子集管理功能，可以实现子集的组织分配，即规定某个子集在哪个组织下应用。

•   满足用工类型的子集差异化：对于不同用工类型的人员信息标准差异化的需求，如正式工有10个子集，派遣工只有5个子集，之前是通过模板拆分的方式实现，但会导致所有子集的模板都做了拆分，带来了过大的配置量和不稳定因素。通过子集管理功能，可以配置某个子集应用在哪些用工类型的人员上。比如规定“语言能力”子集应用在正式工、派遣工，但不应用在“季节工”，则正式工、派遣工具有该子集，季节工则没有，且正式工、派遣工使用的是同一个子集配置（同一个场景），并不会做模板拆分。

•   满足子集权限管理：之前标准产品有“子集权限管理”功能，但只能授权给个人，系统的授权还是以“角色”为主，到人的授权有一定局限性。通过子集管理可以将某个子集授权给某些角色查看，比如规定“家庭情况”子集只能由人力资源部长查看，普通人事专员不能查看，则可以创建人力部长的角色，将该子集分配给该角色查看即可实现。

产品说明

子集信息

用于配置每个子集的详细内容，包括模型、显示名称、图标、卡片类型/列表类型的子集 等内容。

该配置基本覆盖了base模板中的内容，系统将根据当前使用场景，动态生成childs配置：

属性说明：

•   编号：唯一值即可。

•   名称：子集管理中使用的名称，方便区分管理即可，比如系统中定义了2个教育经历，分别给正式工、派遣工使用，则该名称可能是“教育经历（正式工）”、“教育经历（派遣工）”以区分。

•   显示名称（child：label）：子集实现显示的名称，如上例中的“教育经历（正式工）”、“教育经历（派遣工）” 都显示为 “教育经历”。

•   图标（child：icon）：子集的图标，如标准的 教育经历：icon-hcm-education， 家庭信息：icon-hcm-relationship。

•   模型名称（child：model）：子集的模型，如教育经历：EmployeeEducation， 家庭信息：FamilyInformation。

•   布局类型（child：view）：卡片类型 / 列表类型，卡片类型（一人一条，子集显示为view样式，比如标准的联系信息子集），列表类型（一人多条，子集显示为list样式，比如教育经历、家庭信息等）。

•   人员id对应字段（child：parent_id）：该子集模型中记录人员id的字段，默认为employee_id。其他模块的模型（如绩效）记录人员id的字段可能不同（绩效应改为obj_id），配置成子集时要注意修改。

•   meta场景：该子集使用哪个场景，标准产品中人员管理的子集使用的是inside场景，我的资料中的则是manager、employee、owner。

•   页面跳转state（child：meta_state）：使用了【meta场景】后，通常不需要配置该属性，特殊场景请在开发指导下使用。

•   子集类型：人员信息 / 待入职人员信息 / 信息采集人员信息，即该子集是用在人员信息（Employee）或者 待入职人员信息（PreEmployee）或者 信息采集人员信息（PreEmployee）

•   子集适用场景：在【子集类型】的基础上的细分，如“人员信息”的应用场景有很多，包括 人员管理、我的资料（包括3个场景，管理者查看员工、员工互查、员工看自己）；“待入职人员信息”也区分专员端、员工端。

•   排序码（child：sequence）：子集的排序

因主子模型在base模板中结构不同（base/child），系统需要为一个人识别到唯一一个“基本信息”，否则无法确定哪个是基本信息，哪个作为子集信息。因此引入限制条件：

（1）控制正式库中只能有1个模型为Employee的信息集，入职、采集中分别只能有1个模型为PreEmployee的信息集。

（2）访问人员详情页时，被查看人员必须具有基本信息，这要求被查看人员本身具有基本信息，且当前用户也必须具有基本信息的权限。

子集类型、子集适用场景

定义子集信息时需要指定“子集类型”、“子集适用场景”。

•   子集类型：人员信息 / 待入职人员信息 / 信息采集人员信息，不可扩展。表示该子集是给正式库的人员使用，还是给待入职的人员使用，或者是给信息采集中的人员使用。

•   子集适用场景：规定该子集是在哪个应用场景中使用，比如”人员信息“（正式库）有很多应用场景：人员管理、我的资料（包括manager、owner、employee），”待入职人员信息“也分专员维护功能（入职管理）和候选人应用（入职预约），”信息采集人员信息“也区分专员端和员工端。该属性就规定了该子集在哪个场景下使用。

标准预制的子集适用场景（子集管理→ 子集应用场景，通过“从标准初始化”）：

•   人员信息：人员管理（inside）、员工资料（本人查看）（owner）、员工资料（管理者查看员工）（manager）、员工资料（员工互查）（employee）

•   待入职人员信息：入职管理（专员端）（entry）、入职管理（员工端）（entryPersonal）

•   信息采集人员信息：信息采集（专员端）（collect）、信息采集（员工端）（collectPersonal）

透过现象看本质

•   子集类型的本质是模型（Employee、PreEmployee），子集适用场景的本质是base模板的场景。

如定义了“家庭情况”子集，子集类型是“人员信息”（Employee），子集适用场景是“人员管理”（inside）、“员工资料（本人查看）”（owner），则该子集只在【人员管理】（Employee.base.inside.json）、员工通过我的资料查看自己的信息（Employee.base.owner.json）时有该子集。

•   因待入职人员信息、信息采集人员信息实际是共用一套模型（PreEmployee）的，程序在场景中做了特殊处理以区分是入职还是采集，此处不赘述。

  一个子集要同时在人员管理、入职、采集中使用，需要配置成3个子集吗？——是的，后续会规划做同步生成。

应用方式解析

人员管理

【乘风破浪有限公司】有二级单位【华东公司】、【西部公司】、【深圳公司】

1、系统中配置了教育经历、工作经历、家庭信息、政治面貌四个子集，正式工全部应用，派遣工只使用教育经历、工作经历，人员信息统一由人事专员维护。

在【人员管理】中的配置方式如下：

2、家庭信息因为涉及员工隐私，规定只有档案管理员、人力资源部总经理可见。

定义一个角色，“档案管理员”，并将该角色分配给 人力资源部总经理，修改子集配置如下：

3、【华东公司】独有的绩效考核方式，要在子集中体现，只应用在【华东公司】的正式工，人事专员、档案管理员可见。

配置如下：

基于上述配置，在【人员管理】中：

员工资料

在“我的资料”中展示 联系信息、教育经历、政治面貌子集，其中正式工有 政治面貌子集，派遣工没有。

且规定：员工查看自己的资料时（employee）可以看到全部子集；领导查看下级资料时，可以查看全部子集；员工之间互查时只能看到联系信息；

在子集管理中配置如下：

注意

1、员工资料增强：以前员工资料是无法实现不同类型的人（如正式工、派遣工）有不同的子集的，但有了【子集分配】后，虽然依然只有3个场景（manager、owner、employee），但具体有哪些子集是动态的了，比如上例中，正式工有政治面貌，派遣工则没有。

2、配置复杂度降低：以前员工资料的子集也是按照manager、owner、employee拆分的，比如要配置一个教育经历的显示方式，要在这三个模板中配置三次，使用上述配置则可以统一使用一个场景，配置一次就可以了。当然，如果就是要差异化，比如同样是教育经历子集，如果要求员工自己看的时候字段多，员工互查的时候字段少，则拆成两个子集即可。

3、在建项目升级：因为以前项目已经按照manager、owner、employee分别配置了模板，所以后续项目升级时会按照多套子集升级。例如上述联系信息子集，会升级成3个子集信息如下。

子集拆分原则

1、不同的【子集类型】，要建成不同的子集：如同样是【教育经历】，在人员信息、入职管理、信息采集中都要使用，要建成3个子集。（后面产品会做便捷创建功能）。

2、相同的子集类型，在不同的应用场景下，配置不同，要建成不同的子集：如【教育经历】，在人员信息管理中，需要显示全部字段，但在我的资料中显示少量字段，且有特殊的列表布局样式，这时候要拆成2个子集（不同的场景）。

产品替换说明

使用子集管理后，之前依赖于base模板的部分配置，需要使用新版本的功能替代，说明如下：

base模板child配置 → 子集管理

启用子集管理后，人员管理、我的资料、入职管理、信息采集等功能中有哪些子集要在【子集管理】中配置，在base模板中配置就没有效果了。

子集权限管理 → 子集管理 子集分配

之前产品有个【人员子集权限管理】功能，可以将子集权限分配给人员，使用子集管理后，将弃用该功能，统一使用【子集管理 → 子集分配】实现权限的管理。

人员信息完整度 → 信息完整度方案

之前人员信息完整度是在元数据配置中设置的，分别在人员管理的base模板和基本信息的info模板中，使用子集管理后，该配置将失效，需要使用标准功能【信息完整度方案】，配置可视化且扩展性极大增强，可以满足更复杂的计算场景。

入职/采集中子集必填 → 人员数据校验方案

之前在入职/采集的base模板中，可以配置子集是否必填（required属性），使用子集管理后，该配置需要使用【人员数据校验方案】（开发中）实现，配置可视化，且扩展性极大增强，将满足更加复杂的数据校验规则。

产品初始化说明

打算使用子集管理的项目，请先详细阅读以上产品说明，再按照下面初始化说明进行操作，如有疑问，可先与产品部联系。

1、生成子集适用场景

路径：组织人事-人事基础设置-信息集应用场景

2、初始化子集管理数据

执行初始化接口：https://项目地址/api/sub.set.apply.state.init.state 

子集管理中没有数据的话直接提交即可，有数据的话传参数“force_init”:true，删除现有子集信息重新生成

3、切换为走子集管理的功能逻辑

以人员管理为例：在对应的base模板中开启插件（注意，人员管理、我的资料、入职、采集需要分别单独开启）

可在功能界面或对象管理中开启插件：

入职对应模版：PreEmployee.meta.base.entry.json；PreEmployee.meta.base.entryPersonal.json

采集对应模版：PreEmployee.meta.base.collect.json；PreEmployee.meta.base.collectPersonal.json

我的资料对应模版：Employee.meta.base.employee.json；Employee.meta.base.manager.json；Employee.meta.base.owner.json；

4、如何新增一个自定义子集？

维护子集基本信息

弹性子集注意model命名方式  ：employee_dynamic_subset.XXX （人员）；  pre_employee_dynamic_subset.XXX （待入职/采集）

子集分配

在功能「人员信息集分配」中，对该子集进行分配

在人员管理中查看，并维护该子集中的字段信息

5、快速创建入职和采集的子集

之前配置子集要在人员管理、入职和采集中配置3遍；

现在子集管理中，提供了快速创建子集的小工具，一键将人员信息中的子集生成到入职和采集中，通过按钮[生成到待入职]、[生成到采集]

6、自定义子集如何进行权限控制？

新增的自定义子集，如果想要在人员主页进行权限控制，可在场景中配置关联组织树。

{
    "fields": [{
        "key": "employee_id_id",
        "field": [
            "employee_id"
        ],
        "hide": true
    }],
    "actions": [{
            "key": "new",
            "hide": true
        },
        {
            "key": "edit",
            "hide": true
        },
        {
            "key": "delete",
            "hide": true
        },
        {
            "action": "COMMON_EXPORT",
            "key": "COMMON_EXPORT",
            "label": "页面导出查询结果",
            "data": {
                "file_name": "页面结果导出",
                "celery_mode": true
            }
        }
    ],
    "relations": [{
            "filter": {
                "employee.id": ":employee_id"
            },
            "model": "Employee",
            "name": "人员基础信息",
            "key": "employee"
        },
        {
            "filter": {
                "job_info.employee_id": ":employee_id",
                "job_info.begin_date": {
                    "lte": "=date_"
                },
                "job_info.end_date": {
                    "gt": "=date_"
                },
                "job_info.position_type": 1,
                "job_info.on_job": "1"
            },
            "model": "JobInformation",
            "name": "任职信息",
            "key": "job_info"
        },
        {
            "filter": {
                "job_info.position_id": ":position.origin_id",
                "position.begin_date": {
                    "lte": "=date_"
                },
                "position.end_date": {
                    "gt": "=date_"
                }
            },
            "model": "OrgPositionHistory",
            "type": "outer",
            "name": "岗位信息",
            "key": "position"
        },
        {
            "filter": {
                "position.parent_id": ":department.origin_id",
                "department.begin_date": {
                    "lte": "=date_"
                },
                "department.end_date": {
                    "gt": "=date_"
                }
            },
            "model": "OrgDepartmentHistory",
            "type": "outer",
            "name": "部门信息",
            "key": "department"
        },
        {
            "filter": {
                "department.subordinate_unit_id": ":unit.origin_id",
                "unit.begin_date": {
                    "lte": "=date_"
                },
                "unit.end_date": {
                    "gt": "=date_"
                }
            },
            "model": "OrgUnitHistory",
            "type": "outer",
            "name": "单位信息",
            "key": "unit"
        }
    ],
    "role": {
        "role": "cm-org-emp.emp",
        "field": "department.origin_id"
    }
}

配置好后，可实现在主界面切换子集时，进行权限控制。