CMC 框架菜单、权限的重构(权限与菜单的分离，权限分类，避免升级时菜单的过度添加)

1、现阶段的实现，菜单与权限是一一对应的，在框架中的管理界面，如图1

2、设计结构如下：

3、如果需要新增加一个菜单/权限(例：移动端 – 任务 – 完成(完成任务)：/mobile/plan-tasks/finish/{ids}(mobile/plan-task/finish))，那么其操作步骤大致如下，第一步，在服务层面添加菜单，如图2

4、第二步，在租户层面下的服务中编辑/勾选菜单，如图3

5、第三步，在用户层面下的角色中编辑/勾选菜单，如图4

6、现阶段遇见的问题，如果 PCS 被 10 个租户所使用，而这 10 个租户下面，具有的角色中，其中有 3 个角色皆需要勾选新增加的菜单，那么，如果需要新增加一个菜单/权限，则需要执行操作次数：1 + 10 + (10 * 3) = 41。实际上，在一个云环境中，租户的数量是远不止 10 个的，且即使基于程序来实现菜单/权限的管理，也仅能够实现第一步与第二步，第三步是实现不了的(操作次数：1 + 10 + (10 * 3) – 1 – 10 = 30。)。因为：每一个租户下面的角色是不一致的，可完全由用户自定义。

7、针对现阶段所遇见的问题，解决方案大致规划为：菜单、权限的重构(权限与菜单的分离，权限分类)，即权限与菜单的分离，不再一一对应，这样的话，菜单的显示上的需要，可以减少菜单配置的数量，因为，菜单显示上，一般仅需要第一、二级就已足够。如图5

8、权限分类，将所有权限划分至不同的分类下，分类暂时决定也仅划分为四级，某分类下的权限，配置在程序中，这样的话，如果需要新增加一个菜单/权限(例：移动端 – 任务 – 完成(完成任务)：/mobile/plan-tasks/finish/{ids}(mobile/plan-task/finish))，也仅需要在程序中新增加一个配置项罢了。因为其所属的分类已经存在于框架中。只有当新增加的一个菜单/权限所属的分类为一个不存在于框架的分类时，才需要基于之前的步骤，执行第一、二、三步骤了的。

9、菜单的最终结构如下(为了防止权限标识冲突，分类类型的菜单添加了后缀：-menu-category，链接类型的菜单添加了后缀：-menu-link)：

10、权限的最终结构如下(为了防止权限标识冲突，分类类型的权限添加了后缀：-permission-category，链接类型的权限添加了后缀：-permission-link，按钮类型的权限添加了后缀：-permission-button)：

11、在服务层面添加菜单完毕后，在租户层面下的服务中编辑/勾选菜单，如图6

12、编辑文件：\common\config\params.php，添加框架服务权限配置

13、当调用某接口时，其分类权限标识的确认，是获取其上一维度的数组键。可能存在多个数组键。同一个接口可能所属权限分类不止一个，举例：获取选题栏目人员配置列表(创建、编辑、更新选题时必需)同时存在于新建选题与更新选题的分类中。出现这种情况时，基于权限分类标识依次调用 CMC 框架接口，直到具有某权限分类标识为止。或者直到结束仍然未具有权限分类标识，此时响应无对应接口的权限。注：后续 CMC 框架需要支持权限标识为数组格式，以避免多次 CMC 框架接口的调用。调用接口：获取选题栏目人员配置列表(创建、编辑、更新选题时必需) 时，其分类权限标识值为：[‘plan/create-permission-button’, ‘plan/have-permission-button’]。如图7

14、在 Postman 中调用接口：http://api.pcs-api.localhost/v1/plan-config-column-users?login_id=2e368664c41b8bf511bcc9c65d86dbc3&login_tid=0b0f8b3f90a7afc91bf5416c283053df&filter[config_column_id]=1 ，响应如下

15、查看日志，通过框架服务权限标识获取用户权限，权限标识为接口本身的标识，如图8

16、编辑 \common\behaviors\GlobalAccessBehavior.php，新增方法，基于接口标识获取其父级的数组键名，格式为数组。

17、调用接口，接口的权限标识为：plan-config-column-user/index，此时，框架服务权限中的键名为：[‘plan/create-permission-button’, ‘plan/have-permission-button’]，当前用户所属角色的权限配置，由于 2 个键名皆为勾选，则仅会执行 1 次授权请求，如图9

18、调用接口，接口的权限标识为：plan-config-column-user/index，此时，框架服务权限中的键名为：[‘plan/create-permission-button’, ‘plan/have-permission-button’]，当前用户所属角色的权限配置，由于仅勾选了第 2 个键名，则会执行 2 次授权请求，如图10、图11

19、调用接口，接口的权限标识为：plan-config-column-user/index，此时，框架服务权限中的键名为：[‘plan/create-permission-button’, ‘plan/have-permission-button’]，当前用户所属角色的权限配置，由于 2 个键名皆未勾选，则会执行 2 次授权请求，且提示授权失败，如图12、图13、图14

 

20、调用接口，接口的权限标识为：plan-config-column-user/index，此时，框架服务权限中的键名为：[‘plan/create-permission-button’, ‘plan/have-permission-button’]，当前用户所属角色的权限配置，由于仅勾选了第 1 个键名，则执行流程与第 17 步骤一致

21、权限的设计原则总结如下：
(1)权限(四级)与菜单(二级)隔离，可确保菜单显示的结构与权限的结构不一致时的灵活处理。
(2)权限与菜单在某一程度上又需要保持一定的对应关系(层级与名称尽量保持一致)，以解决如下情况：当用户具有某菜单的显示时，如菜单：待审选题，却在权限中不具有接口：待审核选题(获取选题列表)的所属权限分类，直接弹出提示：不具有接口权限。此时，部署实施人员能够很直观地基于菜单结构在权限结构中勾选对应的权限。
(3)在划分接口的分类时，在同一个分类中，需要确保接口之间的依赖关系是完全满足的。举例：在接口：编辑选题所属的权限分类中，必须具有接口：编辑选题所依赖的其他接口，如(接口：获取选题栏目人员配置列表(创建、编辑、更新选题时必需))。
(4)接口：编辑选题，在桌面端与移动端中皆存在，是否需要将两个端中的接口划分至不同的分类下。最终决定：由于接口路由已经明确区分了的，那么其分类也应该明确区分。权限的整体结构更为清晰。
(5)权限的结构在程序的配置文件中，格式为四维数组。
(6)同一个接口可能所属权限分类不止一个，举例：获取选题栏目人员配置列表(创建、编辑、更新选题时必需)同时存在于新建选题与更新选题的分类中。出现这种情况时，基于权限分类标识依次调用 CMC 框架接口，直到具有某权限分类标识为止。或者直到结束仍然未具有权限分类标识，此时响应无对应接口的权限。注：后续 CMC 框架需要支持权限标识为数组格式，以避免多次 CMC 框架接口的调用。
(7)当调用某接口时，其分类权限标识的确认，是获取其上一维度的数组键，如果所属权限分类为空，则设置默认值为接口本身权限标识。