first commit
This commit is contained in:
50
40-平台与架构/基础平台/功能模块/01-客户管理.md
Normal file
50
40-平台与架构/基础平台/功能模块/01-客户管理.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# 5.1 客户管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.1.1 功能说明
|
||||
|
||||
客户管理用于维护使用公司产品的客户主体,是多客户隔离和业务系统开通的基础。
|
||||
|
||||
## 5.1.2 功能范围
|
||||
|
||||
- 新增客户
|
||||
- 编辑客户信息
|
||||
- 启用 / 停用客户
|
||||
- 查询客户列表
|
||||
- 查看客户详情
|
||||
- 为客户开通应用
|
||||
- 维护客户管理员
|
||||
|
||||
## 5.1.3 字段要求
|
||||
|
||||
客户基础信息至少包括:
|
||||
|
||||
- 客户名称
|
||||
- 客户简称
|
||||
- 客户编码
|
||||
- 客户类型
|
||||
- 所属行业
|
||||
- 联系人
|
||||
- 联系方式
|
||||
- 启用状态
|
||||
- 开通应用
|
||||
- 创建时间
|
||||
|
||||
## 5.1.4 业务规则
|
||||
|
||||
- 客户编码全局唯一。
|
||||
- 停用客户后,该客户下用户不可登录业务系统。
|
||||
- 客户停用不删除历史数据。
|
||||
- 客户未开通某应用时,该客户下用户不可看到该应用入口。
|
||||
- 一个客户至少应有一个客户管理员。
|
||||
|
||||
## 5.1.5 验收标准
|
||||
|
||||
- 可创建、编辑、停用客户。
|
||||
- 可为客户开通和关闭应用。
|
||||
- 停用客户后,该客户下账号无法继续访问系统。
|
||||
- 客户之间数据不可互相查看。
|
||||
43
40-平台与架构/基础平台/功能模块/02-应用管理.md
Normal file
43
40-平台与架构/基础平台/功能模块/02-应用管理.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# 5.2 应用管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.2.1 功能说明
|
||||
|
||||
应用管理用于维护接入基础平台的业务系统。
|
||||
|
||||
## 5.2.2 功能范围
|
||||
|
||||
- 新增应用
|
||||
- 编辑应用信息
|
||||
- 启用 / 停用应用
|
||||
- 配置应用入口
|
||||
- 配置应用菜单
|
||||
- 配置应用权限项
|
||||
- 配置应用可授权范围
|
||||
|
||||
## 5.2.3 应用清单
|
||||
|
||||
1.0 需要支持以下应用接入:
|
||||
|
||||
- 连锁业务对账系统
|
||||
- 分账系统
|
||||
- 聚合支付
|
||||
- 门店选址规划系统
|
||||
- 连锁门店客服系统
|
||||
|
||||
## 5.2.4 业务规则
|
||||
|
||||
- 应用编码全局唯一。
|
||||
- 应用停用后,所有客户不可访问该应用。
|
||||
- 客户未开通应用时,不显示该应用入口。
|
||||
- 应用菜单和权限项由产品管理员维护。
|
||||
|
||||
## 5.2.5 验收标准
|
||||
|
||||
- 可维护应用基础信息。
|
||||
- 可控制客户是否开通某应用。
|
||||
- 应用停用后入口不可访问。
|
||||
50
40-平台与架构/基础平台/功能模块/03-组织管理.md
Normal file
50
40-平台与架构/基础平台/功能模块/03-组织管理.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# 5.3 组织管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.3.1 功能说明
|
||||
|
||||
组织管理用于维护客户内部组织结构,支撑总部、部门、品牌、区域、门店等组织层级。
|
||||
|
||||
## 5.3.2 功能范围
|
||||
|
||||
- 新增组织
|
||||
- 编辑组织
|
||||
- 启用 / 停用组织
|
||||
- 查询组织树
|
||||
- 调整上级组织
|
||||
- 维护组织负责人
|
||||
- 维护组织类型
|
||||
|
||||
## 5.3.3 组织类型
|
||||
|
||||
基础平台 1.0 支持以下组织类型:
|
||||
|
||||
- 公司
|
||||
- 部门
|
||||
- 品牌
|
||||
- 大区
|
||||
- 区域
|
||||
- 门店
|
||||
- 项目组织
|
||||
- 平台商户
|
||||
- 其他
|
||||
|
||||
## 5.3.4 业务规则
|
||||
|
||||
- 组织必须归属于某个客户。
|
||||
- 组织编码在同一客户下唯一。
|
||||
- 组织支持多级结构。
|
||||
- 停用组织后,该组织不可继续分配给新用户。
|
||||
- 停用组织不影响历史数据归属。
|
||||
- 门店可以作为一种组织类型,但门店业务属性由业务系统维护。
|
||||
|
||||
## 5.3.5 验收标准
|
||||
|
||||
- 可维护多级组织树。
|
||||
- 可按客户隔离组织数据。
|
||||
- 停用组织后不可继续用于新授权。
|
||||
- 用户数据权限可按组织范围生效。
|
||||
54
40-平台与架构/基础平台/功能模块/04-用户与账号管理.md
Normal file
54
40-平台与架构/基础平台/功能模块/04-用户与账号管理.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# 5.4 用户与账号管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.4.1 功能说明
|
||||
|
||||
用户与账号管理用于维护系统使用人员及登录账号。
|
||||
|
||||
## 5.4.2 功能范围
|
||||
|
||||
- 新增用户
|
||||
- 编辑用户
|
||||
- 启用 / 停用用户
|
||||
- 创建账号
|
||||
- 重置密码
|
||||
- 设置用户所属组织
|
||||
- 设置默认组织
|
||||
- 分配角色
|
||||
- 查询用户列表
|
||||
- 查看用户详情
|
||||
|
||||
## 5.4.3 字段要求
|
||||
|
||||
用户信息至少包括:
|
||||
|
||||
- 姓名
|
||||
- 手机号
|
||||
- 登录账号
|
||||
- 所属客户
|
||||
- 所属组织
|
||||
- 默认组织
|
||||
- 角色
|
||||
- 状态
|
||||
- 创建时间
|
||||
|
||||
## 5.4.4 业务规则
|
||||
|
||||
- 用户必须归属于一个客户。
|
||||
- 登录账号在平台内唯一。
|
||||
- 手机号是否唯一按客户维度控制,1.0 默认同一客户下唯一。
|
||||
- 一个用户可属于多个组织。
|
||||
- 一个用户必须有一个默认组织。
|
||||
- 停用用户后不可登录。
|
||||
- 用户离职或停用不删除历史操作日志。
|
||||
|
||||
## 5.4.5 验收标准
|
||||
|
||||
- 可创建用户并分配组织和角色。
|
||||
- 用户登录后只能看到授权应用和菜单。
|
||||
- 停用用户后不能登录。
|
||||
- 用户切换组织时,数据范围应随组织变化。
|
||||
72
40-平台与架构/基础平台/功能模块/05-单点登录与统一认证鉴权.md
Normal file
72
40-平台与架构/基础平台/功能模块/05-单点登录与统一认证鉴权.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# 5.5 单点登录与统一认证鉴权
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.5.1 功能说明
|
||||
|
||||
单点登录与统一认证鉴权用于支撑用户一次登录后访问多个已授权业务应用,并统一完成所有应用的 Token 认证和鉴权。
|
||||
|
||||
基础平台作为统一认证中心,所有接入应用不再各自独立维护登录认证逻辑。业务应用需要根据基础平台返回的认证结果和权限结果,控制用户访问。
|
||||
|
||||
详细流程、Token 交互规则和验收口径见:[单点登录与统一认证鉴权设计](../单点登录与统一认证鉴权设计.md)。
|
||||
|
||||
## 5.5.2 功能范围
|
||||
|
||||
- 用户统一登录
|
||||
- 用户统一退出
|
||||
- 登录状态维护
|
||||
- Token 签发
|
||||
- Token 校验
|
||||
- Token 刷新
|
||||
- Token 失效
|
||||
- 应用访问鉴权
|
||||
- 用户身份信息获取
|
||||
- 当前登录用户信息获取
|
||||
- 用户授权应用列表获取
|
||||
- 用户菜单和权限获取
|
||||
|
||||
## 5.5.3 业务规则
|
||||
|
||||
- 用户登录由基础平台统一完成。
|
||||
- 用户登录成功后,可访问已开通且已授权的业务应用。
|
||||
- 用户未登录时,不可访问任何业务应用。
|
||||
- 用户访问业务应用时,业务应用必须通过基础平台完成 Token 认证鉴权。
|
||||
- Token 无效、过期、被注销或用户已停用时,业务应用必须拒绝访问。
|
||||
- 用户退出登录后,已登录应用应同步失效或在下一次认证时失效。
|
||||
- 客户停用、用户停用、应用停用、客户未开通应用、用户未授权应用时,认证鉴权均不通过。
|
||||
- 用户权限变更后,应能在合理时间内影响用户后续访问。
|
||||
- 业务应用不得绕过基础平台独立放行用户访问。
|
||||
|
||||
## 5.5.4 鉴权判断维度
|
||||
|
||||
基础平台认证鉴权至少需要判断:
|
||||
|
||||
- Token 是否有效。
|
||||
- 用户是否存在且启用。
|
||||
- 用户所属客户是否启用。
|
||||
- 应用是否存在且启用。
|
||||
- 客户是否已开通该应用。
|
||||
- 用户是否拥有该应用访问权限。
|
||||
- 用户是否拥有对应菜单、操作或数据范围权限。
|
||||
|
||||
## 5.5.5 业务系统接入要求
|
||||
|
||||
所有接入基础平台的业务系统均需满足:
|
||||
|
||||
- 登录入口统一接入基础平台。
|
||||
- 用户身份校验统一通过基础平台。
|
||||
- Token 认证鉴权统一通过基础平台。
|
||||
- 菜单、权限、数据范围以基础平台授权结果为准。
|
||||
- 业务系统可保留自身业务权限补充规则,但不得与基础平台授权结果冲突。
|
||||
|
||||
## 5.5.6 验收标准
|
||||
|
||||
- 用户一次登录后,可访问多个已授权应用。
|
||||
- 未授权应用不可访问。
|
||||
- Token 无效或过期时,业务应用拒绝访问。
|
||||
- 用户停用、客户停用、应用停用后,业务应用拒绝访问。
|
||||
- 用户退出后,再访问业务应用需要重新登录。
|
||||
- 各业务应用均通过基础平台完成 Token 认证鉴权。
|
||||
36
40-平台与架构/基础平台/功能模块/06-统一门户与应用容器.md
Normal file
36
40-平台与架构/基础平台/功能模块/06-统一门户与应用容器.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# 5.6 统一门户与应用容器
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.6.1 功能说明
|
||||
|
||||
统一门户与应用容器用于承载基础平台页面和各业务应用页面。基础平台负责所有业务系统的菜单聚合、业务链接入口、页面框架、Tab 管理、iframe 嵌入和 Token 有效期管理。
|
||||
|
||||
业务应用不再独立渲染系统级菜单。业务应用只负责提供自身业务页面,由基础平台通过 iframe 嵌入到右侧内容区。
|
||||
|
||||
详细页面结构、容器规则、keepalive 规则和验收口径见:[统一门户与应用容器设计](../统一门户与应用容器设计.md)。
|
||||
|
||||
## 5.6.2 页面总体布局
|
||||
|
||||
基础平台主页面由三部分组成:
|
||||
|
||||
- 头部区域
|
||||
- 左侧菜单导航栏
|
||||
- 右侧内容区
|
||||
|
||||
右侧内容区用于展示基础平台自身页面和各业务应用 iframe 页面。
|
||||
|
||||
## 5.6.3 验收标准
|
||||
|
||||
- 基础平台可聚合展示用户有权限访问的所有应用菜单。
|
||||
- 业务应用不再独立展示系统级菜单。
|
||||
- 点击业务应用菜单后,可在右侧内容区通过 iframe 打开应用页面。
|
||||
- 打开的页面可生成 Tab。
|
||||
- Tab 切换时页面状态可保持。
|
||||
- 关闭 Tab 后页面状态释放。
|
||||
- iframe 应用可使用基础平台 Token 访问业务接口。
|
||||
- Token 刷新后,已打开 iframe 应用可继续访问。
|
||||
- 用户注销后,已打开 iframe 应用不可继续访问。
|
||||
45
40-平台与架构/基础平台/功能模块/07-角色管理.md
Normal file
45
40-平台与架构/基础平台/功能模块/07-角色管理.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# 5.7 角色管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.7.1 功能说明
|
||||
|
||||
角色管理用于将权限项组合成可分配给用户的权限集合。
|
||||
|
||||
## 5.7.2 功能范围
|
||||
|
||||
- 新增角色
|
||||
- 编辑角色
|
||||
- 复制角色
|
||||
- 启用 / 停用角色
|
||||
- 为角色配置权限
|
||||
- 为角色配置数据范围
|
||||
- 查询角色列表
|
||||
|
||||
## 5.7.3 角色类型
|
||||
|
||||
基础平台 1.0 支持:
|
||||
|
||||
- 平台角色
|
||||
- 客户角色
|
||||
- 应用角色
|
||||
|
||||
## 5.7.4 业务规则
|
||||
|
||||
- 平台角色由平台超级管理员维护。
|
||||
- 客户角色由客户管理员维护。
|
||||
- 应用角色可作为系统预置角色。
|
||||
- 角色停用后不可再分配给新用户。
|
||||
- 停用角色不影响历史操作日志。
|
||||
- 用户拥有多个角色时,功能权限取并集。
|
||||
- 数据权限按角色配置规则合并,具体合并规则需在角色配置中明确展示。
|
||||
|
||||
## 5.7.5 验收标准
|
||||
|
||||
- 可创建角色并配置功能权限。
|
||||
- 用户分配角色后权限立即生效。
|
||||
- 角色停用后不可继续分配。
|
||||
- 多角色用户权限计算正确。
|
||||
57
40-平台与架构/基础平台/功能模块/08-权限管理.md
Normal file
57
40-平台与架构/基础平台/功能模块/08-权限管理.md
Normal file
@@ -0,0 +1,57 @@
|
||||
# 5.8 权限管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.8.1 功能说明
|
||||
|
||||
权限管理用于控制用户可访问的应用、菜单、页面和操作。
|
||||
|
||||
## 5.8.2 权限分类
|
||||
|
||||
基础平台 1.0 支持:
|
||||
|
||||
- 应用权限
|
||||
- 菜单权限
|
||||
- 操作权限
|
||||
- 数据范围权限
|
||||
|
||||
## 5.8.3 操作权限
|
||||
|
||||
基础操作权限包括:
|
||||
|
||||
- 查看
|
||||
- 新增
|
||||
- 编辑
|
||||
- 删除
|
||||
- 审核
|
||||
- 导入
|
||||
- 导出
|
||||
- 启用 / 停用
|
||||
|
||||
## 5.8.4 数据范围
|
||||
|
||||
基础数据范围包括:
|
||||
|
||||
- 全部数据
|
||||
- 本组织及下级组织
|
||||
- 本组织
|
||||
- 指定组织
|
||||
- 本人数据
|
||||
|
||||
## 5.8.5 业务规则
|
||||
|
||||
- 用户未授权应用时不可看到应用入口。
|
||||
- 用户未授权菜单时不可看到菜单。
|
||||
- 用户未授权操作时不可执行对应操作。
|
||||
- 数据权限必须按客户隔离。
|
||||
- 不允许用户通过 URL 或其他入口访问未授权功能。
|
||||
|
||||
## 5.8.6 验收标准
|
||||
|
||||
- 菜单显示与用户权限一致。
|
||||
- 操作按钮显示与用户权限一致。
|
||||
- 未授权用户无法访问对应接口或页面。
|
||||
- 数据范围控制正确。
|
||||
32
40-平台与架构/基础平台/功能模块/09-菜单管理.md
Normal file
32
40-平台与架构/基础平台/功能模块/09-菜单管理.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 5.9 菜单管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.9.1 功能说明
|
||||
|
||||
菜单管理用于维护应用在系统中的导航结构。
|
||||
|
||||
## 5.9.2 功能范围
|
||||
|
||||
- 新增菜单
|
||||
- 编辑菜单
|
||||
- 排序菜单
|
||||
- 启用 / 停用菜单
|
||||
- 绑定权限项
|
||||
- 配置菜单所属应用
|
||||
|
||||
## 5.9.3 业务规则
|
||||
|
||||
- 菜单必须归属于某个应用。
|
||||
- 菜单可多级展示。
|
||||
- 停用菜单后用户不可见。
|
||||
- 菜单是否可见由应用开通状态、用户角色、菜单权限共同决定。
|
||||
|
||||
## 5.9.4 验收标准
|
||||
|
||||
- 菜单可按应用维护。
|
||||
- 菜单可根据权限显示或隐藏。
|
||||
- 菜单排序生效。
|
||||
40
40-平台与架构/基础平台/功能模块/10-基础配置管理.md
Normal file
40
40-平台与架构/基础平台/功能模块/10-基础配置管理.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# 5.10 基础配置管理
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.10.1 功能说明
|
||||
|
||||
基础配置管理用于维护客户级、应用级基础参数。
|
||||
|
||||
## 5.10.2 功能范围
|
||||
|
||||
- 配置项管理
|
||||
- 配置值维护
|
||||
- 启用 / 停用配置
|
||||
- 按客户配置
|
||||
- 按应用配置
|
||||
|
||||
## 5.10.3 配置分类
|
||||
|
||||
1.0 支持:
|
||||
|
||||
- 平台配置
|
||||
- 客户配置
|
||||
- 应用配置
|
||||
- 业务开关
|
||||
|
||||
## 5.10.4 业务规则
|
||||
|
||||
- 平台配置仅平台管理员维护。
|
||||
- 客户配置仅影响当前客户。
|
||||
- 应用配置仅影响对应应用。
|
||||
- 配置变更需要记录操作日志。
|
||||
|
||||
## 5.10.5 验收标准
|
||||
|
||||
- 可维护客户级配置。
|
||||
- 可维护应用级配置。
|
||||
- 配置变更后业务系统可读取到正确配置。
|
||||
31
40-平台与架构/基础平台/功能模块/11-消息与待办.md
Normal file
31
40-平台与架构/基础平台/功能模块/11-消息与待办.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# 5.11 消息与待办
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.11.1 功能说明
|
||||
|
||||
消息与待办用于为业务系统提供基础通知能力。
|
||||
|
||||
## 5.11.2 功能范围
|
||||
|
||||
- 系统消息
|
||||
- 待办消息
|
||||
- 消息已读 / 未读
|
||||
- 消息查询
|
||||
- 消息跳转业务系统
|
||||
|
||||
## 5.11.3 业务规则
|
||||
|
||||
- 消息必须归属于客户和用户。
|
||||
- 用户只能查看自己的消息。
|
||||
- 待办可关联业务系统和业务单据。
|
||||
- 业务单据处理完成后,待办状态应支持更新。
|
||||
|
||||
## 5.11.4 验收标准
|
||||
|
||||
- 用户可查看自己的消息和待办。
|
||||
- 已读 / 未读状态正确。
|
||||
- 待办可跳转到对应业务系统。
|
||||
50
40-平台与架构/基础平台/功能模块/12-操作日志.md
Normal file
50
40-平台与架构/基础平台/功能模块/12-操作日志.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# 5.12 操作日志
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.12.1 功能说明
|
||||
|
||||
操作日志用于记录用户关键操作,支持审计和问题排查。
|
||||
|
||||
## 5.12.2 日志范围
|
||||
|
||||
1.0 至少记录:
|
||||
|
||||
- 登录
|
||||
- 新增
|
||||
- 编辑
|
||||
- 删除
|
||||
- 启用 / 停用
|
||||
- 授权变更
|
||||
- 配置变更
|
||||
- 导入
|
||||
- 导出
|
||||
|
||||
## 5.12.3 日志字段
|
||||
|
||||
日志至少包括:
|
||||
|
||||
- 操作时间
|
||||
- 操作用户
|
||||
- 所属客户
|
||||
- 所属组织
|
||||
- 操作应用
|
||||
- 操作模块
|
||||
- 操作类型
|
||||
- 操作对象
|
||||
- 操作结果
|
||||
|
||||
## 5.12.4 业务规则
|
||||
|
||||
- 操作日志不可由普通用户修改或删除。
|
||||
- 日志查询需按权限控制。
|
||||
- 不同客户日志隔离。
|
||||
|
||||
## 5.12.5 验收标准
|
||||
|
||||
- 关键操作可生成日志。
|
||||
- 日志内容可查询。
|
||||
- 客户之间日志隔离。
|
||||
29
40-平台与架构/基础平台/功能模块/13-数据字典.md
Normal file
29
40-平台与架构/基础平台/功能模块/13-数据字典.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# 5.13 数据字典
|
||||
|
||||
本文档从《基础平台产品设计》第 5 章拆分而来,用于独立描述基础平台功能模块的业务需求、规则和验收标准。
|
||||
|
||||
上级文档:[基础平台产品设计](../基础平台产品设计.md)
|
||||
|
||||
|
||||
## 5.13.1 功能说明
|
||||
|
||||
数据字典用于维护基础枚举类数据,供各业务系统复用。
|
||||
|
||||
## 5.13.2 功能范围
|
||||
|
||||
- 字典分类
|
||||
- 字典项
|
||||
- 启用 / 停用字典项
|
||||
- 字典项排序
|
||||
|
||||
## 5.13.3 业务规则
|
||||
|
||||
- 字典编码唯一。
|
||||
- 停用字典项后,不影响历史数据展示。
|
||||
- 字典变更需记录日志。
|
||||
|
||||
## 5.13.4 验收标准
|
||||
|
||||
- 可维护字典分类和字典项。
|
||||
- 业务系统可使用启用状态的字典项。
|
||||
- 停用字典项不影响历史数据。
|
||||
19
40-平台与架构/基础平台/功能模块/README.md
Normal file
19
40-平台与架构/基础平台/功能模块/README.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# 基础平台功能模块
|
||||
|
||||
本目录用于承接《基础平台产品设计》第 5 章的功能模块详细设计。每个功能模块独立成文档,便于研发拆分任务、测试编写用例、产品进行范围控制。
|
||||
|
||||
| 编号 | 功能模块 | 文档 |
|
||||
| --- | --- | --- |
|
||||
| 5.1 | 客户管理 | [01-客户管理.md](./01-客户管理.md) |
|
||||
| 5.2 | 应用管理 | [02-应用管理.md](./02-应用管理.md) |
|
||||
| 5.3 | 组织管理 | [03-组织管理.md](./03-组织管理.md) |
|
||||
| 5.4 | 用户与账号管理 | [04-用户与账号管理.md](./04-用户与账号管理.md) |
|
||||
| 5.5 | 单点登录与统一认证鉴权 | [05-单点登录与统一认证鉴权.md](./05-单点登录与统一认证鉴权.md) |
|
||||
| 5.6 | 统一门户与应用容器 | [06-统一门户与应用容器.md](./06-统一门户与应用容器.md) |
|
||||
| 5.7 | 角色管理 | [07-角色管理.md](./07-角色管理.md) |
|
||||
| 5.8 | 权限管理 | [08-权限管理.md](./08-权限管理.md) |
|
||||
| 5.9 | 菜单管理 | [09-菜单管理.md](./09-菜单管理.md) |
|
||||
| 5.10 | 基础配置管理 | [10-基础配置管理.md](./10-基础配置管理.md) |
|
||||
| 5.11 | 消息与待办 | [11-消息与待办.md](./11-消息与待办.md) |
|
||||
| 5.12 | 操作日志 | [12-操作日志.md](./12-操作日志.md) |
|
||||
| 5.13 | 数据字典 | [13-数据字典.md](./13-数据字典.md) |
|
||||
239
40-平台与架构/基础平台/单点登录与统一认证鉴权设计.md
Normal file
239
40-平台与架构/基础平台/单点登录与统一认证鉴权设计.md
Normal file
@@ -0,0 +1,239 @@
|
||||
# 单点登录与统一认证鉴权设计
|
||||
|
||||
## 1. 文档说明
|
||||
|
||||
本文档是《基础平台产品设计》的专题补充文档,用于定义基础平台单点登录、统一 Token 认证鉴权、Token 刷新、登录注销、当前登录用户信息获取和 Token 状态同步规则。
|
||||
|
||||
本文档阅读对象为研发部门、测试部门、产品部门和实施交付团队。
|
||||
|
||||
## 2. 产品定位
|
||||
|
||||
单点登录与统一认证鉴权用于支撑用户一次登录基础平台后,访问多个已授权业务应用,并统一完成所有应用的 Token 认证和鉴权。
|
||||
|
||||
基础平台作为统一认证中心。所有接入应用不再各自独立维护登录认证逻辑,业务应用需要根据基础平台返回的认证结果和权限结果控制用户访问。
|
||||
|
||||
## 3. 功能范围
|
||||
|
||||
- 用户统一登录
|
||||
- 用户统一退出
|
||||
- 登录状态维护
|
||||
- Token 签发
|
||||
- Token 校验
|
||||
- Token 刷新
|
||||
- Token 失效
|
||||
- 应用访问鉴权
|
||||
- 用户身份信息获取
|
||||
- 当前登录用户信息获取
|
||||
- 用户授权应用列表获取
|
||||
- 用户菜单和权限获取
|
||||
|
||||
## 4. 业务规则
|
||||
|
||||
- 用户登录由基础平台统一完成。
|
||||
- 用户登录成功后,可访问已开通且已授权的业务应用。
|
||||
- 用户未登录时,不可访问任何业务应用。
|
||||
- 用户访问业务应用时,业务应用必须通过基础平台完成 Token 认证鉴权。
|
||||
- Token 无效、过期、被注销或用户已停用时,业务应用必须拒绝访问。
|
||||
- 用户退出登录后,已登录应用应同步失效或在下一次认证时失效。
|
||||
- 客户停用、用户停用、应用停用、客户未开通应用、用户未授权应用时,认证鉴权均不通过。
|
||||
- 用户权限变更后,应能在合理时间内影响用户后续访问。
|
||||
- 业务应用不得绕过基础平台独立放行用户访问。
|
||||
|
||||
## 5. 鉴权判断维度
|
||||
|
||||
基础平台认证鉴权至少需要判断:
|
||||
|
||||
- Token 是否有效。
|
||||
- 用户是否存在且启用。
|
||||
- 用户所属客户是否启用。
|
||||
- 应用是否存在且启用。
|
||||
- 客户是否已开通该应用。
|
||||
- 用户是否拥有该应用访问权限。
|
||||
- 用户是否拥有对应菜单、操作或数据范围权限。
|
||||
|
||||
## 6. 业务系统接入要求
|
||||
|
||||
所有接入基础平台的业务系统均需满足:
|
||||
|
||||
- 登录入口统一接入基础平台。
|
||||
- 用户身份校验统一通过基础平台。
|
||||
- Token 认证鉴权统一通过基础平台。
|
||||
- 菜单、权限、数据范围以基础平台授权结果为准。
|
||||
- 业务系统可保留自身业务权限补充规则,但不得与基础平台授权结果冲突。
|
||||
|
||||
## 7. 统一登录流程
|
||||
|
||||
统一登录流程用于解决用户登录入口、Token 源头、门户登录态统一问题。用户只登录基础平台门户,不直接登录各业务应用。
|
||||
|
||||
流程步骤:
|
||||
|
||||
1. 用户访问基础平台登录页。
|
||||
2. 用户提交登录账号和登录凭证。
|
||||
3. 基础平台校验用户账号、密码或其他登录凭证。
|
||||
4. 基础平台校验用户状态、客户状态、默认组织状态。
|
||||
5. 校验通过后,基础平台生成门户登录会话并签发 Token。
|
||||
6. 基础平台加载当前用户基础信息、默认组织、可访问应用列表、菜单和权限。
|
||||
7. 用户进入基础平台统一门户主页面。
|
||||
8. 基础平台根据用户权限渲染头部、左侧菜单、Tab 导航栏和右侧内容区。
|
||||
9. 用户点击业务应用菜单时,基础平台在右侧内容区通过 iframe 打开业务应用页面。
|
||||
10. 基础平台将 Token 访问状态同步给 iframe 应用。
|
||||
11. iframe 应用使用基础平台 Token 访问自身业务接口。
|
||||
|
||||
流程规则:
|
||||
|
||||
- 用户登录必须由基础平台统一完成。
|
||||
- 业务应用不得独立生成登录 Token。
|
||||
- Token 的签发源头只能是基础平台。
|
||||
- 登录成功后,业务应用只能在基础平台门户容器中使用基础平台签发的 Token 进行访问。
|
||||
- 用户无任何授权应用时,登录成功后应提示暂无可访问应用。
|
||||
- 业务应用不再提供独立登录页作为常规访问入口。
|
||||
|
||||
## 8. iframe 应用 Token 交互流程
|
||||
|
||||
iframe 应用 Token 交互流程用于解决业务应用嵌入基础平台后,如何获取和使用基础平台统一 Token。
|
||||
|
||||
流程步骤:
|
||||
|
||||
1. 用户在基础平台左侧菜单点击某业务应用菜单。
|
||||
2. 基础平台校验用户是否拥有该应用和菜单访问权限。
|
||||
3. 校验通过后,基础平台在右侧内容区创建或激活对应 iframe 页面。
|
||||
4. 基础平台向 iframe 应用同步当前 Token 或可用于获取 Token 的访问状态。
|
||||
5. iframe 应用接收基础平台 Token 后,向基础平台进行 Token 校验或获取当前登录用户信息。
|
||||
6. 基础平台返回 Token 有效性、当前用户信息、当前应用权限和数据范围。
|
||||
7. iframe 应用根据基础平台返回结果加载业务页面。
|
||||
8. iframe 应用访问自身业务接口时,使用基础平台 Token 作为统一认证凭证。
|
||||
|
||||
流程规则:
|
||||
|
||||
- 业务应用只接受基础平台签发的 Token。
|
||||
- 业务应用不得自行伪造、转换或替代基础平台 Token。
|
||||
- iframe 应用不得要求用户再次登录。
|
||||
- iframe 应用不得独立维护与基础平台冲突的登录态。
|
||||
- iframe 应用每次关键访问均应确认 Token 有效性。
|
||||
- 多个 iframe 应用之间不直接互相传递用户身份,以基础平台门户容器和 Token 为统一身份依据。
|
||||
- 用户未通过基础平台打开业务应用时,业务应用应拒绝访问或引导到基础平台。
|
||||
|
||||
## 9. Token 刷新流程
|
||||
|
||||
Token 刷新流程用于解决基础平台门户中多个已打开 iframe 应用的登录状态延续和 Token 过期处理问题。
|
||||
|
||||
流程步骤:
|
||||
|
||||
1. 用户已登录基础平台门户,并打开一个或多个 iframe 应用。
|
||||
2. 基础平台监控当前 Token 有效期。
|
||||
3. Token 即将过期时,基础平台发起 Token 刷新。
|
||||
4. 基础平台校验原登录会话、用户状态、客户状态和应用授权状态。
|
||||
5. 校验通过后,基础平台签发新的 Token。
|
||||
6. 基础平台更新门户容器中的当前 Token。
|
||||
7. 基础平台向已打开 iframe 应用同步 Token 刷新结果。
|
||||
8. iframe 应用使用新 Token 继续访问业务接口。
|
||||
9. 旧 Token 按规则失效或在有效期结束后失效。
|
||||
|
||||
流程规则:
|
||||
|
||||
- Token 刷新必须由基础平台完成。
|
||||
- 用户停用、客户停用、应用停用、用户无应用权限时,不允许刷新 Token。
|
||||
- Token 刷新后,基础平台负责向已打开 iframe 应用同步新 Token 状态。
|
||||
- iframe 应用收到 Token 刷新成功结果后,应使用新 Token 访问。
|
||||
- Token 刷新失败时,基础平台应统一引导用户重新登录,并使已打开 iframe 应用访问失效。
|
||||
- iframe 应用不主动刷新 Token,只响应基础平台刷新结果。
|
||||
|
||||
## 10. 登录注销流程
|
||||
|
||||
登录注销流程用于解决用户退出基础平台后,所有已打开 iframe 应用访问状态一致失效问题。
|
||||
|
||||
流程步骤:
|
||||
|
||||
1. 用户在基础平台头部用户信息区域点击退出登录。
|
||||
2. 基础平台确认注销操作。
|
||||
3. 基础平台失效当前用户门户登录会话和相关 Token。
|
||||
4. 基础平台向所有已打开 iframe 应用同步注销或 Token 失效状态。
|
||||
5. 基础平台关闭或失效所有已打开业务应用页面访问状态。
|
||||
6. iframe 应用清理本地临时登录状态或停止继续访问业务接口。
|
||||
7. 用户再次访问基础平台或业务应用时,需要重新登录基础平台。
|
||||
|
||||
流程规则:
|
||||
|
||||
- 登录注销由基础平台统一处理。
|
||||
- 用户注销后,原 Token 不可继续访问业务应用。
|
||||
- 基础平台负责向已打开 iframe 应用同步注销状态。
|
||||
- iframe 应用发现 Token 已注销或失效时,不得继续放行访问。
|
||||
- 业务应用不提供独立注销逻辑作为常规退出入口;如业务页面存在退出入口,应调用基础平台统一注销能力。
|
||||
|
||||
## 11. 当前登录用户信息获取流程
|
||||
|
||||
当前登录用户信息获取流程用于解决基础平台门户和 iframe 应用如何获取当前用户、组织、角色和权限信息问题。
|
||||
|
||||
流程步骤:
|
||||
|
||||
1. 用户登录基础平台后,基础平台加载当前登录用户信息。
|
||||
2. iframe 应用打开时,通过基础平台 Token 请求当前登录用户信息。
|
||||
3. 基础平台校验 Token 有效性。
|
||||
4. 基础平台返回当前用户基础信息。
|
||||
5. 基础平台返回用户所属客户、默认组织、组织列表、角色列表。
|
||||
6. 基础平台返回当前应用下的菜单、操作权限和数据范围。
|
||||
7. iframe 应用根据返回结果加载业务页面和控制操作。
|
||||
|
||||
当前用户信息至少包括:
|
||||
|
||||
- 用户 ID
|
||||
- 用户姓名
|
||||
- 登录账号
|
||||
- 手机号
|
||||
- 所属客户
|
||||
- 默认组织
|
||||
- 可选组织列表
|
||||
- 角色列表
|
||||
- 可访问应用列表
|
||||
- 当前应用菜单
|
||||
- 当前应用操作权限
|
||||
- 当前应用数据范围
|
||||
|
||||
流程规则:
|
||||
|
||||
- 当前登录用户信息必须以基础平台为准。
|
||||
- 业务应用不得自行维护独立用户主档。
|
||||
- 业务应用可缓存用户信息,但缓存失效和刷新规则需服从基础平台授权结果。
|
||||
- 用户角色、组织、权限变更后,业务应用应能在合理时间内获取最新结果。
|
||||
- iframe 应用仅获取当前应用所需的用户、权限和数据范围信息。
|
||||
|
||||
## 12. Token 信息交互同步规则
|
||||
|
||||
Token 信息交互同步用于规范基础平台门户容器与各 iframe 应用之间的 Token 使用关系。
|
||||
|
||||
同步规则:
|
||||
|
||||
- 基础平台是 Token 唯一签发方。
|
||||
- 基础平台是 Token 唯一认证鉴权方。
|
||||
- 基础平台门户容器是 Token 持有方和同步方。
|
||||
- iframe 应用是 Token 使用方。
|
||||
- iframe 应用需要识别 Token 有效、无效、过期、刷新、注销、无权限等状态。
|
||||
- iframe 应用需要根据基础平台认证结果决定是否允许访问。
|
||||
- iframe 应用需要根据基础平台返回的用户、组织、角色、权限结果进行页面和数据控制。
|
||||
- 用户在基础平台注销后,所有 iframe 应用再次访问时必须感知 Token 已失效。
|
||||
- 用户权限变更后,iframe 应用应在下次鉴权、Token 状态同步或重新获取用户信息时同步变化。
|
||||
- 已打开 iframe 应用的 Token 状态由基础平台门户容器统一管理。
|
||||
|
||||
异常处理规则:
|
||||
|
||||
- Token 不存在:基础平台门户引导用户登录。
|
||||
- Token 无效:基础平台门户拒绝访问并引导重新登录。
|
||||
- Token 过期且可刷新:基础平台门户统一刷新 Token,并同步给 iframe 应用。
|
||||
- Token 过期且不可刷新:基础平台门户引导重新登录,并使已打开 iframe 应用访问失效。
|
||||
- 用户无应用权限:提示无权限访问。
|
||||
- 用户无菜单权限:不展示对应菜单。
|
||||
- 用户无操作权限:不展示或禁用对应操作。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
- 用户一次登录后,可访问多个已授权应用。
|
||||
- 未授权应用不可访问。
|
||||
- Token 无效或过期时,业务应用拒绝访问。
|
||||
- 用户停用、客户停用、应用停用后,业务应用拒绝访问。
|
||||
- 用户退出后,再访问业务应用需要重新登录。
|
||||
- 各业务应用均通过基础平台完成 Token 认证鉴权。
|
||||
- Token 即将过期或已过期但允许刷新时,由基础平台门户统一刷新 Token。
|
||||
- Token 刷新成功后,已打开 iframe 应用使用新 Token 继续访问。
|
||||
- Token 刷新失败后,基础平台门户引导用户重新登录。
|
||||
- 用户注销后,所有已打开 iframe 应用访问状态失效。
|
||||
- 当前用户信息获取结果包含用户、客户、默认组织、组织列表、角色、可访问应用、菜单、操作权限和数据范围。
|
||||
464
40-平台与架构/基础平台/基础平台产品设计.md
Normal file
464
40-平台与架构/基础平台/基础平台产品设计.md
Normal file
@@ -0,0 +1,464 @@
|
||||
# 基础平台产品设计
|
||||
|
||||
## 1. 文档说明
|
||||
|
||||
### 1.1 文档目的
|
||||
|
||||
本文档用于定义基础平台的产品设计和业务需求,作为研发部门进行基础平台研发、测试部门进行测试验收的依据。
|
||||
|
||||
本文档重点描述基础平台需要支撑的业务对象、功能范围、业务规则、产品边界和验收标准,不描述具体技术实现方案。
|
||||
|
||||
### 1.2 阅读对象
|
||||
|
||||
- 研发部门:根据本文档理解基础平台的业务范围、功能模块、数据对象、业务规则和系统边界。
|
||||
- 测试部门:根据本文档设计测试用例、验证功能完整性、业务规则正确性和跨模块协同结果。
|
||||
- 产品部门:根据本文档进行需求澄清、范围控制、版本验收和后续迭代管理。
|
||||
- 实施与交付团队:根据本文档理解基础平台能力边界和客户初始化配置方式。
|
||||
|
||||
### 1.3 建设背景
|
||||
|
||||
公司当前产品战略要求同时支撑纵向产品和横向产品:
|
||||
|
||||
- 纵向产品:营帐通拆分、连锁业务对账系统、分账系统、聚合支付系统、物流撮合行业分账试点。
|
||||
- 横向产品:门店选址规划系统、连锁门店客服系统,以及后续餐饮连锁行业产品线。
|
||||
|
||||
为避免各业务系统重复建设组织、账号、权限、菜单、配置、消息、流程等通用能力,需要建设统一基础平台,作为后续多产品、多客户、多组织、多门店复用的底座。
|
||||
|
||||
### 1.4 版本范围
|
||||
|
||||
本文档定义基础平台 1.0 范围。
|
||||
|
||||
1.0 重点支撑:
|
||||
|
||||
- 多客户管理
|
||||
- 组织管理
|
||||
- 用户与账号管理
|
||||
- 单点登录服务
|
||||
- 统一 Token 认证鉴权
|
||||
- 统一门户与菜单聚合
|
||||
- 应用 iframe 容器
|
||||
- 角色与权限管理
|
||||
- 菜单与应用入口管理
|
||||
- 基础配置管理
|
||||
- 操作日志
|
||||
- 消息与待办基础能力
|
||||
- 基础数据字典
|
||||
- 业务系统接入管理
|
||||
|
||||
1.0 不展开:
|
||||
|
||||
- 复杂工作流引擎
|
||||
- 复杂主数据治理平台
|
||||
- 数据中台
|
||||
- 统一报表平台
|
||||
- 复杂低代码配置平台
|
||||
- 复杂开放平台能力
|
||||
|
||||
## 2. 产品定位
|
||||
|
||||
### 2.1 基础平台定位
|
||||
|
||||
基础平台是公司各业务产品的统一底座,为连锁业务对账系统、分账系统、聚合支付系统、门店选址规划系统、门店大数据平台、连锁门店客服系统等产品提供通用管理能力。
|
||||
|
||||
基础平台不直接承载具体业务交易,不负责对账、分账、支付、客服、选址等具体业务逻辑。基础平台负责统一管理业务系统运行所需的基础对象和通用能力。
|
||||
|
||||
### 2.2 核心价值
|
||||
|
||||
- 统一客户、组织、用户、角色、权限、菜单等基础能力。
|
||||
- 支撑多产品复用,避免每个业务系统重复建设基础模块。
|
||||
- 支撑多客户、多品牌、多门店、多业务系统的统一管理。
|
||||
- 为后续分账系统 SaaS 化、聚合支付接入、客户项目交付提供基础能力。
|
||||
- 为研发技术架构调整提供清晰的业务边界和模块边界。
|
||||
|
||||
### 2.3 产品边界
|
||||
|
||||
基础平台负责:
|
||||
|
||||
- 客户管理
|
||||
- 组织管理
|
||||
- 用户账号管理
|
||||
- 单点登录服务
|
||||
- 统一 Token 认证鉴权
|
||||
- 统一门户与菜单聚合
|
||||
- 应用 iframe 容器
|
||||
- 角色权限管理
|
||||
- 菜单与应用入口管理
|
||||
- 基础配置管理
|
||||
- 消息与待办基础能力
|
||||
- 操作日志
|
||||
- 数据字典
|
||||
- 业务系统接入管理
|
||||
|
||||
基础平台不负责:
|
||||
|
||||
- 对账业务规则
|
||||
- 分账业务规则
|
||||
- 聚合支付业务规则
|
||||
- 客服工单业务规则
|
||||
- 选址评分模型
|
||||
- 经营分析指标计算
|
||||
- 具体客户项目的业务审批细节
|
||||
|
||||
## 3. 用户与使用场景
|
||||
|
||||
### 3.1 主要用户角色
|
||||
|
||||
| 角色 | 使用场景 |
|
||||
| --- | --- |
|
||||
| 平台超级管理员 | 管理客户、系统应用、全局配置、平台级账号 |
|
||||
| 客户管理员 | 管理本客户下组织、用户、角色、权限、菜单 |
|
||||
| 产品管理员 | 管理某个业务产品的菜单、权限项、接入配置 |
|
||||
| 实施人员 | 初始化客户组织、账号、权限、配置 |
|
||||
| 客服 / 运维人员 | 查询账号、权限、日志、消息状态,协助排查问题 |
|
||||
| 业务系统用户 | 通过基础平台获得账号、权限、菜单、消息和待办 |
|
||||
|
||||
### 3.2 典型使用场景
|
||||
|
||||
#### 3.2.1 新客户初始化
|
||||
|
||||
实施人员为新客户创建客户档案,配置客户基本信息,初始化组织架构、管理员账号、基础角色和可用应用。
|
||||
|
||||
#### 3.2.2 新产品接入
|
||||
|
||||
产品管理员将新业务系统注册到基础平台,配置应用入口、菜单、权限项和可授权范围。
|
||||
|
||||
#### 3.2.3 客户开通业务产品
|
||||
|
||||
平台管理员为客户开通连锁业务对账系统、分账系统、聚合支付等业务产品,客户管理员再给本客户内部用户分配权限。
|
||||
|
||||
#### 3.2.4 用户登录与权限控制
|
||||
|
||||
用户登录后,根据所属客户、组织、角色和权限,看到对应业务系统入口和菜单,并只能操作授权范围内的数据。
|
||||
|
||||
#### 3.2.5 账号和权限问题排查
|
||||
|
||||
客服或运维人员可查询用户所属组织、角色、权限、菜单、登录状态和操作日志,用于定位用户无法访问或权限异常问题。
|
||||
|
||||
## 4. 核心业务对象
|
||||
|
||||
### 4.1 对象清单
|
||||
|
||||
| 对象 | 定义 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 客户 | 使用公司产品的企业或平台客户 | 例如餐饮连锁客户、鞋服连锁客户、物流撮合平台客户 |
|
||||
| 应用 | 接入基础平台的业务系统 | 例如连锁业务对账系统、分账系统、聚合支付 |
|
||||
| 组织 | 客户内部管理结构 | 例如总部、品牌、区域、门店、部门 |
|
||||
| 用户 | 使用系统的自然人 | 可属于一个或多个组织 |
|
||||
| 账号 | 用户登录系统的身份标识 | 与用户关联 |
|
||||
| 登录会话 | 用户登录后形成的访问状态 | 用于支撑跨应用访问 |
|
||||
| Token | 用户访问应用和接口的认证凭证 | 由基础平台统一签发和校验 |
|
||||
| 门户框架 | 基础平台统一页面框架 | 包含头部、左侧菜单、Tab、内容区 |
|
||||
| 应用入口 | 业务应用在基础平台中的访问入口 | 可指向基础平台页面或 iframe 应用页面 |
|
||||
| 已打开页签 | 用户在门户中打开的页面 Tab | 可关联基础平台页面或业务应用页面 |
|
||||
| iframe 容器 | 基础平台承载业务应用页面的容器 | 用于嵌入业务应用界面 |
|
||||
| 角色 | 权限集合 | 例如客户管理员、财务主管、门店店长 |
|
||||
| 权限项 | 系统可控制的功能或操作 | 例如查看、创建、修改、审核、导出 |
|
||||
| 菜单 | 用户可见的系统导航入口 | 与应用和权限关联 |
|
||||
| 数据范围 | 用户可查看或操作的数据边界 | 例如全部、指定组织、指定门店 |
|
||||
| 配置项 | 可被客户或系统配置的参数 | 例如启用状态、业务开关 |
|
||||
| 消息 | 系统向用户发送的通知 | 可包含待办、通知、提醒 |
|
||||
| 操作日志 | 用户在系统中的关键操作记录 | 用于审计和排查 |
|
||||
|
||||
### 4.2 对象关系
|
||||
|
||||
- 一个客户可开通多个应用。
|
||||
- 一个客户下可建立多级组织。
|
||||
- 一个用户归属于一个客户。
|
||||
- 一个用户可关联多个组织,但必须有一个默认组织。
|
||||
- 一个用户可拥有多个角色。
|
||||
- 一个用户登录基础平台后,可在已授权应用之间进行单点访问。
|
||||
- 各业务应用访问时,Token 认证鉴权统一由基础平台完成。
|
||||
- 基础平台统一聚合所有应用菜单。
|
||||
- 业务应用不再独立渲染系统级菜单。
|
||||
- 业务应用页面通过 iframe 方式嵌入基础平台内容区。
|
||||
- 一个角色可包含多个权限项。
|
||||
- 一个权限项归属于一个应用。
|
||||
- 一个菜单归属于一个应用,并可绑定权限项。
|
||||
- 一个用户最终可访问的菜单和功能,由客户开通应用、用户角色、权限项和数据范围共同决定。
|
||||
|
||||
## 5. 功能模块设计
|
||||
|
||||
基础平台功能模块详细设计已拆分至独立文档,便于研发、测试和产品分别按模块评审、开发和验收。
|
||||
|
||||
功能模块目录:[功能模块](./功能模块/README.md)
|
||||
|
||||
| 编号 | 功能模块 | 独立文档 |
|
||||
| --- | --- | --- |
|
||||
| 5.1 | 客户管理 | [01-客户管理.md](./功能模块/01-客户管理.md) |
|
||||
| 5.2 | 应用管理 | [02-应用管理.md](./功能模块/02-应用管理.md) |
|
||||
| 5.3 | 组织管理 | [03-组织管理.md](./功能模块/03-组织管理.md) |
|
||||
| 5.4 | 用户与账号管理 | [04-用户与账号管理.md](./功能模块/04-用户与账号管理.md) |
|
||||
| 5.5 | 单点登录与统一认证鉴权 | [05-单点登录与统一认证鉴权.md](./功能模块/05-单点登录与统一认证鉴权.md) |
|
||||
| 5.6 | 统一门户与应用容器 | [06-统一门户与应用容器.md](./功能模块/06-统一门户与应用容器.md) |
|
||||
| 5.7 | 角色管理 | [07-角色管理.md](./功能模块/07-角色管理.md) |
|
||||
| 5.8 | 权限管理 | [08-权限管理.md](./功能模块/08-权限管理.md) |
|
||||
| 5.9 | 菜单管理 | [09-菜单管理.md](./功能模块/09-菜单管理.md) |
|
||||
| 5.10 | 基础配置管理 | [10-基础配置管理.md](./功能模块/10-基础配置管理.md) |
|
||||
| 5.11 | 消息与待办 | [11-消息与待办.md](./功能模块/11-消息与待办.md) |
|
||||
| 5.12 | 操作日志 | [12-操作日志.md](./功能模块/12-操作日志.md) |
|
||||
| 5.13 | 数据字典 | [13-数据字典.md](./功能模块/13-数据字典.md) |
|
||||
|
||||
## 6. 跨模块业务规则
|
||||
|
||||
### 6.1 多客户隔离
|
||||
|
||||
- 所有客户数据必须隔离。
|
||||
- 用户只能访问所属客户数据。
|
||||
- 平台管理员可管理多个客户。
|
||||
- 客户管理员只能管理本客户。
|
||||
|
||||
### 6.2 应用开通与访问
|
||||
|
||||
- 客户未开通应用时,该客户用户不可访问应用。
|
||||
- 应用停用时,所有客户均不可访问。
|
||||
- 用户是否能访问应用,由客户开通状态和用户角色共同决定。
|
||||
|
||||
### 6.3 权限生效顺序
|
||||
|
||||
用户最终权限由以下条件共同决定:
|
||||
|
||||
1. 客户是否启用。
|
||||
2. 用户是否启用。
|
||||
3. 应用是否启用。
|
||||
4. 客户是否开通应用。
|
||||
5. Token 是否有效。
|
||||
6. 用户是否拥有对应角色。
|
||||
7. 角色是否包含对应权限。
|
||||
8. 数据范围是否覆盖目标数据。
|
||||
|
||||
任一条件不满足,用户不可访问对应功能或数据。
|
||||
|
||||
### 6.4 历史数据处理
|
||||
|
||||
- 客户、组织、用户、角色停用后,不删除历史数据。
|
||||
- 历史操作日志保留。
|
||||
- 历史业务数据归属不因组织调整自动变化。
|
||||
|
||||
## 7. 与业务系统关系
|
||||
|
||||
### 7.1 与营帐通现状关系
|
||||
|
||||
营帐通作为现有产品和客户项目现状,不作为基础平台 1.0 的新接入应用。
|
||||
|
||||
营帐通拆分后的目标产品为连锁业务对账系统和分账系统。基础平台 1.0 面向拆分后的连锁业务对账系统、分账系统提供客户、组织、用户、角色、菜单、权限、日志等能力。
|
||||
|
||||
营帐通现有业务能力、现状问题和迁移策略不在基础平台中处理,应在营帐通现状文档、连锁业务对账系统规划文档和分账系统规划文档中分别承接。
|
||||
|
||||
### 7.2 与连锁业务对账系统关系
|
||||
|
||||
基础平台提供用户、权限、组织、菜单、配置等能力。
|
||||
|
||||
连锁业务对账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
|
||||
|
||||
连锁业务对账系统页面通过 iframe 嵌入基础平台内容区,不再独立渲染系统级菜单。
|
||||
|
||||
连锁业务对账系统负责对账任务、账单、流水、差异、报表等业务能力。
|
||||
|
||||
### 7.3 与分账系统关系
|
||||
|
||||
基础平台提供用户、权限、组织、菜单、配置等能力。
|
||||
|
||||
分账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
|
||||
|
||||
分账系统页面通过 iframe 嵌入基础平台内容区,不再独立渲染系统级菜单。
|
||||
|
||||
分账系统负责结算主体、账户体系、分账规则、清分、分账、退款、出款等业务能力。
|
||||
|
||||
### 7.4 与聚合支付关系
|
||||
|
||||
基础平台提供用户、权限、应用入口、配置等能力。
|
||||
|
||||
聚合支付系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
|
||||
|
||||
聚合支付系统页面通过 iframe 嵌入基础平台内容区,不再独立渲染系统级菜单。
|
||||
|
||||
聚合支付系统负责支付渠道、支付订单、支付流水、退款、支付状态、支付通知等业务能力。
|
||||
|
||||
### 7.5 与客服系统关系
|
||||
|
||||
基础平台提供用户、组织、角色、权限、菜单、消息等能力。
|
||||
|
||||
客服系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
|
||||
|
||||
客服系统页面通过 iframe 嵌入基础平台内容区,不再独立渲染系统级菜单。
|
||||
|
||||
客服系统负责客诉、咨询、工单、补偿、回访、责任归属等业务能力。
|
||||
|
||||
## 8. 测试验收要求
|
||||
|
||||
### 8.1 测试范围
|
||||
|
||||
测试部门需重点覆盖:
|
||||
|
||||
- 客户隔离
|
||||
- 组织管理
|
||||
- 用户账号管理
|
||||
- 单点登录
|
||||
- Token 认证鉴权
|
||||
- 统一门户布局
|
||||
- 菜单聚合
|
||||
- iframe 应用嵌入
|
||||
- Tab 与 keepalive
|
||||
- Token 共享与有效期管理
|
||||
- 角色权限管理
|
||||
- 菜单展示控制
|
||||
- 应用开通控制
|
||||
- 数据范围控制
|
||||
- 配置项维护
|
||||
- 消息与待办
|
||||
- 操作日志
|
||||
- 停用规则
|
||||
- 多角色权限合并
|
||||
|
||||
### 8.2 核心测试场景
|
||||
|
||||
#### 8.2.1 客户隔离测试
|
||||
|
||||
- A 客户用户不能看到 B 客户组织、用户、角色、菜单、日志。
|
||||
- A 客户停用后,A 客户用户不可登录。
|
||||
- B 客户不受 A 客户停用影响。
|
||||
|
||||
#### 8.2.2 应用开通测试
|
||||
|
||||
- 未开通应用的客户不可见应用入口。
|
||||
- 开通应用后,客户管理员可为用户授权。
|
||||
- 应用停用后,所有客户均不可访问该应用。
|
||||
|
||||
#### 8.2.3 角色权限测试
|
||||
|
||||
- 用户分配角色后可访问对应菜单和操作。
|
||||
- 移除角色后权限失效。
|
||||
- 多角色用户权限为授权能力组合。
|
||||
- 无权限用户不可通过直接访问地址绕过权限。
|
||||
|
||||
#### 8.2.4 单点登录与 Token 认证鉴权测试
|
||||
|
||||
- 用户登录基础平台后,可进入已授权业务应用。
|
||||
- 用户未登录时,不可访问基础平台门户和业务应用。
|
||||
- 用户访问未授权应用时,被拒绝访问。
|
||||
- 用户访问业务应用入口时,统一进入基础平台门户登录和访问流程。
|
||||
- Token 无效时,业务应用拒绝访问。
|
||||
- Token 过期时,业务应用拒绝访问。
|
||||
- Token 即将过期或已过期但允许刷新时,由基础平台门户统一刷新 Token。
|
||||
- Token 刷新成功后,已打开 iframe 应用使用新 Token 继续访问。
|
||||
- Token 刷新失败后,基础平台门户引导用户重新登录。
|
||||
- 用户退出登录后,原访问状态失效。
|
||||
- 用户在基础平台注销后,再访问其他应用时需要重新认证。
|
||||
- 用户停用后,业务应用认证鉴权不通过。
|
||||
- 客户停用后,该客户下用户认证鉴权不通过。
|
||||
- 应用停用后,所有用户不可访问该应用。
|
||||
- 所有接入应用均通过基础平台完成 Token 认证鉴权。
|
||||
|
||||
#### 8.2.5 当前登录用户信息测试
|
||||
|
||||
- 业务应用可通过基础平台 Token 获取当前登录用户信息。
|
||||
- 当前用户信息包含用户、客户、默认组织、组织列表、角色、可访问应用、菜单、操作权限和数据范围。
|
||||
- 用户切换组织后,业务应用获取到的当前组织和数据范围正确。
|
||||
- 用户权限变更后,业务应用重新获取用户信息时权限结果正确。
|
||||
- Token 无效时,不可获取当前用户信息。
|
||||
|
||||
#### 8.2.6 统一门户与 iframe 应用容器测试
|
||||
|
||||
- 基础平台主页面包含头部、左侧菜单导航栏和右侧内容区。
|
||||
- 头部第一部分展示应用 logo、平台名称、菜单折叠按钮、常用菜单、主题设置、消息按钮、语言切换按钮、用户信息。
|
||||
- 头部第二部分展示已打开页面 Tab 导航栏。
|
||||
- 左侧菜单展示用户有权限访问的所有应用菜单。
|
||||
- 用户无权限应用不展示菜单。
|
||||
- 用户无权限菜单不展示。
|
||||
- 点击基础平台菜单后,在右侧内容区打开基础平台页面。
|
||||
- 点击业务应用菜单后,在右侧内容区通过 iframe 打开业务应用页面。
|
||||
- 业务应用页面不展示自身系统级菜单。
|
||||
- 打开页面后生成对应 Tab。
|
||||
- 切换 Tab 时已打开页面状态保持。
|
||||
- 关闭 Tab 后对应页面状态释放。
|
||||
- 刷新当前 Tab 时仅刷新当前页面。
|
||||
- 多个已打开 iframe 应用共享基础平台登录态。
|
||||
- Token 刷新后,已打开 iframe 应用可继续访问。
|
||||
- Token 失效或用户注销后,已打开 iframe 应用不可继续访问。
|
||||
|
||||
#### 8.2.7 数据范围测试
|
||||
|
||||
- 本组织用户只能访问本组织数据。
|
||||
- 本组织及下级组织用户可访问本组织和下级组织数据。
|
||||
- 指定组织权限按指定范围生效。
|
||||
- 不同客户之间数据不可跨越。
|
||||
|
||||
#### 8.2.8 停用规则测试
|
||||
|
||||
- 停用客户后,客户下用户不可登录。
|
||||
- 停用组织后,不可继续分配给新用户。
|
||||
- 停用用户后,用户不可登录。
|
||||
- 停用角色后,不可继续分配。
|
||||
- 停用菜单后,用户不可见。
|
||||
|
||||
#### 8.2.9 日志测试
|
||||
|
||||
- 新增、修改、删除、启用、停用、授权、配置变更等关键操作生成日志。
|
||||
- 日志记录操作人、时间、对象、结果。
|
||||
- 日志按客户隔离。
|
||||
|
||||
## 9. 验收清单
|
||||
|
||||
| 模块 | 验收项 | 是否必须 |
|
||||
| --- | --- | --- |
|
||||
| 客户管理 | 支持客户新增、编辑、停用、应用开通 | 是 |
|
||||
| 应用管理 | 支持应用、入口、菜单、权限项维护 | 是 |
|
||||
| 组织管理 | 支持多级组织树和组织停用 | 是 |
|
||||
| 用户管理 | 支持用户、账号、组织、角色维护 | 是 |
|
||||
| 单点登录 | 支持一次登录访问多个已授权应用 | 是 |
|
||||
| Token 认证鉴权 | 所有应用 Token 认证鉴权均通过基础平台完成 | 是 |
|
||||
| Token 刷新 | 支持基础平台门户统一刷新 Token 并同步给已打开 iframe 应用 | 是 |
|
||||
| 登录注销 | 用户注销后原 Token 不可继续访问应用 | 是 |
|
||||
| 当前用户信息 | 支持业务应用通过 Token 获取当前登录用户信息 | 是 |
|
||||
| 统一门户 | 支持头部、左侧菜单、Tab、右侧内容区布局 | 是 |
|
||||
| 菜单聚合 | 支持聚合展示所有授权应用菜单 | 是 |
|
||||
| iframe 应用容器 | 支持业务应用 iframe 嵌入基础平台内容区 | 是 |
|
||||
| Tab 与 keepalive | 支持已打开页面 Tab 管理和状态保持 | 是 |
|
||||
| Token 共享 | 支持已打开 iframe 应用共享基础平台 Token | 是 |
|
||||
| 角色管理 | 支持角色授权和数据范围配置 | 是 |
|
||||
| 权限管理 | 支持应用、菜单、操作、数据范围控制 | 是 |
|
||||
| 菜单管理 | 支持菜单层级、排序、启停和权限绑定 | 是 |
|
||||
| 配置管理 | 支持平台、客户、应用配置 | 是 |
|
||||
| 消息待办 | 支持消息查询、已读未读、待办跳转 | 是 |
|
||||
| 操作日志 | 支持关键操作记录和查询 | 是 |
|
||||
| 多客户隔离 | 客户数据不可互相访问 | 是 |
|
||||
| 停用规则 | 客户、组织、用户、角色、菜单停用规则正确 | 是 |
|
||||
|
||||
## 10. 后续迭代方向
|
||||
|
||||
基础平台 1.0 完成后,后续可按业务需要迭代:
|
||||
|
||||
- 更完整的流程审批能力
|
||||
- 更完整的主数据管理能力
|
||||
- 更细的数据权限模型
|
||||
- 外部客户自助开通能力
|
||||
- 开放平台和第三方接入能力
|
||||
- 统一通知中心
|
||||
- 更完整的审计与风控能力
|
||||
- 统一首页和工作台
|
||||
- 外部协同单点登录接入
|
||||
|
||||
上述能力不纳入 1.0 必须范围。
|
||||
|
||||
## 11. 2.0 版本规划补充
|
||||
|
||||
### 11.1 外部协同单点登录接入
|
||||
|
||||
基础平台 2.0 需要支持外部协同场景下的单点登录接入,使外部合作方、客户已有系统或第三方协同平台能够按规则接入基础平台认证体系。
|
||||
|
||||
2.0 重点支持:
|
||||
|
||||
- 外部系统单点登录接入
|
||||
- 外部协同用户身份识别
|
||||
- 外部用户与内部客户、组织、角色的映射关系
|
||||
- 外部协同应用访问授权
|
||||
- 外部协同登录状态管理
|
||||
- 外部接入审计与日志
|
||||
|
||||
2.0 业务目标:
|
||||
|
||||
- 支持客户已有系统与公司业务系统之间的协同登录。
|
||||
- 支持外部合作方访问被授权的业务应用。
|
||||
- 保证外部协同用户访问仍受基础平台客户、组织、角色、权限、数据范围控制。
|
||||
|
||||
2.0 不在基础平台 1.0 范围内,研发和测试在 1.0 阶段只需预留产品边界认知,不作为 1.0 验收项。
|
||||
152
40-平台与架构/基础平台/统一门户与应用容器设计.md
Normal file
152
40-平台与架构/基础平台/统一门户与应用容器设计.md
Normal file
@@ -0,0 +1,152 @@
|
||||
# 统一门户与应用容器设计
|
||||
|
||||
## 1. 文档说明
|
||||
|
||||
本文档是《基础平台产品设计》的专题补充文档,用于定义基础平台统一门户、菜单聚合、Tab 导航、右侧内容区、iframe 应用容器、keepalive、Token 共享与业务应用改造要求。
|
||||
|
||||
本文档阅读对象为研发部门、测试部门、产品部门和实施交付团队。
|
||||
|
||||
## 2. 产品定位
|
||||
|
||||
统一门户与应用容器用于承载基础平台页面和各业务应用页面。基础平台负责所有业务系统的菜单聚合、业务链接入口、页面框架、Tab 管理、iframe 嵌入和 Token 有效期管理。
|
||||
|
||||
业务应用不再独立渲染系统级菜单。业务应用只负责提供自身业务页面,由基础平台通过 iframe 嵌入到右侧内容区。
|
||||
|
||||
## 3. 页面总体布局
|
||||
|
||||
基础平台主页面由三部分组成:
|
||||
|
||||
- 头部区域
|
||||
- 左侧菜单导航栏
|
||||
- 右侧内容区
|
||||
|
||||
右侧内容区用于展示基础平台自身页面和各业务应用 iframe 页面。
|
||||
|
||||
## 4. 头部区域
|
||||
|
||||
头部区域分为上下两部分。
|
||||
|
||||
第一部分为全局操作区,包含:
|
||||
|
||||
- 应用 logo
|
||||
- 平台名称
|
||||
- 左侧菜单折叠按钮
|
||||
- 常用菜单
|
||||
- 主题设置
|
||||
- 消息按钮
|
||||
- 语言切换按钮
|
||||
- 用户信息
|
||||
|
||||
第二部分为已打开页面的 Tab 导航栏,包含:
|
||||
|
||||
- 已打开页面 Tab
|
||||
- 当前激活页面状态
|
||||
- 关闭单个 Tab
|
||||
- 关闭其他 Tab
|
||||
- 关闭全部可关闭 Tab
|
||||
- 刷新当前 Tab
|
||||
|
||||
## 5. 左侧菜单导航栏
|
||||
|
||||
左侧菜单导航栏展示当前用户有权限访问的所有菜单。
|
||||
|
||||
菜单来源:
|
||||
|
||||
- 基础平台菜单
|
||||
- 连锁业务对账系统菜单
|
||||
- 分账系统菜单
|
||||
- 聚合支付菜单
|
||||
- 门店选址规划系统菜单
|
||||
- 连锁门店客服系统菜单
|
||||
- 后续接入应用菜单
|
||||
|
||||
菜单展示规则:
|
||||
|
||||
- 用户无权限的应用不展示。
|
||||
- 用户无权限的菜单不展示。
|
||||
- 客户未开通的应用菜单不展示。
|
||||
- 应用停用后,该应用菜单不展示。
|
||||
- 菜单支持多级展示。
|
||||
- 菜单支持折叠和展开。
|
||||
- 菜单点击后,在右侧内容区打开对应页面。
|
||||
|
||||
## 6. 右侧内容区
|
||||
|
||||
右侧内容区用于展示:
|
||||
|
||||
- 基础平台自身业务页面
|
||||
- 业务应用 iframe 页面
|
||||
|
||||
展示规则:
|
||||
|
||||
- 点击基础平台菜单时,在内容区打开基础平台页面。
|
||||
- 点击业务应用菜单时,在内容区以 iframe 方式打开业务应用页面。
|
||||
- 已打开页面在 Tab 导航栏中生成对应 Tab。
|
||||
- 切换 Tab 时,内容区切换到对应页面。
|
||||
- 关闭 Tab 时,关闭对应页面容器。
|
||||
|
||||
## 7. iframe 应用嵌入规则
|
||||
|
||||
业务应用采用 iframe 方式嵌入基础平台。
|
||||
|
||||
嵌入规则:
|
||||
|
||||
- iframe 页面地址由基础平台菜单或应用入口配置提供。
|
||||
- iframe 打开前,基础平台需要确认当前用户对该应用和菜单有访问权限。
|
||||
- iframe 打开时,需要让业务应用获得基础平台 Token。
|
||||
- 业务应用使用基础平台 Token 完成自身业务接口访问鉴权。
|
||||
- iframe 页面不展示业务应用自身系统级菜单。
|
||||
- iframe 页面应适配基础平台内容区展示。
|
||||
|
||||
## 8. Tab 与 keepalive 规则
|
||||
|
||||
基础平台需要对已打开应用页面进行 keepalive 管理。
|
||||
|
||||
规则包括:
|
||||
|
||||
- 已打开 Tab 可保持页面状态。
|
||||
- 用户在 Tab 之间切换时,已打开页面不应重复初始化,除非用户主动刷新。
|
||||
- 用户关闭 Tab 后,对应页面状态释放。
|
||||
- 用户刷新当前 Tab 时,仅刷新当前页面。
|
||||
- 基础平台应管理已打开 iframe 应用页面的生命周期。
|
||||
- keepalive 范围应可控,避免无限制保留页面导致性能问题。
|
||||
|
||||
## 9. Token 共享与有效期管理
|
||||
|
||||
基础平台负责对已打开应用系统进行 Token 有效期管理和 Token 共享。
|
||||
|
||||
规则包括:
|
||||
|
||||
- 基础平台持有并管理当前登录用户的 Token。
|
||||
- iframe 应用页面使用基础平台 Token。
|
||||
- 已打开的多个 iframe 应用共享同一基础平台登录态。
|
||||
- Token 刷新由基础平台统一处理。
|
||||
- iframe 应用不主动刷新 Token,只响应基础平台门户容器同步的 Token 状态。
|
||||
- Token 刷新成功后,已打开应用应能使用新 Token 继续访问。
|
||||
- Token 失效或注销后,已打开应用再次访问时应被拒绝,并引导回基础平台登录。
|
||||
- 用户注销后,基础平台关闭或失效所有已打开应用访问状态。
|
||||
- 基础平台需要向已打开应用同步 Token 有效、刷新、失效、注销等状态。
|
||||
|
||||
## 10. 业务应用改造要求
|
||||
|
||||
接入基础平台的业务应用需要满足:
|
||||
|
||||
- 不再独立渲染系统级菜单。
|
||||
- 支持被基础平台 iframe 嵌入。
|
||||
- 支持接收或获取基础平台 Token。
|
||||
- 所有业务接口访问均使用基础平台 Token。
|
||||
- 支持 Token 刷新后的访问延续。
|
||||
- 支持 Token 失效后的访问拒绝。
|
||||
- 页面布局适配基础平台内容区。
|
||||
|
||||
## 11. 验收标准
|
||||
|
||||
- 基础平台可聚合展示用户有权限访问的所有应用菜单。
|
||||
- 业务应用不再独立展示系统级菜单。
|
||||
- 点击业务应用菜单后,可在右侧内容区通过 iframe 打开应用页面。
|
||||
- 打开的页面可生成 Tab。
|
||||
- Tab 切换时页面状态可保持。
|
||||
- 关闭 Tab 后页面状态释放。
|
||||
- iframe 应用可使用基础平台 Token 访问业务接口。
|
||||
- Token 刷新后,已打开 iframe 应用可继续访问。
|
||||
- 用户注销后,已打开 iframe 应用不可继续访问。
|
||||
Reference in New Issue
Block a user