bk-user
bk-user copied to clipboard
TencentBlueKing
【已评审】合并组织架构和目录 + 用户/组织/目录删除逻辑优化
已评审
关联需求
1、用户目录逻辑删除会导致相同登陆域的目录不可创建 #441 2、未关联部门的用户应该有地方展示 #35 3、被软删除的用户需要在前端有所体现 #623
需求背景
方案说明
原型
用户删除
组织删除
目录删除
数据回收策略设置
用户数据还原
组织数据还原
目录数据还原
未关联部门用户展示方式
数据恢复逻辑图有点问题，由于用户和组织都是目录内唯一的？恢复时应先判断其所属目录的存在与否，然后才是目录内判断id是否重复。不然可能会做成跨目录判断id是否重复的逻辑。
删除比较简单，数据恢复涉及到的各种交互细节没有提供，至少在设计稿评审时应提供。
数据恢复逻辑图有点问题，由于用户和组织都是目录内唯一的？恢复时应先判断其所属目录的存在与否，然后才是目录内判断id是否重复。不然可能会做成跨目录判断id是否重复的逻辑。
删除比较简单，数据恢复涉及到的各种交互细节没有提供，至少在设计稿评审时应提供。
1、数据恢复逻辑图已修改
2、交互细节已补充，新增了还原操作的二次确认交互。（详见原型交互）
用户/组织/目录删除逻辑优化
当前状态
- ProfileCategory status:
NORMAL / INACTIVE - Department status: 目前没有这个字段, 只有
enabled - Profile status:
NORMAL / LOCKED / DELETED / DISABLED / EXPIRED+enabled
必须
- 先去看下 profile/department/category目前的删除逻辑, 以及删除前做的检测
- 了解 category / department / profile之间的关系, 特别是 部门-子部门 以及 部门-用户 关系
相关开发需求
- [配置] 全局配置 / 回收策略配置 => 数据回收保留天数 (用户/组织/目录)
- [定时任务] 按照数据保留天数执行
硬删除, 并且有审计 - [审计] 软删除/恢复/硬删除都要有审计记录
- [模型] 设计回收箱的数据结构
id(自增) / object_type(profile,department,category) / object_id(对应表的主键) / create_time / update_time - [删除] 先做删除目录
- 生命周期: normal -> inactive -> deleted -> 物理删除
- 删除需要清理所有关联数据: 所有category_id为外键的数据
- 需要考虑事务, 以及目录下十万级用户删除的场景
- 因为category在所有地方都会先校验, 所以理论上删除只需要改category本身的状态就行, 不需要联动操作改部门/用户的状态
- 还原, 判断有没有冲突即可, 没有冲突直接状态操作改回去
- [删除] 再做删除用户
- deleted 理论上已经是被删除状态
- 同时需要
enabled置为 0? 需要考虑会有什么影响 - 存量的deleted用户怎么处理?
- 恢复直接把状态改回去
- 还原, 需要判定用户-部门-目录等关系, 这个根据产品设计具体考虑(需要确认是否合理)
- [删除] 最后做删除部门(有疑问, 见后面, 需要同产品再确定, 确定之后才能做)
- [需求] 未关联部门用户展示
问题
删除组织有疑问
设计的逻辑: 单组织用户, 跟随组织一并被删除, 以及恢复; 跨组用户, 仅解除用户-组织关系, 恢复组织时, 需要一并恢复
- 删除用户 A, 还未过 30 天(未清理)
- 删除 A 的上级组织, 此时联动删除用户, 包括 A 与上级组织的关系
- 恢复 这个被删除的上级组织, 那么 A 也会被恢复(因为无法标识 A 是哪种情况下被删除的)
另外, 删除部门是有前提的
- 当前部门存在下级组织无法删除
- 当前部门下存在用户无法删除
是否:
- 删除部门只是
部门+部门-用户关系, 不动用户; 如果部门被硬删除了, 那么下面的用户全部变成无组织的用户 - 删除部门, 级联删除下面所有子部门?
先做目录删除恢复(看设计稿, 看代码, 方案先行), 完成全流程 => 再去做其他的
@Canway-shiisa
问题
删除组织有疑问
设计的逻辑: 单组织用户, 跟随组织一并被删除, 以及恢复; 跨组用户, 仅解除用户-组织关系, 恢复组织时, 需要一并恢复
- 删除用户 A, 还未过 30 天(未清理)
- 删除 A 的上级组织, 此时联动删除用户, 包括 A 与上级组织的关系
- 恢复 这个被删除的上级组织, 那么 A 也会被恢复(因为无法标识 A 是哪种情况下被删除的)
另外, 删除部门是有前提的
- 当前部门存在下级组织无法删除
- 当前部门下存在用户无法删除
是否:
- 删除部门只是
部门+部门-用户关系, 不动用户; 如果部门被硬删除了, 那么下面的用户全部变成无组织的用户- 删除部门, 级联删除下面所有子部门?
之前的结论是，删除部门是做全量删除：删除该部门下的所有子部门和用户（在回收站内的部门tab页作为原子项展示即可，该部门下联动被删除的内容不对用户暴露），还原也是做全量还原。不再走之前的「存在用户的部门无法删除」的校验逻辑。
先删除用户A，再删除用户A的上级组织B后： 1、恢复用户A，提醒原组织不存在，需要重新分配组织。 2、恢复组织B，不会联动恢复用户A。以时间为维度，该恢复操作：理论上对早于「该组织删除时间」的已删除用户不会生效（利用时间戳，或者考虑下别的逻辑）。实现上是否有困难？需要后端评估下。
另外： 上面的原型稿很多信息已经过时，没有更新。例如：回收站内的数据查看权限问题，是拥有同删除权限的用户共享回收站数据。 实现上优先以设计稿为准：
cc @Canway-shiisa @wklken
这个issue分两块做
- 先做前端的调整, 目录和组织架构两个页面的合并 @yuri0528 这块主要是前端工作, 后台我这边配合
- 再做删除/回收的逻辑 @Canway-shiisa
这个issue分两块做
- 先做前端的调整, 目录和组织架构两个页面的合并 @yuri0528 这块主要是前端工作, 后台我这边配合
- 再做删除/回收的逻辑 @Canway-shiisa
2.亮哥看下这块是否拆分下issue哩，我们按拆分issue逐个处理
- https://github.com/TencentBlueKing/bk-user/issues/896
- https://github.com/TencentBlueKing/bk-user/issues/897
- https://github.com/TencentBlueKing/bk-user/issues/908
- https://github.com/TencentBlueKing/bk-user/issues/901
- https://github.com/TencentBlueKing/bk-user/issues/902
- https://github.com/TencentBlueKing/bk-user/issues/903
- https://github.com/TencentBlueKing/bk-user/issues/898
- https://github.com/TencentBlueKing/bk-user/issues/899