宁语之溪 - 高校业务系统
type: channel
link: https://nyzx.de/category/university-business-system/
items: 学校业务系统中的权限和角色配置
items: 业务表单、审批流程和工作台是怎么串起来的
items: 低代码平台之外，我还做了哪些二次开发

学校业务系统中的权限和角色配置
type: item
date: 2025-11-15T16:36:00+08:00
description: 学校业务系统中的权限配置，通常不只是“能不能登录”。用户登录之后，还需要确定能看到哪些菜单、能访问哪些数据、能执行哪些操作，以及当前状态下是否允许继续操作。低代码平台可以提供用户、角色、菜单和权限等基础能力，但业务系统的权限边界仍然需要结合实际场景设计。用户、角色和权限不是一回事用户是具体使用系统的人，角色是对一类职责的抽象，权限则描述允许执行的操作或访问的资源。用户 -> 绑定角色 -> 获得菜单和功能权限 -> 叠加数据范围 -> 执行业务操作这样做可以避免把每个用户的权限单独配置一遍。用户岗位或职责变化时，调整角色关系通常比逐项修改权限更容易维护。但角色也不能简单按照部门名称堆出来。一个角色应该对应相对清晰的业务职责，否则角色数量会不断增加，权限边界也会变得难以理解。菜单权限不等于数据权限用户能看到某个菜单，不代表可以访问菜单下的所有数据；用户可以打开某个页面，也不代表可以执行新增、编辑、删除和导出等全部操作。权限至少可以分成几个层次：菜单或页面访问权限；按钮和操作权限；数据范围权限；字段查看或编辑权限；流程节点和状态权限。例如，某个角色可以查看本部门数据，但不能查看其他部门；可以编辑草稿，却不能修改已经审核通过的内容；可以发起流程，但不能审批自己的申请。这些是通用权限模型，不对应内部系统的具体角色和数据范围。权限要和业务状态配合权限并不是静态的。即使用户拥有编辑权限，记录进入审核状态后，也可能暂时不能修改；退回后可以重新编辑；完成后又恢复只读。角色权限 + 记录当前状态 + 流程节点条件 -> 当前允许的操作因此，判断一个按钮是否显示或是否可用时，不能只看用户有没有某个角色，还要同时判断数据状态和业务规则。页面层可以隐藏不允许使用的按钮，但服务端仍然需要再次校验。否则用户可能通过直接请求接口绕过页面限制。低代码平台和代码扩展低代码平台通常能够配置角色、菜单、按钮和基础数据范围。对于简单的权限需求，这些能力已经足够。但遇到复杂规则时，可能需要通过表达式、接口或代码扩展完成。例如，数据范围取决于组织层级，审批权限取决于申请人与审核人的关系，或者某些字段只有在特定状态下才能编辑。标准权限配置 -> 验证是否覆盖业务规则 -> 配置可解决的部分 -> 扩展特殊数据范围或状态判断 -> 前后端一起验证本文只介绍通用处理方式，不展开内部扩展点、角色名称、接口和权限配置。权限测试不能只测一个账号权限配置完成后，至少需要准备不同角色和不同状态的数据进行验证。一个账号能够正常打开页面，只能说明其中一条路径可用，不能说明权限体系完整。测试时可以覆盖：普通用户和管理用户；不同组织或数据范围；草稿、待审核、退回和已完成状态；有权限和无权限的页面入口；直接访问接口和重复提交操作；角色变更后的权限刷新。如果只测试正常流程，越权、数据串看和状态绕过等问题可能会被遗漏。权限测试的重点，是确认用户既能做应该做的事，也不能做不应该做的事。权限配置的目标是可理解和可维护权限系统并不是配置项越多越安全。角色过多、权限命名不清、数据范围相互覆盖，都会增加维护难度。我会更关注几个问题：这个角色负责什么，能够访问哪些菜单，能够操作哪些状态，数据范围如何确定，角色变化后如何验证。只有这些问题能够说明白，权限配置才不只是平台里的几张表，而是可维护的业务规则。学校业务系统中的权限设计，最终仍然要回到业务职责。平台提供基础能力，代码可以补充特殊规则，但权限边界需要由需求理解、实现和测试共同确认。

业务表单、审批流程和工作台是怎么串起来的
type: item
date: 2025-10-18T16:24:00+08:00
description: 在学校业务系统中，一个需求通常不会只对应一个页面。表单负责收集数据，审批流程负责推动状态变化，工作台则负责让不同角色看到自己需要处理的事项。这几个部分如果分别配置，页面可能都能打开，但业务不一定能真正走通。真正的交付，需要把数据、角色、流程和入口串在一起。表单不只是输入框表单最直接的作用是收集数据，但字段设计还会影响后面的流程和权限。同一个字段可能有几种状态：创建时由申请人填写，审批时只能查看，退回后允许修改，完成后又变成只读。字段是否必填、谁可以编辑、什么条件下显示，都需要和业务过程一起考虑。业务对象 -> 字段定义 -> 填写与校验 -> 提交后状态变化 -> 审批和后续使用这是一种通用的表单设计思路，不对应内部业务系统的具体字段和配置。流程连接角色和状态审批流程的作用，不只是把一条数据从一个人送到另一个人。它还需要说明数据当前处于什么状态，以及下一步由谁处理。一个简化的流程可以表示为：草稿 -> 提交 待审核 -> 通过 -> 已完成 -> 退回 -> 待修改每个状态都可能对应不同的操作权限。待审核状态下，申请人可能只能查看；退回状态下，申请人可以修改并重新提交；已完成状态下，普通用户可能只能查看结果。平台通常能够提供流程节点和角色配置，但具体哪些角色参与、什么条件可以通过、退回后哪些字段可编辑，仍然需要结合业务需求判断。工作台是业务入口工作台把待办、已办、草稿和相关业务入口集中起来，让不同角色能够快速找到需要处理的内容。对于申请人，工作台可能重点展示自己的草稿、待修改和已提交记录；对于审核人，重点可能是待审核事项；对于管理人员，则可能需要查看统计和整体进度。因此，工作台的内容不是简单地把所有菜单放在一起，而是需要根据角色和数据状态筛选出合适的入口。当前用户 -> 角色与权限 -> 可见业务范围 -> 待办和历史记录 -> 进入表单或审批节点这是公开业务系统中常见的设计方式，项目内部的角色名称、菜单和数据范围不公开展开。三者之间必须保持一致表单、流程和工作台之间最容易出现的问题，是各自的配置没有同步。例如，表单提交后已经进入待审核状态，但工作台没有生成审核人的待办；或者流程退回后允许申请人修改，但表单仍然是只读；又或者工作台显示了一条记录，但打开后用户没有对应权限。排查这类问题时，可以沿着一条完整链路检查：表单是否收集到了正确数据；提交接口是否改变了正确状态；流程是否根据条件找到正确角色；工作台是否查询到了对应待办；点击入口后，权限和页面状态是否一致。这类检查是通用联调方法，不代表项目内部存在上述具体故障。平台配置和代码扩展低代码平台可以快速配置表单、流程和工作台，但业务系统往往会有一些特殊规则。例如，某个字段是否显示取决于前置选择，某个审批节点需要根据数据内容动态决定，或者提交前需要执行平台默认校验之外的逻辑。这些需求可能通过平台配置完成，也可能需要增加代码扩展。判断方式不是看到特殊需求就全部写代码，而是先确认平台能力能否覆盖，再选择配置、表达式、接口或代码扩展。平台标准能力 -> 能否覆盖需求 -> 配置解决 -> 配置不足时补充代码 -> 联调并验证状态闭环公开文章只介绍这种通用决策过程，不展开内部扩展点、接口和实现细节。业务闭环比单页完成更重要一个业务功能完成的标志，不只是表单页面能提交，也不只是审批节点能够保存。还需要确认从创建、提交、审核、退回、再次提交到完成的整个过程是否连贯，工作台入口是否和状态同步，权限是否始终符合角色边界。现在我会把这类需求看成一条业务闭环：表单负责表达数据，流程负责推动状态，工作台负责组织入口和任务。低代码平台可以提供很多基础能力，但真正的交付仍然需要把这些能力按照业务规则组合起来。

低代码平台之外，我还做了哪些二次开发
type: item
date: 2025-09-27T16:27:00+08:00
description: 进入学校业务系统开发之后，我接触到了一种和过去不太一样的开发方式：系统不一定从空白项目开始，很多业务能力已经由低代码平台提供，但实际交付仍然需要理解需求、配置平台、补充代码，并把功能真正落到业务流程里。这也是我想记录“低代码平台之外”的原因。低代码并不意味着不用理解代码，更不意味着所有需求都能通过拖拽直接完成。平台能力解决一部分问题低代码平台通常已经提供了一些基础能力，例如表单、数据模型、流程、权限和工作台。面对常见的业务需求，可以先利用这些能力搭建基础结构，再根据业务要求继续调整。业务需求 -> 识别平台已有能力 -> 配置表单和流程 -> 补充特殊业务逻辑 -> 联调和验证平台能力的价值在于减少重复建设，但前提是先理解需求。一个字段应该放在哪里、一个审批节点需要什么条件、不同角色能够看到哪些内容，都不能只靠平台默认配置决定。二次开发需要理解业务边界学校业务系统通常包含教务、行政和资源管理等场景。它们看起来都是表单和流程，实际却有不同的业务规则。同一个“提交”动作，在不同场景下可能意味着保存草稿、发起审批、提交审核或完成某个业务节点。页面上的字段也不只是展示内容，可能会影响后续流程、权限和数据状态。所以二次开发时，我会先确认几个问题：这个功能是平台标准能力，还是业务特殊需求；字段由谁填写、谁修改、谁查看；数据提交后会进入什么状态；流程节点之间有什么前置条件；平台配置能否覆盖需求，哪些部分需要代码扩展。这些问题本身不依赖具体平台，属于业务系统开发中的通用分析方法。内部表单、流程和权限配置不在公开文章中展开。代码扩展不是重新造平台当平台能力无法直接覆盖需求时，就需要补充代码。但补充代码并不等于把平台完全替换掉，也不等于从零独立开发整套系统。更实际的方式通常是保留平台提供的基础能力，再围绕特殊业务做扩展，例如：平台基础能力 + 业务字段和表单调整 + 特殊校验 + 接口或数据处理 + 页面交互补充 + 流程结果验证这也是我对“平台能力 + 代码扩展”模式的理解。平台负责通用部分，开发工作负责把特殊业务接起来，并处理平台默认行为无法覆盖的部分。具体使用了哪些前端组件、接口路径和内部扩展方式，涉及项目实现细节，本文不公开展开。公开文章只保留方法和职责边界。独立技术开发和平台二次开发可以同时存在在这个阶段，我的工作并不只有平台配置，也包含独立技术开发。两者的区别不在于有没有使用平台，而在于具体功能由什么方式完成、本人承担了哪一部分责任。平台二次开发通常是在已有能力上扩展：先了解平台的模型、流程和权限，再接入业务需求。独立技术开发则需要更多地负责具体功能的设计、实现和联调。但这两种工作也不是完全割裂的。一个独立开发的功能，可能仍然需要和平台中的表单、流程、权限或数据模型连接起来；一个平台配置功能，也可能需要通过代码解决特殊边界。因此，不能简单地把低代码项目概括成“只做配置”，也不能把其中的代码扩展写成“完全从零开发整套平台”。更准确的表达是：在平台能力基础上进行二次开发，同时完成部分独立技术开发。低代码仍然要求工程判断低代码平台能够加快业务应用建设，但它没有消除工程问题。需求是否理解准确、字段是否设计合理、流程是否覆盖异常情况、权限是否符合角色边界、上线后能否正常使用，这些仍然需要开发人员判断。配置完成 -> 功能联调 -> 正常流程验证 -> 异常和权限验证 -> 用户反馈整理 -> 调整并再次验证这套流程是业务系统交付中的通用做法，不对应某个内部项目的完整验收表。平台提供的是工具和能力，最终能不能落地，仍然取决于需求理解、实现方式和验证过程。目前我对这个阶段的认识是：低代码降低了重复建设的成本，但没有降低理解业务的要求。真正的二次开发，既要知道平台能做什么，也要知道平台默认行为在哪里不够用，以及应该用配置还是代码去补上这部分能力。