RBAC 反正就是很厉害. 干就完事了,不BB 直接进入正题

本文写的就是如何设计表,以及设计表的思路.

用户和角色 :

多对多字段放在哪张表更好点?
用户找角色,角色找权限. 放在user表中,是正向查询,我们操作起来更方便些.

记得在admin里面,admin.site.register(models.User)
记得在admin里面,admin.site.register(models.Permission)
记得在admin里面,admin.site.register(models.Role)

权限 :

- 权限的本质就是URL
- 里面有title(用户列表,添加,删除,编辑), 还有url
让码农这个角色 和 查看用户权限  建立关系
根据角色找权限.
- 你的权限包括 增删改查,  在页面上你的编辑和删除 应该是由\d+的,他俩没法做菜单,他俩应该是现在是用户列表页面的. 你进入list后才能看的到的.       添加勉强可以做菜单  所以 你应该在你权限表里面加一个 是否为菜单的字段
- 有没想过 这个权限里面为什么要有code字段呢?我直接让角色和url对应起来不是更简单易懂吗还方便操作吗?
    -

group :

- 又因为code里面  都是list,add  分不清是那个组(用户,订单)的
所以加了一个字段, group, 是用来区分list是属于user还是order的
每个组下面四个权限

- 分完组之后,每个组的权限少了,那么个数就多了.      每个组下面            显示的菜单太少.

所以再来一级.

• menu_id : 菜单--> 组 --> 权限

---

现在还有一个问题, 但我们点击用户列表的时候, 菜单上的用户列表会被默认选中, 但是当你点击编辑的时候,因为编辑不是菜单,这个时候,菜单选项就没了. 可是我们还是在菜单一下面的用户信息完成编辑操作的. 我们还是要让菜单一下面的用户信息默认选中. 在权限里面加一个内联的foreign key,别和我扯什么is_menu. 丢掉,统统丢掉,你如果用is_menu的话,你如何把你同一个组的list(显示菜单),add,edit,del 关联起来. 如何实现刚才说的,当请求权限并不是菜单的时候如何继续默认选中菜单组.