数据库设计
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');
小源大厅、流程中台等应用，只需要做认证，不需要做授权，故增加此表，用以在登录时，以及分配权限时做区分。
目的：
集团授权版本，我要知道他的访问策略，如果是小源大厅，他就没有 function_code
集团租户功能实现
新增集团租户
插入管理员数据：
插入 t_bloc_admin ，为集团指定管理员信息
生成超级管理员：
因为目前角色都归属于特定的公司，故在创建集团时，将角色仍然挂载主公司上
如果有新的公司加入集团，就再生成新的超级管理员角色
生成role实体，companyId=主公司，applicationId=目标应用
集团的有效期与定时启用、停用
增加定时任务：
如果当前集团位于有效期内，且状态为已停用，将启用状态置为已启用（没有启用，默认开始有效期为创建集团的日期）
如果当前集团不在有效期内，且状态为已启用，将启用状态置为已停用
@如旭 已确认
手动启用与停用
增加启用停用接口：
增加状态幂等，如果已经位于已启用，则不可进行启用。如果状态处于已停用，同样不可进行启用
@如旭
列表查询
根据管理员姓名、管理员手机号码查询条件，推荐改为先根据手机号码、用户名查出所有管理员，再让用户选择指定的管理员，获取id给后端查询。以防止join多张表导致的数据量过大的问题。
@如旭
授权版本功能实现
启源集团数据处理
启源集团当前应该是全量版本，无论有多少新功能加入，都可以使用全量的功能信息。故需要增加一个固定的全两的授权版本信息，且处于启用状态。
预留系统默认id，数据库中，如果版本id小于100就认为是系统默认版本，就不可删除修改
当发现集团的版本中包含id为1的授权版本时，需要进行特殊处理，不对功能进行限制
参见SQL
@如旭，增加全量版本，还要增加应用全量版本
覆盖的应用程序以及逻辑变动
目前授权版本覆盖的应用程序有：
| 系统名称 | 覆盖到的菜单层级 | 一期结束是否是集团应用 |
|---|
| 一级、二级、三级菜单 （@如旭 二级不显示，只显示三级） | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
不是集团应用的应用程序，需要迁移为集团应用，让其使用集团组织架构，以及统一的角色管理。
小源大厅现状：
其他应用在登录时，会判断当前账号是否拥有该系统的角色，如果拥有角色才可进行登录
而小源大厅在登录时，会判断 application_id是否为小源大厅，如果是，固定主体启源，不判断角色是否存在，直接登录
流程中台：
流程中台中，不存在组织架构，且登录用户也是固定启源
如果要为流程中台增加登录账号，需要为启源增加新的公司管理员
增加公司管理员时，会给管理员所有公司拥有的系统增加一个管理员角色
针对小源大厅与流程中台的变动：
也就是说，如果用户拥有应用程序的权限，就拥有系统中的所有权限
为了在登录时，以及权限校验时，区分这种情况，故增加表 t_application_access_policy （参见SQL）
根据应用程序的访问策略，决定
在登录时，对应用程序做怎样的限制（将写死的逻辑改为从数据库中读取）
新增授权版本时的功能查询
查询逻辑如下：
查询上述应用程序的所有FunctionCode，只查询到需要的层级
该信息变化较少，增加缓存，在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": "小源大厅"
}
]
未传入的数据视为未选中
授权版本入库逻辑：
插入 t_authorized_version_application 表
type 授权应用程序类型字段确定主要由 应用程序访问策略决定
如果应用程序访问策略为仅认证，则type一定为全量，无需增加任何全量版本信息
如果应用程序访问策略为认证授权，则type目前一定为应用程序指定功能
插入t_authorized_version_function表
叶子节点已定位选中状态，插入表中 contains_child = true
授权版本编辑详情查询
组装树，并填充checkStatus给前端。
授权版本编辑
如果发生权限撤销，则需要撤销所有应用此集团的用户的权限信息
授权版本的应用程序控制
当前用户应用程序登录限制的现状：
当前登录人是否可登录应用程序，取决于，用户所属的主体是否拥有应用程序的权限 （application_company_rel）
当前做了集团版本应用程序后，公司与应用程序的控制交由集团来控制：
当前登录人是否可登录应用程序，取决于，用户所属的集团的授权版本中有没有该应用权限
需要做出如下修改：
当集团原有的应用程序权限被撤销：
已登录某系统的用户需要强制退出登录
token的缓存key为：token_{account_id}_{application_id}
@如旭 公司的应用程序权限控制还要吗，公司管理员还要吗 已确认
授权版本的功能控制
当前菜单、功能权限的现状：
前端会从接口登录权限列表（/role/getFunctionCodeList）中获取所有的功能代码
如果功能代码不包含当前按钮，那按钮/菜单就会被隐藏
当集团原有的功能权限被撤销时，登录人不可以继续使用该功能：
由于功能控制在前端，撤销后，有可能仍然存在页面停留的访问，故在撤销功能权限后，让所有用户退出登录
撤销方式则是查询所有集团企业角色中含有该功能的记录，将他们都删除
旧功能改造
账号问题确定
小源作战室迁移为集团应用
流程中台迁移为集团应用
公司查询问题
集团组织架构如何正常编辑？
新增：
修改：
删除：
以上操作仅同步组织层级，不同步组织人员。
