فهرس الوثائق

毕业与退住

本文档说明宿舍管理系统中毕业退住如何作为六张表联动的事务执行,并给出批量退住、毕业生数据封存政策、离校未退质量规则与住宿画像归档的完整做法。

  • 退住需六张表在同一事务内联动,不可出现半更新状态
  • 批量退住按学院年级筛选一次落库,失败记录明确列出不静默吞掉
  • 离校在住质量规则可防止幽灵床位与门禁安全隐患
  • 毕业生数据封存可由学校选关闭、只读档案或完整保留三种政策
  • 退住后数据继续用于统计、审计追溯与下一届政策反哺

明·如归 · 宿舍管理白皮书 | 第五篇 旅程篇

六月的最后一天,李洋把最后一箱行李搬出 512。陈昊站在门口看着他、递过来一瓶矿泉水——四年前那个 22:00 就熄灯的年轻人已经变成会熬夜陪室友改简历的人了。李洋把钥匙放在窗台上、拍了一张空房间的照片——这是他在这套系统里留下的最后一条动作

"离开"在系统里长这样——退住的执行、数据的封存、画像的完结、毕业之后系统还能做什么。展开讲七件事。

28.1 退住不是"清空房间",是六张表的一次联动

李洋在移动端提交退住申请、或者辅导员批量给整个毕业班发起退住。系统内部六张表同时联动

  • 住宿记录:状态从"在住"切"已退住";这条记录永久保留,带原始分配时刻与退住时刻;
  • 床位:状态从"占用"切"空闲";床位归属保留(还挂在 512 3 号床上);
  • 房间容量:已住人数从 4/4 变 3/4;
  • 考勤日历:从退住次日起,李洋不再进入考勤范围——不删除他以前的记录、不新增他的记录
  • 设备权限:门禁卡自动作废、下次不能刷开 3 栋的门;这一步走设备连接器;
  • 画像:住宿画像的"当前在住"字段清空、"历史住宿"字段追加一条完整记录。

这六张表在同一个事务里改齐——不会出现"住宿退了、门禁还能刷"、"床位空了、考勤还在算他"这种半更新状态。这套系统对"退住"的严谨度跟"入住"一样:一次入住登记错了可以补、一次退住做错了可能引发安全事故(毕业了两年的学生还能刷开宿舍门)。

28.2 批量退住:整建制毕业的一次操作

每年 6 月底,学校要给两三千名毕业生一次性退住。这套系统对这个动作有专门的路径

  • 管理员在管理端按"批次 / 学院 / 年级 / 专业"筛选出目标学生名单;
  • 选一个执行日期("2029-06-30");
  • 点击"批量退住"——系统按筛选结果生成 N 条退住记录,一次落库;
  • 每条记录都带来源("批量操作")、操作者、时刻、依据;
  • 执行结果输出:成功多少、跳过多少(已经不在住的)、失败多少(并发或其他原因)。

关键的一条失败或跳过的记录会明确列出,不静默吞掉。这样管理员能立刻看到"哦,这 8 个人原来上个月已经办了退住",不会以为"操作失败"。

批量退住不是"删掉一批人"——是把一批人从"在住"切到"已退住",所有历史记录完整保留。

28.3 数据封存:毕业生能看到什么、看不到什么

李洋毕业五年后想查自己当年住哪间房、和谁住——这件事系统对毕业生是否开放,由学校定。三种典型政策:

  • 完全关闭:毕业即注销账号;他查不到任何东西。这条路最简单、也最浪费——五年积累的学生生活数据就此与本人断联;
  • 只读个人档案:毕业生可以登录、只能看自己的住宿记录、考勤、检查、报修、请假——看不到别人的信息、看不到统计报表。这一条是最推荐的,因为它把系统作为"你自己大学四年的完整住宿档案"留下来;
  • 完整保留:毕业生账号能进系统、能看到自己所有相关记录 + 同学的名字(不看到同学的当前状态)。

这套系统对三种政策都支持——权限模型和"角色 → 用户组 → 成员"挂接足够灵活,把"毕业生"设成一个只读角色即可。具体选哪种,是学校自己的政策决定

28.4 住宿画像的最后一笔:四年完整档案

李洋毕业后,他的住宿画像在系统里最终形态是:

  • 基础信息:学院、专业、班级、入学与毕业日期;
  • 住宿变更:四年里的所有分配 / 调宿 / 换房记录,每一条带原因与操作者;
  • 考勤汇总:四年里的在寝 / 迟归 / 未归 / 请假总天数与关键节点;
  • 检查与评级:宿舍卫生检查的每学年平均分、Top / Bottom 记录;
  • 报修汇总:他提交过的报修工单数与主要类别;
  • 宿舍活动:如果学校配了活动数据,可以挂进来。

这份画像是他大学四年"生活"这一维度最完整的档案。学校可以把它做成"离校报告"的一部分、可以在他自己申请时导出成 PDF 给他——这是这套系统对毕业生最有温度的一件事

28.5 离校未退:那条最容易被忽略的质量规则

毕业季最常见的一件事是"学籍毕业了但床位还挂在'在住'状态"。这可能有两种原因:

  • 学生延期毕业,实际还在住——学籍状态切"离校"是错的;
  • 学生已经离校、退住流程忘了办——数据滞后。

这套系统的五条质量规则里,"离校在住"就是专门查这一件事:定期扫"学籍状态 = 毕业 / 退学 / 休学 且 住宿状态 = 在住"的学生,落到问题工作台由管理员核实。

这一条规则的另一个名字叫"防止幽灵床位":一个学生已经毕业两年、床位还挂"在住"——下一届新生分房时这张床就被"看不见"占用了;一个学生已经退学、门禁卡还能刷开宿舍门——这是安全事故。这两件事都靠"离校在住"扫描 + 定期处理避免。

28.6 退住之后:数据还能被谁用

毕业生走了,他的数据在系统里继续做三件事:

  • 统计:某学院历年床位周转、某楼栋入住曲线、某年级异常趋势——这些统计要包含历史毕业生,不然口径不完整
  • 审计:教育评估、专业认证、上级检查——要能追溯"这届毕业生四年前是怎么住的"
  • 反哺:下一届的分配政策、宿舍翻新计划、检查评分标准——都是从往届数据里长出来的

这三件事的正当性支撑"数据不能因为本人毕业就删掉"这条纪律。学生离校不等于学校对他的数据控制变成非法——只要还在"办学必需"的用途范围内、就属于合理处理。这一条在《个人信息保护法》"履行法定职责"的合法性基础里有对应条款。

28.7 给学校的一件事

毕业季前一个月,问你的信息中心或宿管中心:"我们上一届毕业生里,有多少人的住宿状态到今天还挂在'在住'?"

如果答案是"没统计过"——你的质量规则里"离校在住"没在跑。开起来。

如果答案是"20 个人、我们都联系过、他们同意了"——那这些人可能是"学位延期"或"论文二辩临时留宿",让他们继续"在住"是对的;系统里给这条状态加一个可解释的字段("延毕留宿")就完美了。

如果答案是"100 多个人、也没人管"——这就是典型的"毕业即失控"门禁卡没作废、床位被幽灵占用、审计来了说不清。这一件事不需要重新分房、只需要一次批量操作就能清理——但学校要记得做

李洋把钥匙放在窗台上、走出 3 栋。系统没有弹出什么庆祝动画,也没给他发一句"祝前程似锦"——它只是安安静静在系统里把那条住宿记录从"在住"切到了"已退住",从此不再动。这份安静就是这套系统对毕业生能给的最好的告别:你在的时候我认真记,你走了我不打扰,你五年后想回来查,我随时开门