中型项目权限设计-编辑管理员-图示2
中型项目权限设计-编辑角色-图示3
相对于最小权限设计，你可以理解为菜单 账号的拆分，并且在菜单的基础上，扩展了操作权限；也通过角色的区分，扩展了数据权限，此时的权限=菜单权限 操作权限 数据权限。
相对于上一个会复杂很多，为什么我前面会说建议按照产品体系，再去做这一套中型的权限系统？
一方面，众所周知是由于开发工作量以及难度，对应报价会高；另一方面是，这个的复杂度也提高了他使用难度，如果是没有这种业务情况需求(类似于多门店、或者是负责角色不同)，就不建议用了。
最后也是最重要一个方面，针对不可持续性产品的说明：不断向软件增加功能，是不可持续的。增加复杂性意味着遗留代码越来越沉重，导致产品维护成本越来越高，而且也越来越难以灵活应对市场变化；这个道理我想不仅仅适用于用户前端，对管理后台也同样适用。
对应的需求梳理如下：
大型项目的权限，最大的一个变化，是有部门组织架构，不同部门的人使用系统，即将管理员管理拆解为部门管理 成员管理，但是又不仅仅于此。
在一个接入审批的系统、或者CRM中，往往数据是相对独立的，可以按照部门组织架构数，去区分数据的权限。如下图所示：
