RBAC 模型下，分级的权限有什么较好的设计方案吗

这个听起来像是 rbac 不能充分的表达角色？最根本的解决还是说该拆分为
运营总经理，运营经理，运营主管，运营员工
开发总经理，开发经理，开发主管，开发员工

然后开发总经理能增删改查剩下三个，开发经理增删改查剩下两个

如果实现不了的话，在 rbac 的基础上加上基于 attr 的校验？这里的 attr 是指需要校验属性是否相匹配啥的，比方说总经理增删改查只能影响同部门（ attr ）的员工？

@hxndg #1 对，增删改查只能影响同部门。然后上级到下级权限是一致的，只是作用范围的递减，到最底层的用户时，就只能修改自己了。想不到什么比较优雅的方案完成这个作用范围的划分

拆分权限粒度到每个接口, 或者说时每个‘接口模块’.
每个角色拥有特定的模块权限.

但是按照国情传统, 用不着多久就会出现有人想要跨级操作的场景了...例如总经历不想干活只想干秘书, 但是又不想把账号给下属经理, 然后下属经理来找你让你给他总经历的操作权限...
这时候给他指定一个特定角色, 权限在管理后台给他全手工勾选算了...

@wu67 #3 现在就是这样干的，但是存在情况，总经理有修改权限，员工也有修改权限，如果不限制员工权限的作用范围的话，就存在跨级操作了（员工可以修改总经理信息）

@bestmos 这样不是很合理吧.
个人觉得用户信息模块应该独立对待, 仅限本人和 admin 修改,
其他的业务信息模块才允许那些特殊跨级角色和正常角色修改.
因为从上面的描述来看, 总经理撂挑子撂的不正是‘业务’吗? 他没把自己职位(‘用户信息’)让出去, 所以用户信息这模块应该是特殊的才对.

@wu67 #5 你说的是合理的，我开始也是这个想法，但是不合现实。
比如有个场景：老年用户不会自己修改信息，所以由对接他的客户经理（上级）帮助修改。

这个场景像是需要做数据权限的控制吧？
我们之前做的类似方案一，不过是把一个“授权”的动作给显性化了，上级可以操作下级的数据就是下级“授权”上级操作我自己的数据，所以搞了一套授权系统，操作的时候需要根据授权表做额外判断
1. 授权系统本质上就是一套权限关系表加上几个脚本，开始是几个脚本定时同步组织架构，把上下级关系或者部门角色关系带来的一些默认的授权动作自动化跑到授权表里，后来有些时效性问题就改成事件监听组织架构变更了。
2. 另外因为公司恰好有一套接了审批流的授权系统，所以直接套了个壳做了个页面，给业务自己来做组织架构情况以外的各种授权规则

这样的好处就是兼容各种特殊情况，谁谁请假了要同事帮忙操作的，某个领导要同时兼着两个部门的活但组织架构又不调等等，发个授权申请审批后就能操作了。
坏处就是权限管理非常混乱，权限关系理不清，出了事情各种排查追溯到底咋回事，费时费力

内容描述不够完整，具体的需求就是控制某一级的角色只能操作自身和下级，而不能操作同级和上级角色。
比如 QQ 群的踢人，群主可以踢所有人，管理员只能踢普通群员而不能踢群主和其他管理员，普通群员则只能踢自己（退群）

数据权限可以在 RBAC 的基础上单列，RBAC 只需要实现到操作的权限
给所有人划分组织树和权限树，可以合并也可以拆分，在这实现上下级数据权限
拆分的好处是 张三可能是个基层管工，但是数据权限上拉，可以负责整个大部门的某个单项管理