交开投数智建管平台

主题

公文管理 · 详细设计 ​

文档版本：1.00 ｜ 最近核对日期：2026-09-14 所属模块：公文管理 ｜ 后端接口前缀 /business/documentMatter ｜ 后端 DocumentMatterController 覆盖：开投下发公文、对外联系单、内部协同、会议通知。

本版本针对原有“4 个类型页面 × 4 个关系/归档 Tab”的过度拆分进行收敛：菜单只保留一个公文台账入口和一个公文待办入口，台账页内部以四个事项类型 Tab 切换，每个类型只有一张统一列表；“我发起的 / 我收到的”改为列表内的范围筛选；归档不再作为产品功能、页面、接口或业务状态。

1. 入口与功能定位 ​

1.1 菜单结构 ​

动态菜单结构如下，菜单数据由 SYS_MENU 提供，前端不再把待办注册为固定路由：

菜单前端地址组件说明
公文管理-菜单目录现有父菜单
公文台账/business/document/matterbusiness/documentMatter/documentMatter公文管理唯一主入口，内部四个类型 Tab
公文待办/business/document/todobusiness/documentMatter/documentTodo公文管理下的跨类型待办入口

原四个类型地址 /business/document/officialDocument、externalContact、internalCollaboration、meetingNotice 保留为隐藏兼容地址，组件统一转入公文台账并定位到对应类型，供历史书签和旧消息链接过渡使用。

1.2 功能边界 ​

本模块使用统一事项底座管理四类非项目绑定文书：

  • 开投下发公文：登记、发送、签收、办理回复；
  • 对外联系单：发送、回复跟踪、催办；
  • 内部协同：跨部门办理与文件传递；
  • 会议通知：发送、参会回执。

四类事项均不绑定项目，不关联进度、质量、安全或 BIM 数据，也不接入审批工作流。事项完成后以“已完成”作为终态，不再出现“待归档、已归档、发文归档、收文归档”等产品概念。数据库中的历史归档列只作为兼容遗留字段保留，当前代码不读取、不写入。

2. 页面结构 ​

2.1 公文台账 ​

台账页由“查询条件卡片 + 列表卡片”组成，类型 Tab 放在列表卡片头部：

  • 类型 Tab 固定为“开投下发公文、对外联系单、内部协同、会议通知”；
  • 每个类型 Tab 只渲染一张列表，不再嵌套“我发起的 / 我收到的 / 发文归档 / 收文归档”；
  • 查询范围提供“全部事项、我发起的、我收到的”，默认“全部事项”；
  • “全部事项”由后端按当前用户是发起人或收件人合并查询，分页在数据库侧完成；
  • 行内根据当前用户关系显示查看、签收、回复、编辑草稿、催办和复制等操作；
  • 列表不显示归档状态，不提供归档筛选、归档按钮或归档列。

2.2 查询条件卡片规范 ​

四类事项共用同一个列表组件，因此四个类型 Tab 的查询卡片保持一致：

  • 查询卡片标题固定为“筛选条件”，首行可显示 DOCUMENT FILTERS 作为辅助标识；
  • 查询卡片只承载“范围、关键词、状态”三个查询条件；
  • “查询、重置”放在查询卡片右上角或表单操作区；
  • 新增、导出等业务操作放在列表卡片工具栏，不放入查询条件卡片；
  • 表单项使用统一间距和控件宽度，小屏幕自动换行；
  • 查询条件不以卡片高度变化、隐式 Tab 或归档状态影响列表可见性。

2.3 公文待办 ​

/business/document/todo 是菜单下的独立页面，聚合当前用户四类事项的收件记录，保留“待我处理 / 已处理”两个轻量状态 Tab。页面按用户拥有的类型权限查询，行内支持直接签收和回复；签收后如果需要办理，自动进入回复编辑。待办页面不包含归档筛选。

2.4 新建、编辑与详情 ​

  • 新建/编辑以对话框承载，先多选部门，再从已选部门中多选人员；
  • 回显格式固定为“部门 / 姓名”，每个收件人独立保存“办理 / 阅知”；
  • “办理要求”全局开关只作为新选择人员的默认值，并提供“应用到全部”；
  • 详情展示正文、类型扩展字段、附件、收件人处理进度、回复/回执、催办记录和操作轨迹；
  • 发起人可以查看该事项完整历史，收件人仅返回与本人相关的历史记录；
  • 发送确认在表单底部展开，不再叠加第二层确认弹窗；系统提醒始终发送，邮件提醒按需勾选。

2.5 类型字段与列表重点列 ​

类型新建字段列表重点列收件人操作
开投下发公文文号、文种、标题、发文日期、紧急程度、密级、正文、附件、办理/阅知文号、标题、文种、发文日期、签收/回复进度、关系、状态、发送时间签收、办理回复和附件
对外联系单编号、联系单类型、标题、发送日期、回复期限、内容、附件编号、标题、联系单类型、回复期限、签收/回复进度、逾期人数、关系、状态签收、回复
内部协同协同编号、主题、协同类型、办理期限、内容、附件编号、主题、协同类型、发起人、办理期限、办理进度、关系、状态签收、办理回复
会议通知会议编号、主题、会议类型、时间、地点、正文、附件、回执截止时间编号、主题、会议时间、地点、发起人、回执统计、关系、状态签收、确认参会/请假

编号均为“下拉可选 + 可输入”，候选取发起人本人同类型已有人工编号，系统自动生成的长数字编号不进入候选；留空时发送自动生成，发送时仍校验同类型唯一。开投下发公文的文种下拉提供 15 类标准文种，并允许自定义输入兼容历史数据。

3. 核心设计 ​

3.1 数据模型 ​

表职责
document_matter事项主表：类型、编号、标题、正文、发起人、发送时间、办理期限、完成状态、附件和类型扩展字段
document_matter_recipient收件人表：一人一条，保存发送时部门/人员快照、是否需回复、签收和处理状态
document_matter_response回复、回执、办理说明和附件，保留提交人与时间
document_matter_reminder催办内容、催办对象、操作者和时间
document_matter_log创建、编辑、发送、签收、回复、催办等只追加操作轨迹

matter_type 取值为 official_document、external_contact、internal_collaboration、meeting_notice。仅属于单个类型且无需检索的轻量字段可放入扩展 JSON；用于查询、排序或规则判断的字段必须使用独立列。

3.1.1 持久化字段 ​

字段快照、历史兼容列和核验日期见数据库设计。

3.2 收件人选择与去重 ​

  1. 部门只用于限定人员筛选范围，不会自动展开人员，也不会自动通知部门负责人；
  2. 发送对象必须为具体人员，收件记录保存“部门 ID/名称快照 + 人员 ID/名称快照”；
  3. 同一事项的同一人员只生成一条收件记录，防止重复发送和重复统计；
  4. 同一人员从多个部门入口被选择时，以最后一次明确选择的部门作为发送部门快照；
  5. 详情、选择回显和进度统计均显示“部门 / 姓名”；
  6. 每人独立保存“办理 / 阅知”（NEED_RESPONSE 一人一条），全局开关仅提供默认值。

3.3 状态与关系范围 ​

事项主状态统一为：

text
草稿 draft
  -> 待签收 pending_sign
  -> 办理中 processing / 部分完成 partially_completed
  -> 已完成 completed

仅阅知人员签收后即完成；需办理人员提交回复或会议回执后完成。所有必需办理人完成后，事项主状态直接变为 completed。历史数据中的 ready_to_archive、archived 在 API 返回和导出时统一映射为“已完成”，不再向用户暴露旧概念。

3.3.1 2026-09-14 DM8 开发库验证补充 ​

本批次通过项目 dcp-dm8-dev MCP 回读并修正开发库事项状态检查约束：实际约束为 CK_DOCUMENT_MATTER_STATUS_V2，允许 draft、pending_sign、processing、partially_completed、completed、ready_to_archive、archived。开投下发公文事项 2099032320113221633 已真实完成发送、收件人签收和办理回复，主状态为 completed；历史归档状态仍只作兼容读取，不恢复归档产品概念，也未删除测试数据。

台账 scope 取值：

值语义
all当前用户作为发起人或收件人的事项
created当前用户发起的事项
received当前用户收到的事项

后端按当前登录用户计算关系范围，前端传入的 scope 只决定查询分支，不作为越权依据。事项原文在发送后不可编辑；需要再次发起时使用“复制”生成新的草稿。

3.4 发送通知 ​

  1. 四类事项发送均必须发起 SSE 实时推送，系统提醒始终生效，后端不接收“关闭 SSE”参数；
  2. 发送确认融合在表单底部，显示收件人数、发送后正文不可修改提示和可选的邮件提醒；
  3. 发送、收件人快照和操作日志在同一事务完成，事务提交后再持久化消息并推送；
  4. 消息 source/category 固定为 document，消息链接统一为 /business/document/matter?matterType=<type>&matterId=<id>；
  5. SSE 只包含类型、编号/标题、发起人、发送时间、办理期限和统一台账入口，正文与附件不直接放入载荷；
  6. 邮件保留类型重点字段和附件预签名地址，单个消息或邮件失败只记录告警，不回滚已发送事项。

4. 权限与接口 ​

4.1 权限 ​

  • 权限码固定为三段式 business:<资源>:<动作>；
  • 四类事项分别使用独立资源名：
    • official_document → business:officialDocument
    • external_contact → business:externalContact
    • internal_collaboration → business:internalCollaboration
    • meeting_notice → business:meetingNotice
  • 后端控制器逐类型校验权限和事项类型，服务层再次按当前用户校验数据范围；
  • 台账 mine 查询允许具备该类型 list 或 query 权限的用户访问；签收、回复、催办等动作仍按原有动作权限和当前用户身份校验。

4.2 接口 ​

方法路径作用
GET/business/documentMatter/{type}/list兼容接口：查询当前用户发起的分页列表
GET/business/documentMatter/{type}/mine台账统一列表，支持 scope=all|created|received
GET/business/documentMatter/{type}/my-received兼容接口：查询当前用户收到的分页列表，待办继续使用
GET/business/homepage/todo-summary登录级首页聚合：当前用户公文待签收/待回复计数与按发送时间倒序封顶 5 条的明细，并组装规划会商待填意见计数与明细（口径见规划详细设计 2.6）；不挂菜单权限，公文口径与公文待办页行内判定一致
GET/business/documentMatter/{type}/{matterId}查询详情，后端按发起人或收件人过滤历史
POST/business/documentMatter/{type}/draft保存新草稿
PUT/business/documentMatter/{type}/draft/{matterId}编辑草稿
POST/business/documentMatter/{type}/send发送事项并写入收件人快照
POST/business/documentMatter/{type}/{matterId}/sign当前收件人签收
POST/business/documentMatter/{type}/{matterId}/reply当前收件人提交回复/回执
POST/business/documentMatter/{type}/{matterId}/remind发起人催办未完成收件人
POST/business/documentMatter/{type}/export按台账当前范围导出元数据

接口中不再提供归档动作、归档字段或归档状态筛选。旧数据库列和旧状态只在兼容读取时处理，不形成新的业务契约。

5. 操作说明 ​

操作路径和步骤见操作手册。

6. 验收要点 ​

  1. 菜单从“公文管理”下进入“公文台账”和“公文待办”，待办不再依赖前端固定路由；
  2. 公文台账只有四个类型 Tab，每个 Tab 只有一张统一列表；范围筛选能正确切换全部、我发起和我收到；
  3. 四类事项共用的查询条件卡片只显示范围、关键词、状态，查询/重置位置稳定；新增和导出只出现在列表工具栏；
  4. 四类事项均能完成创建、先选部门后选人员、发送、签收、办理/回执、进度查看、催办和复制；
  5. 状态按草稿、待签收、办理中/部分完成、已完成展示，不出现归档列、归档筛选、归档按钮或归档 Tab；
  6. 收件人逐人办理/阅知开关生效：阅知人员签收即完成、不计入待回复与催办对象；
  7. 发起人与收件人的数据权限隔离正确，不能读取他人事项或他人回复历史；
  8. 公文待办的待处理/已处理分组、行内签收与回复、本人期限超期提示正确；
  9. 邮件提醒按需发送，公文消息可从历史消息进入统一台账并自动切换类型、打开对应详情；
  10. 历史数据库归档列未执行删除性 DDL，历史旧状态返回页面时显示为“已完成”。