回顾一下之前权限模型的总结：
1、该IT系统的两套权限管理模式：用户——群组（项目X业务角色）——系统角色；用户——（系统角色X数据范围）
2、现有模型问题：IT框架问题：多套业务角色模板很鸡肋且不可靠；运维问题：系统角色混乱不清。
3、现有管理问题：从权限点到用户，中间经历了权限点到系统角色（关联1），系统角色到群组（关联2），群组到用户（关联3）三层关联。关联1由开发人员完成，关联2由运维人员维护N套模板，关联3由业务人员配置使用。层级复杂，三方人员各自为政。
4、IT优化：统一业务角色模板，项目属性维度的权限控制，以数据权限的思路控制；支持一线用户对业务角色的定制需求。
（博客原文 https://blog.csdn.net/fuyuwei2015/article/details/44813639）
在IT行业中一般由需求分析师、产品经理、交互设计师、视觉设计师、架构设计师、数据架构师、数据分析师、开发工程师、测试工程师、配置管理员、项目经理、质量经理。下面让我们来说说他们分别的职责与在项目运行过程中的职责分布。本文主要以图片来展示，不在用长篇大论在赘述。
所处portal子产品，自从此前子产品经理和IT经理先后易任，团队便逐渐滞步，走向混乱。
此前，portal作为一个独立的子产品，有着全职的业务代表和IT经理，现在，portal并入了交付前台整个大组。 产品经理无暇顾及，IT经理角色缺失。产品经理投入不足，需求来源混乱，交付难以把控，BA方向不明。 幸而还能沿着前人规划的产品目标继续走下去。然而，当前人的路走到尽头时，该如何开启新的历程。
新的子产品经理虽然负责portal子产品，但其工作重心并不在此。整个交付前台都是他的责任田，分摊在portal上的精力实在是太少了。既并没有深入去了解portal现存的业务功能或设计逻辑，也没有时间来输出新的业务需求或决策关键要点。基本就靠BA“意会”领导的意思。而在需要子产品经理出面推动的关键节点，其也是一直缺席。作为BA，时刻处于皇上不急太监急的状态。方案的落地往往阻塞在各子产品之间的拍板决策上。大佬们花了百分之九十以上的时间彼此各种拉通对齐，却只花不到百分之十的时间给BA一句话需求。呈上不启下呀。感叹子产品经理在portal上花的时间实在是太少太少了。少有的所谓意见，也往往是对过往构架的质疑与否定
以基本单元拆分，以业务逻辑配置
一般可将每个对象的「增、删、改、查」各自作为一个基本的权限单元。打个比方，在「人员管理」中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。
但是在业务层面有些操作却是一体的。这些不能拆开的权限在「前端用户配置页面」中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有「人员管理」的查看权限，管理员有操作权限，则可将「增、删、改」三个基本权限单位合并为「操作」权限进行配置。
页面权限优先于操作和数据权限
权限管理，从IT层面来讲，便是在用户和权限（点）之间建立联系。在业界接受度较高的功能权限模型是——RBAC（Role-Based Access Control）模型，其基本理念是将「角色」这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。
但在更复杂的业务系统中，仅仅引入“角色”,还无法完全满足权限控制的需求。下面，我将在基础RABC模型的基础上，谈谈我所接触到的某IT系统中的业务变种。
这是加入“群组（用户组）”和“数据范围”两个对象之后的权限模型。
菜单，作为各个系统功能的直接入口，很大程度影响IT系统的易用性。尤其是对于样功能繁琐的系统，如何做好千人千面，针对性显示用户所需的功能，是一个值得深入分析的问题。
全量菜单树是如何一步步过滤裁剪的？
菜单的字段中包含过滤条件，最简单的便是不依靠任何外部条件的“是否发布”字段。但随着其他模对块菜单过滤的要求，不断新增个性化的字段。例如根据权限点、账号类型、项目相关属性来过滤。然后在菜单功能灰度发布或框架切换的过程中，持续性存在定制的菜单规则，可选择指定菜单对指定特征的项目。但是过滤得到的菜单并不是最终呈现的菜单。在此基础上，PM可以继续定制项目专属菜单，个人用户又可以在项目专属菜单上定制个人菜单。
