【已评审】合并组织架构和目录 + 用户/组织/目录删除逻辑优化

[Shutulee]

已评审

关联需求

1、用户目录逻辑删除会导致相同登陆域的目录不可创建 #441
2、未关联部门的用户应该有地方展示 #35
3、被软删除的用户需要在前端有所体现 #623

需求背景

方案说明

原型

用户删除

组织删除

目录删除

数据回收策略设置

用户数据还原

组织数据还原

目录数据还原

未关联部门用户展示方式

[EchoQT]

数据恢复逻辑图有点问题，由于用户和组织都是目录内唯一的？恢复时应先判断其所属目录的存在与否，然后才是目录内判断id是否重复。不然可能会做成跨目录判断id是否重复的逻辑。

删除比较简单，数据恢复涉及到的各种交互细节没有提供，至少在设计稿评审时应提供。

[Shutulee]

数据恢复逻辑图有点问题，由于用户和组织都是目录内唯一的？恢复时应先判断其所属目录的存在与否，然后才是目录内判断id是否重复。不然可能会做成跨目录判断id是否重复的逻辑。

删除比较简单，数据恢复涉及到的各种交互细节没有提供，至少在设计稿评审时应提供。

1、数据恢复逻辑图已修改
2、交互细节已补充，新增了还原操作的二次确认交互。（详见原型交互）

[EchoQT]

发现目录被占用时还能恢复成功？

基本没大问题了，后面我直接看设计稿。

[wklken]

用户/组织/目录删除逻辑优化

当前状态

• ProfileCategory status: NORMAL / INACTIVE
• Department status: 目前没有这个字段, 只有 enabled
• Profile status: NORMAL / LOCKED / DELETED / DISABLED / EXPIRED + enabled

必须

1. 先去看下 profile/department/category目前的删除逻辑, 以及删除前做的检测
2. 了解 category / department / profile之间的关系, 特别是 部门-子部门 以及 部门-用户 关系

相关开发需求

1. [配置] 全局配置 / 回收策略配置 => 数据回收保留天数 (用户/组织/目录)
2. [定时任务] 按照数据保留天数执行硬删除, 并且有审计
3. [审计] 软删除/恢复/硬删除都要有审计记录
4. [模型] 设计回收箱的数据结构 id(自增) / object_type(profile,department,category) / object_id(对应表的主键) / create_time / update_time
5. [删除] 先做删除目录
   • 生命周期: normal -> inactive -> deleted -> 物理删除
   • 删除需要清理所有关联数据: 所有category_id为外键的数据
   • 需要考虑事务, 以及目录下十万级用户删除的场景
   • 因为category在所有地方都会先校验, 所以理论上删除只需要改category本身的状态就行, 不需要联动操作改部门/用户的状态
   • 还原, 判断有没有冲突即可, 没有冲突直接状态操作改回去
6. [删除] 再做删除用户
   • deleted 理论上已经是被删除状态
   • 同时需要enabled置为 0? 需要考虑会有什么影响
   • 存量的deleted用户怎么处理?
   • 恢复直接把状态改回去
   • 还原, 需要判定用户-部门-目录等关系, 这个根据产品设计具体考虑(需要确认是否合理)
7. [删除] 最后做删除部门(有疑问, 见后面, 需要同产品再确定, 确定之后才能做)
8. [需求] 未关联部门用户展示

问题

删除组织有疑问

设计的逻辑: 单组织用户, 跟随组织一并被删除, 以及恢复; 跨组用户, 仅解除用户-组织关系, 恢复组织时, 需要一并恢复

• 删除用户 A, 还未过 30 天(未清理)
• 删除 A 的上级组织, 此时联动删除用户, 包括 A 与上级组织的关系
• 恢复 这个被删除的上级组织, 那么 A 也会被恢复(因为无法标识 A 是哪种情况下被删除的)

另外, 删除部门是有前提的

• 当前部门存在下级组织无法删除
• 当前部门下存在用户无法删除

是否:

1. 删除部门只是 部门 + 部门-用户关系, 不动用户; 如果部门被硬删除了, 那么下面的用户全部变成无组织的用户
2. 删除部门, 级联删除下面所有子部门?

---

先做目录删除恢复(看设计稿, 看代码, 方案先行), 完成全流程 => 再去做其他的

@Canway-shiisa

[Shutulee]

问题

删除组织有疑问

设计的逻辑: 单组织用户, 跟随组织一并被删除, 以及恢复; 跨组用户, 仅解除用户-组织关系, 恢复组织时, 需要一并恢复

• 删除用户 A, 还未过 30 天(未清理)
• 删除 A 的上级组织, 此时联动删除用户, 包括 A 与上级组织的关系
• 恢复 这个被删除的上级组织, 那么 A 也会被恢复(因为无法标识 A 是哪种情况下被删除的)

另外, 删除部门是有前提的

• 当前部门存在下级组织无法删除
• 当前部门下存在用户无法删除

是否:

1. 删除部门只是 部门 + 部门-用户关系, 不动用户; 如果部门被硬删除了, 那么下面的用户全部变成无组织的用户
2. 删除部门, 级联删除下面所有子部门?

之前的结论是，删除部门是做全量删除：删除该部门下的所有子部门和用户（在回收站内的部门tab页作为原子项展示即可，该部门下联动被删除的内容不对用户暴露），还原也是做全量还原。不再走之前的「存在用户的部门无法删除」的校验逻辑。

先删除用户A，再删除用户A的上级组织B后：
1、恢复用户A，提醒原组织不存在，需要重新分配组织。
2、恢复组织B，不会联动恢复用户A。以时间为维度，该恢复操作：理论上对早于「该组织删除时间」的已删除用户不会生效（利用时间戳，或者考虑下别的逻辑）。实现上是否有困难？需要后端评估下。

另外：
上面的原型稿很多信息已经过时，没有更新。例如：回收站内的数据查看权限问题，是拥有同删除权限的用户共享回收站数据。
实现上优先以设计稿为准：

cc @Canway-shiisa @wklken

[wklken]

@Shutulee @Xmandon 内部设计稿怎么转出来放 github? 或者第三方存储, 需要共享给到他们

[Shutulee]

@Shutulee @Xmandon 内部设计稿怎么转出来放 github? 或者第三方存储, 需要共享给到他们

抱歉，我的问题。

[wklken]

这个issue分两块做

1. 先做前端的调整, 目录和组织架构两个页面的合并 @yuri0528 这块主要是前端工作, 后台我这边配合
2. 再做删除/回收的逻辑 @Canway-shiisa

[Canway-shiisa]

这个issue分两块做

1. 先做前端的调整, 目录和组织架构两个页面的合并 @yuri0528 这块主要是前端工作, 后台我这边配合
2. 再做删除/回收的逻辑 @Canway-shiisa

2.亮哥看下这块是否拆分下issue哩，我们按拆分issue逐个处理

[wklken]

• [删除回收] 回收策略设置 #896
• [删除回收] 回收站逻辑和页面 #897
  • 【删除回收】回收站展示 #908
  • 【删除回收】目录删除 #901
  • 【删除回收】用户删除  #902
  • 【删除回收】部门删除  #903
• [删除回收] 定时任务, 执行永久删除 #898
• [删除回收] 未关联部门用户的展示 #899