权限管理部分的一些设计与想法

需求：公司需要设计一个可编辑的权限管理模块

最初的设计时用户、角色、URL资源，三层关系，在基类中进行过滤，用户一对多角色，角色一对多URL资源。

那么问题来了，对于界面和AJAX的URL返回值并不相同。

这时我在URL资源的表中加了一行ajax标示AJAX类型，同时引入了所属菜单，因为菜单的改动一般很少，所以直接在代码中定义，增加tinyint的type字段，来存储所属菜单。

之后，因为一些特殊的需求，在角色中又加入了TAG字段，在程序中可以单独申请验证登陆用户的所属角色是否拥有TAG标签，来进行一些复杂的权限验证。

这时基本的需求已经满足了，但是新的需求又来了，需要引入第三方管理员的概念，他们可以添加用户，并赋予用户第三方操作员的权限。

可是，第三方管理员又分不同的渠道，我们拿什么来区分一个第三方管理员应该管理哪些用户么？

我们这时给用户和渠道加上了对应关系，而且一个用户还可能对应多个渠道，瞬间就混乱了。

于是，我把加入渠道的影响分成了两部分。

首先是对原先权限管理的影响，然后是如何实现第三方管理员的部分。

原先的权限管理中，我对用户和角色都引入了type来标识是否是第三方用户，然后在角色分配的界面，可以怼第三方类型的用户分配渠道。

第三方管理员由我方人员手动配置。第三方管理员可以添加第三方用户，手动分配给他们一个或多个自己拥有的渠道。第三方管理员只能看到拥有和自己相同渠道的人的用户。
PS：如果一个操作员有两个渠道，但是这两个渠道分属两个人管理。这时岂不是要限制第三方管理员只能分配自己拥有的渠道给别人。
第三方管理员只能分配我方给定义好的角色类型，添加的用户自动是第三方用户属性。

就这样，我在原先基础的权限管理中，加入了反人类的渠道和第三方管理员的功能。

---

后续使用过程中还有一些问题，比如从开发环境到线上环境的同步，因为URL的定义都在数据库中，所以需要把数据导出，直接导入到线上数据库中。
然后这个权限管理系统的可扩展性不强，资源是基于URL定义的所以定位精度也是在URL级别的，不能对一个URL内部的展示做定位。临走前，我也删除了原来代码中所以对角色标签的使用。