智电运维平台组织架构改造二期

数据库设计

t_bloc 集团

因为集团本身不可删除，只可进行停用，故不增加逻辑删除字段。

create table t_bloc  
(  
    id                         int unsigned auto_increment comment '主键' primary key,  
    name                       varchar(100)                            not null comment '集团名',  
    abbre                      varchar(10)                             not null comment '集团简称',  
    short_code                 varchar(10)                             not null comment '集团简码',  
    uniform_social_credit_code varchar(18) charset utf8                null comment '统一社会信用代码',  
    main_company_id            bigint        default 0                 not null comment '集团主体公司',  
    logo                       varchar(500)  default ''                not null comment 'logo的url',  
    remark                     varchar(1000) default ''                not null comment '备注信息',  
    valid_period_start         date                                    null comment '有效期开始日期',  
    valid_period_end           date                                    null comment '有效期结束日期',  
    enable_flag                bool          default true              not null comment '启用状态，进入或退出有效期时，会自动停用启用',  
    create_time                timestamp     default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by                  int           default 0                 not null comment '创建人',  
    update_time                timestamp     default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '修改时间',  
    update_by                  int           default 0                 not null comment '修改人',  
    constraint udx_name unique (name),  
    constraint udx_abbre unique (abbre),  
    constraint udx_short_code unique (short_code),  
    constraint udx_uniform_social_credit_code unique (uniform_social_credit_code)  
)  
    COMMENT ='集团信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB  
    AUTO_INCREMENT = 2;

插入现有的集团信息，当前只有上海起源芯动力一个集团，且长期有效：

INSERT INTO t_bloc (id, name, abbre, short_code, uniform_social_credit_code, main_company_id, valid_period_start, valid_period_end, logo, enable_flag, remark, create_by, update_by) 
VALUES (1, '上海启源芯动力科技有限公司', '启源芯动力', 'HHHH', '91310000MA1JNY8R6H', 1000001, null, null, '', 1, '', 0, 0);

company 公司

部分主体存在没有所属集团的情况，故设置默认值0，代表无所属集团。

ALTER TABLE company  
    ADD COLUMN bloc_id  INT NOT NULL DEFAULT '0' COMMENT '集团id，如果主体没有集团则为默认值0',  
    ADD COLUMN group_id INT NULL     DEFAULT NULL COMMENT '属于的分组';

需要更新原有的启源集团的主体的所属集团信息 （原sql脚本中已做修改）。

t_authorized_version 授权版本

因授权版本不可删除，故不增加逻辑删除字段

create table t_authorized_version  
(  
    id          int unsigned auto_increment comment '主键，小于100的版本为系统固定版本不可删除' primary key,  
    name        varchar(20)                           not null comment '授权版本名称',  
    description varchar(50) default ''                not null comment '授权版本说明',  
    enable_flag bool        default true              not null comment '启用状态',  
    create_time timestamp   default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by   int         default 0                 not null comment '创建人',  
    update_time timestamp   default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '修改时间',  
    update_by   int         default 0                 not null comment '修改人',  
    constraint udx_name unique (name)  
)  
    COMMENT ='授权版本信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB  
    AUTO_INCREMENT = 100;

增加启源集团使用的全量版本：

INSERT INTO t_authorized_version(id, name, description, enable_flag, create_by, update_by)  
VALUES (1, '全量版', '', 1, 0, 0);

t_authorized_version_application 授权版本的应用程序id

create table t_authorized_version_application  
(  
    version_id     int unsigned                        not null comment '授权版本id',  
    application_id int unsigned                        not null comment '应用程序id',  
    type           int unsigned                        not null comment '授权类型（1 应用程序全量，2 应用程序指定功能）',
    create_time    timestamp default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by      int       default 0                 not null comment '创建人',  
    update_time    timestamp default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '修改时间',  
    update_by      int       default 0                 not null comment '修改人',  
    PRIMARY KEY (version_id, application_id)  
)  
    COMMENT ='授权版本的应用信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB;

t_authorized_version_function 授权版本的功能信息

create table t_authorized_version_function  
(  
    version_id     int unsigned                        not null comment '授权版本id',  
    application_id int unsigned                        not null comment '应用程序id（冗余字段）',  
    function_id    int unsigned                        not null comment '功能id',  
    contains_child bool                                not null comment '授权的功能是否包含他的所有子功能，是则不需要添加子功能默认拥有所有子功能，否则只拥有配置的子功能权限',  
    create_time    timestamp default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by      int       default 0                 not null comment '创建人',  
    PRIMARY KEY (version_id, function_id)  
)  
    COMMENT ='授权版本的功能信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB;

t_bloc_authorized_version 集团的授权版本信息

create table t_bloc_authorized_version  
(  
    bloc_id    int unsigned not null comment '集团id',  
    version_id int unsigned not null comment '授权版本id',  
    create_time      timestamp default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by        int       default 0                 not null comment '创建人',  
    PRIMARY KEY (bloc_id, version_id)  
)  
    COMMENT '集团授权版本信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB;

单个集团可赋予的授权版本信息的最大限制 @如旭

t_bloc_admin 集团管理员信息

create table t_bloc_admin  
(  
    bloc_id    int unsigned not null comment '集团id',  
    account_id int unsigned not null comment '管理员账户id',  
    create_time      timestamp default CURRENT_TIMESTAMP not null comment '创建时间',  
    create_by        int       default 0                 not null comment '创建人', 
	update_time timestamp   default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '修改时间',  
    update_by   int         default 0                 not null comment '修改人',   
    PRIMARY KEY (bloc_id, account_id)  
)  
    COMMENT '集团管理员信息'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB;

建立新表是为了防止后期出现多个管理员

t_application_access_policy 应用程序访问策略

create table t_application_access_policy  
(  
    application_id int unsigned not null comment '应用程序id',  
    access_policy  varchar(20)  not null comment '访问策略',  
    PRIMARY KEY (application_id, access_policy)  
)  
    COMMENT '应用程序访问策略'  
    COLLATE = 'utf8_general_ci'  
    ENGINE = InnoDB;

如果应用程序在该表中没有记录，就认定应用程序需要认证、授权。目前的访问策略有：

Authentication 认证 （登录认证）
Authorization  授权 （要有角色）

初始化所有的应用程序策略：

INSERT INTO t_application_access_policy (application_id, access_policy) VALUES (1500001, 'Authentication');

小源大厅、流程中台等应用，只需要做认证，不需要做授权，故增加此表，用以在登录时，以及分配权限时做区分。

目的：

1. 更改登录逻辑，去除具体应用程id的判断

2. 集团授权版本，我要知道他的访问策略，如果是小源大厅，他就没有 function_code

集团租户功能实现

新增集团租户

插入管理员数据：

1. 待确认，账号区分集团还是用户区分集团

2. 最终目的插入账号，获取管理员账号id

3. 插入 t_bloc_admin ，为集团指定管理员信息

生成超级管理员：

1. 因为目前角色都归属于特定的公司，故在创建集团时，将角色仍然挂载主公司上

2. 如果有新的公司加入集团，就再生成新的超级管理员角色

3. 根据functionCode获取所有的应用id

4. 生成role实体，companyId=主公司，applicationId=目标应用

5. 为超级管理员分配角色

集团的有效期与定时启用、停用

增加定时任务：

1. 此任务会在每天 00 点开始执行

2. 查询所有拥有有效期的集团信息

3. 如果当前集团位于有效期内，且状态为已停用，将启用状态置为已启用（没有启用，默认开始有效期为创建集团的日期）

4. 如果当前集团不在有效期内，且状态为已启用，将启用状态置为已停用

@如旭 已确认

手动启用与停用

增加启用停用接口：

1. 增加状态幂等，如果已经位于已启用，则不可进行启用。如果状态处于已停用，同样不可进行启用

2. 手动启用：

   1. 手动启用则认定此集团长期有效

   2. 更新启用状态为已启用，并清空有效期结束日期的字段

3. 手动禁用：

   1. 手动禁用则认定此集团长期失效

   2. 更新启用状态为已禁用，并清空有效期字段

@如旭

列表查询

根据管理员姓名、管理员手机号码查询条件，推荐改为先根据手机号码、用户名查出所有管理员，再让用户选择指定的管理员，获取id给后端查询。以防止join多张表导致的数据量过大的问题。

@如旭

授权版本功能实现

启源集团数据处理

启源集团当前应该是全量版本，无论有多少新功能加入，都可以使用全量的功能信息。故需要增加一个固定的全两的授权版本信息，且处于启用状态。

1. 全量版不可修改以及删除，系统默认

2. 预留系统默认id，数据库中，如果版本id小于100就认为是系统默认版本，就不可删除修改

3. 当发现集团的版本中包含id为1的授权版本时，需要进行特殊处理，不对功能进行限制

参见SQL

@如旭，增加全量版本，还要增加应用全量版本

覆盖的应用程序以及逻辑变动

目前授权版本覆盖的应用程序有：

系统名称	覆盖到的菜单层级	一期结束是否是集团应用
经租系统（包含销售）	一级、二级、三级菜单 （@如旭 二级不显示，只显示三级）	是
仓储系统	一级、二级	是
财会平台	一级、二级	是
档案系统	一级、二级	是
小源内容	一级、二级	是
小源大厅	无菜单、无功能权限控制	是
小源作战室	一级、二级	否
流程中台	无菜单、无功能权限控制	否

不是集团应用的应用程序，需要迁移为集团应用，让其使用集团组织架构，以及统一的角色管理。

小源大厅现状：

1. 其他应用在登录时，会判断当前账号是否拥有该系统的角色，如果拥有角色才可进行登录

2. 而小源大厅在登录时，会判断 application_id是否为小源大厅，如果是，固定主体启源，不判断角色是否存在，直接登录

流程中台：

1. 流程中台中，不存在组织架构，且登录用户也是固定启源

2. 如果要为流程中台增加登录账号，需要为启源增加新的公司管理员

3. 增加公司管理员时，会给管理员所有公司拥有的系统增加一个管理员角色

针对小源大厅与流程中台的变动：

1. 小源大厅与流程中台，目前都没有进行功能权限的控制

2. 也就是说，如果用户拥有应用程序的权限，就拥有系统中的所有权限

3. 为了在登录时，以及权限校验时，区分这种情况，故增加表 t_application_access_policy （参见SQL）

4. 根据应用程序的访问策略，决定

   1. 在登录时，对应用程序做怎样的限制（将写死的逻辑改为从数据库中读取）

   2. 在获取授权版本时，是否再需要根据功能列表进行过滤

新增授权版本时的功能查询

查询逻辑如下：

1. 查询上述应用程序的所有FunctionCode，只查询到需要的层级

2. 按照如下结构返回给前端（结构已经与@宇星确认）

3. 该信息变化较少，增加缓存，在FunctionCode表数据被修改时，清除缓存

返回结构如下：

[  
  {  
    "applicationId": 1010001,  
    "applicationName": "dpad经租系统",  
    "functions": [  
      {  
        "id": "xxx",  
        "name": "业务管理",  
        "functions": [  
          {  
            "id": "xxx",  
            "name": "A业务",  
            "functions": [  
              {  
                "id": "xxx",  
                "name": "AA业务"  
              }  
            ]  
          },  
          {  
            "id": "xxx",  
            "name": "B业务"  
          }  
        ]  
      },  
      {  
        "id": "xxx",  
        "name": "财务管理",  
        "functions": [  
          {  
            "id": "xxx",  
            "name": "A财务"  
          },  
          {  
            "id": "xxx",  
            "name": "B财务"  
          }  
        ]  
      }  
    ]  
  },  
  {  
    "applicationId": 1,  
    "applicationName": "小源大厅"  
  }  
]

授权版本新增

新增时的数据结构如下：

[  
  {  
    "applicationId": 1010001,  
    "applicationName": "dpad经租系统",  
    "checkStatus": 0, // 0 未选中 1 部分选中 2 选中
    "functions": [  
      {  
        "id": "xxx",  
        "name": "业务管理",  
        "functions": [  
          {  
            "id": "xxx",  
            "name": "A业务",  
            "functions": [  
              {  
                "id": "xxx",  
                "name": "AA业务"  
              }  
            ]  
          },  
          {  
            "id": "xxx",  
            "name": "B业务"  
          }  
        ]  
      },  
      {  
        "id": "xxx",  
        "name": "财务管理",  
        "functions": [  
          {  
            "id": "xxx",  
            "name": "A财务"  
          },  
          {  
            "id": "xxx",  
            "name": "B财务"  
          }  
        ]  
      }  
    ]  
  },  
  {  
    "applicationId": 1,  
    "applicationName": "小源大厅"  
  }  
]

未传入的数据视为未选中

授权版本入库逻辑：

1. 插入t_authorized_version表

2. 插入 t_authorized_version_application 表

   1. type 授权应用程序类型字段确定主要由 应用程序访问策略决定

   2. 如果应用程序访问策略为仅认证，则type一定为全量，无需增加任何全量版本信息

   3. 如果应用程序访问策略为认证授权，则type目前一定为应用程序指定功能

3. 插入t_authorized_version_function表

   1. 如果应用程序是指定功能，才需要添加此表记录

   2. 根据前端所给的树，遍历树

   3. 找出数的叶子节点

   4. 如果未选中，不插入表中

   5. 叶子节点已定位选中状态，插入表中 contains_child = true

授权版本编辑详情查询

组装树，并填充checkStatus给前端。

授权版本编辑

1. 对比内容，填充数据库

2. 如果发生权限撤销，则需要撤销所有应用此集团的用户的权限信息

授权版本的应用程序控制

当前用户应用程序登录限制的现状：

1. 当前登录人是否可登录应用程序，取决于，用户所属的主体是否拥有应用程序的权限 （application_company_rel）

当前做了集团版本应用程序后，公司与应用程序的控制交由集团来控制：

1. 当前登录人是否可登录应用程序，取决于，用户所属的集团的授权版本中有没有该应用权限

2. 查看登录人在企业下是否有该应用程序的角色

需要做出如下修改：

1. 登录接口增加集团的应用授权过滤

当集团原有的应用程序权限被撤销：

1. 已登录某系统的用户需要强制退出登录

   1. 删除所有集团用户下在此应用程序的token缓存

   2. token的缓存key为：token_{account_id}_{application_id}

   3. 需要先查出所有 account_id

@如旭 公司的应用程序权限控制还要吗，公司管理员还要吗 已确认

授权版本的功能控制

当前菜单、功能权限的现状：

1. 系统中的功能权限当前主要由前端控制

2. 前端会从接口登录权限列表（/role/getFunctionCodeList）中获取所有的功能代码

3. 如果功能代码不包含当前按钮，那按钮/菜单就会被隐藏

当集团原有的功能权限被撤销时，登录人不可以继续使用该功能：

1. 由于功能控制在前端，撤销后，有可能仍然存在页面停留的访问，故在撤销功能权限后，让所有用户退出登录

2. 撤销方式则是查询所有集团企业角色中含有该功能的记录，将他们都删除

旧功能改造

账号问题确定

小源作战室迁移为集团应用

流程中台迁移为集团应用

公司查询问题

集团组织架构如何正常编辑？

新增：

1. 由新增主体的组织架构改为新增分组的组织架构

2. 同步分组组织架构到其他该分组下的主体

修改：

1. 由修改主体的组织架构改为修改分组的组织架构

2. 同步分组组织架构到其他该分组下的主体

删除：

1. 由删除主体的组织架构改为删除分组的组织架构

2. 同步分组组织架构到其他该分组下的主体

3. 删除还需要将人员全部移动到根层级下

以上操作仅同步组织层级，不同步组织人员。