App开发模式概览：

原生App开发(native App)；

Android App开发(java 、Kotlin)

IOS App开发(Objective-C、Swift)

web App开发(Web App)；

   普通H5应用开发

   PWA应用开发

混合App开发（hybrid App）:

   微信-小程序

   快应用

   超级App-H5应用

跨平台开发框架(一套代码，多端运行)：

以基本单元拆分，以业务逻辑配置

一般可将每个对象的「增、删、改、查」各自作为一个基本的权限单元。打个比方，在「人员管理」中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些操作却是一体的。这些不能拆开的权限在「前端用户配置页面」中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有「人员管理」的查看权限，管理员有操作权限，则可将「增、删、改」三个基本权限单位合并为「操作」权限进行配置。

页面权限优先于操作和数据权限

权限管理，从IT层面来讲，便是在用户和权限（点）之间建立联系。在业界接受度较高的功能权限模型是——RBAC（Role-Based Access Control）模型，其基本理念是将「角色」这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

但在更复杂的业务系统中，仅仅引入“角色”,还无法完全满足权限控制的需求。下面，我将在基础RABC模型的基础上，谈谈我所接触到的某IT系统中的业务变种。

---

一、IT系统权限模型概览

这是加入“群组（用户组）”和“数据范围”两个对象之后的权限模型。

回顾一下之前权限模型的总结：

1、该IT系统的两套权限管理模式：用户——群组（项目X业务角色）——系统角色；用户——（系统角色X数据范围）

2、现有模型问题：IT框架问题：多套业务角色模板很鸡肋且不可靠；运维问题：系统角色混乱不清。

3、现有管理问题：从权限点到用户，中间经历了权限点到系统角色（关联1），系统角色到群组（关联2），群组到用户（关联3）三层关联。关联1由开发人员完成，关联2由运维人员维护N套模板，关联3由业务人员配置使用。层级复杂，三方人员各自为政。

4、IT优化：统一业务角色模板，项目属性维度的权限控制，以数据权限的思路控制；支持一线用户对业务角色的定制需求。

菜单，作为各个系统功能的直接入口，很大程度影响IT系统的易用性。尤其是对于样功能繁琐的系统，如何做好千人千面，针对性显示用户所需的功能，是一个值得深入分析的问题。

---

一、菜单规则概览

全量菜单树是如何一步步过滤裁剪的？

菜单的字段中包含过滤条件，最简单的便是不依靠任何外部条件的“是否发布”字段。但随着其他模对块菜单过滤的要求，不断新增个性化的字段。例如根据权限点、账号类型、项目相关属性来过滤。然后在菜单功能灰度发布或框架切换的过程中，持续性存在定制的菜单规则，可选择指定菜单对指定特征的项目。但是过滤得到的菜单并不是最终呈现的菜单。在此基础上，PM可以继续定制项目专属菜单，个人用户又可以在项目专属菜单上定制个人菜单。