一、权限的三个来源来源含义决定什么数据拥有人该数据的权威管理者该数据的最高权限级别 3机器拥有人本机 PC 的责任人本机操作的权限上限登录人当前输入密码的人本机软件权限的实际持有者核心公式本机软件权限 登录人权限 ∩ 机器拥有人权限取交集即较低者。二、数据类别与拥有人每类数据有独立的拥有人不混用。数据类别拥有人说明PC 设备资产IT 人员某台 PC 的责任人企业通讯录HR人事管理唯一拥有人消息/通知系统系统生成用户只读用户自己的资料用户自己有限字段可编辑配置/字典管理员0 号系统级日志/审计系统只追加不可改关键不同数据类别拥有人不同。IT 拥有 PC 资产HR 拥有通讯录互不越界。三、权限级别级别名称含义0无不可见1读取可查看2建议修改可提交修改建议拥有人确认后生效3完全控制可直接修改即拥有人建议修改是中间态非拥有人可以提意见但最终发起人始终是拥有人。四、权限计算通用公式有效权限(用户 U, 数据 R, 机器 M) min( base(U, R), -- 登录人对数据的权限 base(owner(M), R) -- 机器拥有人对数据的权限 )其中base(U, R)条件结果U 是 R 的拥有人3U 有显式授权授权级别默认按类别PC0通讯录1例子登录人机器拥有人数据结果张三IT张三自己机器张三负责的 PC3 完全控制李四HR张三IT 的机器通讯录min(3, ?)王五普通张三IT 的机器张三负责的 PCmin(0, 3) 0第三行的含义王五在张三的机器上对张三负责的 PC 没有权限王五不是那些 PC 的拥有人。第二行的问题机器拥有人张三对通讯录是什么权限如果张三只有读取1那李四在这台机器上只能读通讯录。这可能不合理——HR 在任何机器上都该能管通讯录。五、机器拥有人约束的适用范围这里需要你决策机器拥有人约束适用于哪些数据方案 A适用于所有数据有效权限 min(登录人权限, 机器拥有人权限)问题HR 在 IT 的机器上无法管理通讯录因为 IT 对通讯录没权限。方案 B只适用于 PC 资产PC 资产min(登录人, 机器拥有人) 其他数据只看登录人理由机器拥有人是 PC 的责任人他的权限约束只应作用于 PC 资产。通讯录归 HR与 IT 无关。方案 C按数据类别分别定义每类数据定义“是否受机器拥有人约束”数据类别受机器拥有人约束PC 资产是通讯录否其他按需建议方案 C最灵活语义最清晰。六、权限如何标识1. 数据拥有人每类数据的拥有人用独立表表达-- PC 设备的拥有人CREATETABLEpc_responsibles(pc_idINTEGERPRIMARYKEY,responsible_idINTEGERNOTNULL,assigned_atINTEGERNOTNULL,assigned_byINTEGER);-- 通讯录的拥有人全局单行CREATETABLEcontacts_owner(idINTEGERPRIMARYKEYCHECK(id1),owner_idINTEGERNOTNULL,assigned_atINTEGERNOTNULL);-- 通用的数据拥有人如需要CREATETABLEdata_owners(resource_typeTEXTNOTNULL,resource_idINTEGERNOTNULL,owner_idINTEGERNOTNULL,assigned_atINTEGERNOTNULL,PRIMARYKEY(resource_type,resource_id));2. 显式授权非拥有人获得权限用权限表CREATETABLEpermissions(user_idINTEGERNOTNULL,resource_typeTEXTNOTNULL,-- pc / contactsresource_idINTEGER,-- NULL 表示全局levelINTEGERNOTNULL,-- 1 / 2 / 3granted_atINTEGERNOTNULL,granted_byINTEGER,PRIMARYKEY(user_id,resource_type,resource_id));CREATEINDEXidx_perm_userONpermissions(user_id,resource_type);3. 权限解析函数/// 计算用户对某数据的有效权限fneffective_level(user_id:i64,machine_owner_id:i64,resource_type:str,resource_id:Optioni64,)-i32{letuser_levelbase_level(user_id,resource_type,resource_id);letmachine_levelbase_level(machine_owner_id,resource_type,resource_id);user_level.min(machine_level)}/// 基础权限不考虑机器约束fnbase_level(user_id:i64,resource_type:str,resource_id:Optioni64,)-i32{// 1. 是拥有人ifis_owner(user_id,resource_type,resource_id){return3;}// 2. 显式授权ifletSome(level)explicit_permission(user_id,resource_type,resource_id){returnlevel;}// 3. 默认default_level(resource_type)}七、权限的存储方式方案 1级别数字enumLevel{None0,Read1,Suggest2,Full3,}存INTEGER简单直接。方案 2位标志constREAD:u80b001;constSUGGEST:u80b010;constFULL:u80b100;问题建议修改隐含读取完全控制隐含建议 读取。位标志表达不了“隐含”。方案 3级别 权限名{level:2,actions:[read,suggest]}冗余不如直接存级别。建议方案 1级别数字最小语义隐含关系在代码里处理。八、数据类别如何标识方案 A字符串常量pubconstRES_PC:strpc;pubconstRES_CONTACTS:strcontacts;方案 B枚举#[derive(Debug, Clone, Copy, PartialEq)]pubenumResourceType{Pc,Contacts,Messages,UserProfile,Config,}建议方案 B类型安全编译期检查。九、权限变更的触发场景动作设备转移责任人更新pc_responsibles写历史授权 IT 管理某 PC插入permissions授予 HR 通讯录管理权更新contacts_owner用户离职撤销其所有permissions部门调整按新部门重新计算默认权限十、离线时的权限缓存内容-- 本机登录过的用户及其权限CREATETABLElocal_users(user_idINTEGERPRIMARYKEY,nameTEXTNOTNULLUNIQUE,passwordTEXTNOTNULL,permissions_jsonTEXTNOTNULL,-- 该用户的权限快照...);-- 本机拥有人CREATETABLElocal_machine(idINTEGERPRIMARYKEYCHECK(id1),responsible_idINTEGERNOTNULL,synced_atINTEGERNOTNULL);离线权限计算同在线公式只是数据来自本地缓存有效权限 min( 登录人缓存权限, 机器拥有人缓存权限 )缓存时效每次在线登录刷新local_users和local_machine离线时用最后一次的快照快照过期如 7 天→ 提示重新在线登录十一、边界与异常场景处理机器拥有人未登记视为无约束只用登录人权限登录人 机器拥有人取自己的权限不重复 min数据拥有人离职需先移交否则权限悬空权限冲突取 min宁严勿松跨类别访问按各类别分别计算十二、与其他设计的关系模块关系pc_responsiblesPC 数据的拥有人表pc_suggestions级别 2 的操作载体pc_assets_history级别 3 的修改留痕it_messages推送给机器拥有人客户端缓存权限的离线快照十三、需要你决策的点机器拥有人约束的适用范围方案 A所有数据/ B仅 PC/ C按类别定义我倾向C。通讯录的默认权限所有登录用户默认级别 1读取对吗权限级别存储级别数字0-3对吗数据类别标识枚举对吗权限变更留痕是否要permissions_history表我倾向要与资产历史一致。离线权限快照有效期7 天还是永久我倾向7 天过期要求在线刷新。data_owners通用表是否需要还是每类数据独立建表pc_responsibles/contacts_owner我倾向独立建表语义清晰。permissions表是否需要如果绝大多数权限能通过拥有人推导显式授权是少数是否需要独立表我倾向要用于跨部门、临时授权等。确认后我把权限表、解析函数、离线缓存的完整代码写出来。