配套方案并入共享资料库方案.md 5.3 KB

配套方案并入共享资料库方案(含UNBIND方案B)

决策:①ADMIN无条件拥有UNBIND_ATTACHMENT(方案B);②"配套方案"(原子案SUB_PLAN) 与支撑成果/方案训考资料/典型案例并轨为共享资料库附件的第四种类型,入库、挂载、 解绑、留存语义与另外三类完全一致。

一、目标语义

  1. 共享资料库条目新增类型ACCOMPANYING_PLAN(配套方案),类型集合扩为四值;
  2. 主案"配套方案"Tab:上传→以配套方案类型入库共享资料库并自动挂载到当前主案; 挂载→打开共享资料库挂载弹窗,配套方案排前、其余类型排后(软排序,不过滤); 列表→仅显示挂载到当前主案且类型为配套方案的条目(与其他三类Tab同构); 解绑/拖动排序→走附件挂载关系(binding)接口;
  3. 解绑后条目保留在共享资料库,与任何主案无关联也不删除;
  4. 停止新建SUB_PLAN文档(接口拒绝,存量数据迁移),子案跨主案挂载(0018)与 子案重排等专属链路随之退役(接口保留兼容但无数据可达)。

二、权限与可见性变化(需知悉)

  • 原SUB_PLAN可见性/ACL继承其父主案;并轨后与其他附件一致:标题对全体登录用户 可见(列表全量可见),正文/下载由"至少一个挂载主案的查看/下载权限"控制;
  • 密级保留文档自身密级;密码锁仍仅主案可设(附件不可设密,与现状一致);
  • 删除配套方案=删除共享资料库条目:被挂载时拒绝(ATTACHMENT_IN_USE),先解绑;
  • 主案删除不再受"存在子方案"限制(MAIN_PLAN_HAS_CHILDREN退役),挂载关系随主案 软删,配套方案条目留在库中。

三、数据库迁移(0020_sub_plan_to_attachment / Flyway V5)

  1. CHECK约束ck_doc_document_document_attachment_type扩四值:以新名 ck_doc_document_attachment_type_v2重建(旧名DROP IF EXISTS,新名ADD IF NOT EXISTS, 双引擎按名幂等);
  2. 同名消歧:存活子案与存活附件同名、或与更小id存活子案同名者,追加"(id)"后缀;
  3. 全部SUB_PLAN(含软删)→document_type='ATTACHMENT'、 attachment_type='ACCOMPANYING_PLAN'、visibility_type='ALL_AUTHENTICATED';
  4. 自有子案关系转挂载:存活子案按parent_document_id补doc_attachment_binding (sort_no沿用,NOT EXISTS防重);
  5. doc_sub_plan_binding活跃行转doc_attachment_binding后软删(防重跑双转);
  6. 重算全部主案attachment_count;child_count清零;
  7. 幂等可重跑;降级:存在ACCOMPANYING_PLAN数据时拒绝有损回退。 生产升级仍走dms-server upgrade-db(Alembic 0020),Java并行环境由Flyway V5 幂等承接。

四、后端改动(两侧同步)

  • 枚举/字典:AttachmentType.ACCOMPANYING_PLAN;UI字典attachmentTypes四值 (配套方案10/支撑成果20/训考30/典型40),服务端启动校验两版同步生效;
  • 方案B:plan_allowed_actions ADMIN分支删除"附件挂载数>0"条件,恒含UNBIND (顺带消除主案列表每行一次的count查询);
  • SUB_PLAN创建拒绝(单传/批量/覆盖一致): "配套方案已并入共享资料库,请以附件类型ACCOMPANYING_PLAN上传";
  • 其余SUB_PLAN读路径(listSubPlans/bind/unbind/重排/守卫)保留兼容,数据迁移后 自然不可达。

五、前端改动

  • AttachmentType枚举+ACCOMPANYING_PLAN;关系Tab首项由"sub"改为该类型; 两处关系面板(浏览/管理)统一走挂载附件列表(类型=当前Tab)、上传自动挂载、 挂载弹窗(配套方案Tab软排序)、解绑/拖动走binding接口;
  • 检索类型徽章、定位Tab、共享资料库类型筛选与列展示随字典自动扩展;
  • 子案专属弹窗(子案上传/子案挂载/子案解挂)退役。

六、验证

docs/temp/stage11_contract.py(自建自清):方案B放行/无权仍拒;SUB_PLAN创建400; 配套方案上传→入库→挂载→Tab列表→解绑→仍在库;迁移前后存量12条子案的转换 (类型/挂载/计数/child_count);四值字典下发。

七、实施偏差与补充决策(2026-08-29 实施时确定)

  1. 密级保留而非归一PUBLIC:原附件shape约束强制security_level='PUBLIC'。 为不静默降密存量INTERNAL/SECRET子案,迁移同步放宽shape约束 (ck_doc_document_type_shape_v2,附件允许任意密级),存量子案密级原样保留; 附件读路径(详情/预览/下载)增加密级前置(任何角色含ADMIN密级不足即拒, 拒绝码SECURITY_LEVEL_FORBIDDEN,与主案口径一致)。新建附件仍默认PUBLIC (上传不含securityLevel字段)。
  2. 类型转换置空父/根/分类:附件shape要求parent/root/category为NULL, 迁移在补齐挂载关系之后置空三组字段(挂载关系承载原父子关联)。
  3. 同名消歧经临时表:UPDATE自联派生表触发MySQL 1093,候选id先落临时表再JOIN。
  4. 挂载顺序调整:先补挂载(需parent_document_id)后转类型,与初稿顺序相反。
  5. mount弹窗配套方案Tab为软排序(preferredType:配套方案居前、其余类型排后, 不做类型过滤);其余三类Tab维持原类型预过滤。