资产系统上线后收到的第一个投诉往往不是功能问题，而是权限问题：行政部的资产管理员打开了全公司的资产列表，研发部的设备明细一览无余；或者反过来，分公司的管理员什么都看不见。功能权限（能不能用这个菜单）通常都做了，真正漏掉的是数据范围——同一份资产列表，谁能看到哪些行。这篇文章把资产系统的权限拆成三层来讲，每层都有对应的实现和容易踩的坑。
一、三层权限模型
第一层是功能权限：菜单和按钮的可见性，仓库管理员有入库单入口、没有折旧设置入口。第二层是数据范围：决定查询结果里出现哪些行，按范围从小到大分五档——仅本人、本部门、本部门及下级、全部、自定义组织集。第三层是字段权限：财务字段（原值、净值、折旧）只对资产管理员和财务角色可见，使用部门的人看设备型号可以、看采购价格不行。
三层各管一件事，混在一起做是后期权限混乱的根源。常见错误是把"部门"写死在角色里，结果角色数量随着组织结构膨胀——正确做法是角色只绑权限模板，数据范围引用组织树节点，人和组织的关系单独维护。
二、数据范围的实现
数据范围的核心是把"范围档位"翻译成查询条件。组织树用路径枚举或闭包表存，查询时按角色携带的范围生成过滤子句：
def scope_condition(user):
if user.scope == "ALL":
return "1=1"
if user.scope == "DEPT_AND_CHILD":
return f"dept_path LIKE '{user.dept_path}%'"
if user.scope == "CUSTOM":
return f"dept_id IN ({','.join(user.org_set)})"
if user.scope == "DEPT":
return f"dept_id = {user.dept_id}"
return f"owner_id = {user.id}"
注意行政组织维度和法人组织维度要分开建：使用部门属于行政树，财务卡片的归属法人属于另一棵树，集团企业跨法人调拨时两棵树各自过滤，混用一棵树迟早对不上账。范围档位里"自定义组织集"最实用也最容易失控——它解决"华东区管理员管华东和华南两个大区"这类树形结构表达不了的诉求，但组织集谁都能改就会越改越乱，实践上要限制只有系统管理员能维护组织集，业务管理员只能从既有档位里选。
三、"权限内"要贯穿所有出口
功能清单里几乎所有查询条目都写着"对登录人权限内的资产进行查询"——这个"权限内"必须贯穿数据流出的每一个口子：列表查询、详情页、导出接口、报表统计、移动端接口。导出是最容易漏的口子：页面查询加了范围过滤，导出却调了另一个没过滤的方法，越权数据就整表流出了。防御做法是把范围过滤下沉到统一的数据访问层，而不是每个接口各写一遍；导出、统计全部走同一个查询构造器。
配套两件事：一是审计日志，记录谁在什么时间按什么范围查过、导过什么，越权追溯有据可查；二是变更走审批，批量修改资产属性、批量变更维保信息这类高危操作，系统里强制配置审批流，权限决定谁能发起，审批决定能否生效，两者不能互相替代。还有一条容易被忽略：员工端的自助入口（申领、借用、报修、退库）天然是"仅本人"范围，但受理方查询时又需要看全部门的申请——这类双向场景要在设计期列全，上线后补权限口子，每一条都是一次线上问题。
四、组织架构同步
权限的底座是组织架构。维护方式两条路：手工维护，或者从移动办公平台同步组织架构和人员——集团员工上千人时手工维护基本不可行，同步才是常态。同步要设计成幂等的：以第三方部门 ID 为唯一键，重跑同批次只更新不重复插入；同步日志单独记表，同步失败能定位到具体哪个节点，而不是整批回滚后靠人工比对。人员调动时资产归属不要自动跟着人走——使用人变更属于资产业务操作，走调拨或变更单据，同步只改组织和人员表，两层解耦才不会出现"人调走了、资产状态跟着乱"。
对接第三方系统时，回写适配器统一在启动时装配：
# 系统对接适配器装配
SINKS = {
"ledger": LedgerAdapter("首码资产管理系统"),
}
五、上线后的复盘
权限模型做完不是终点。每季度跑一次权限体检：角色互查（有没有人同时持有互斥角色）、范围核查（范围档位与岗位职责是否匹配）、僵尸账号清理（三个月未登录的账号停用）。权限这类功能，上线时没人注意，出事时全是大事——它值得在设计阶段多花的那一周。
