DC's blog DC's blog
首页
  • 计算机基础
  • linux基础
  • mysql
  • git
  • 数据结构与算法
  • axure
  • english
  • docker
  • opp
  • oop
  • 网络并发编程
  • 不基础的py基础
  • 设计模式
  • html
  • css
  • javascript
  • jquery
  • UI
  • 第一次学vue
  • 第二次学vue
  • Django
  • drf
  • drf_re
  • 温故知新
  • flask
  • 前后端不分离

    • BBS
    • 订单系统
    • CRM
  • 前后端部分分离

    • pear-admin-flask
    • pear-admin-django
  • 前后端分离

    • 供应链系统
  • 理论基础
  • py数据分析包
  • 机器学习
  • 深度学习
  • 华中科大的网课
  • cursor
  • deepseek
  • 杂文
  • 罗老师语录
  • 关于我

    • me
  • 分类
  • 归档
GitHub (opens new window)

DC

愿我一生欢喜,不为世俗所及.
首页
  • 计算机基础
  • linux基础
  • mysql
  • git
  • 数据结构与算法
  • axure
  • english
  • docker
  • opp
  • oop
  • 网络并发编程
  • 不基础的py基础
  • 设计模式
  • html
  • css
  • javascript
  • jquery
  • UI
  • 第一次学vue
  • 第二次学vue
  • Django
  • drf
  • drf_re
  • 温故知新
  • flask
  • 前后端不分离

    • BBS
    • 订单系统
    • CRM
  • 前后端部分分离

    • pear-admin-flask
    • pear-admin-django
  • 前后端分离

    • 供应链系统
  • 理论基础
  • py数据分析包
  • 机器学习
  • 深度学习
  • 华中科大的网课
  • cursor
  • deepseek
  • 杂文
  • 罗老师语录
  • 关于我

    • me
  • 分类
  • 归档
GitHub (opens new window)
  • BBS

  • 订单平台

  • CRM

  • flask+layui

  • django+layui

    • 理论储备
    • 项目编写
    • 规则怪谈
      • 登陆
      • 动态菜单
      • 权限认证
      • 部门管理
      • 权限状态的逻辑
      • 权限管理
      • 角色管理
      • 角色授权
      • 用户管理
    • 一些思考
    • 代码讲解
    • 部署
  • 供应链

  • 实战
  • django+layui
DC
2024-11-11
目录

规则怪谈

项目需求以及相关技术关键词.

其实针对于系统管理中的部门管理、权限管理、角色管理、用户管理. 都是具备高权限的人在操作..
可操作的很多, 我们不必过于纠结这个人会不会在浏览器里右健检查进行修改、用apifox发送请求之类的, 没必要..
简单的在curd逻辑里判断下 id 是否存在即可.. (但有一点,超级管理员的配置是改不动的!!)

至于普通用户, 在进行业务功能的修改删除时, 就要考虑这些小人操作, 比如当前登陆用户只能修改自己的..

# 登陆

  • 需求1: 用户输入用户名和密码, 登陆成功后, 自动跳转首页. 未登陆成功, 提示用户 用户名或密码错误..
  • 需求2: 用户访问某页面(eg:首页), 若未登陆自动跳转登陆页面.
  • 需求3: 当超级管理员将该用户的状态改为了禁用, 应该立即生效, 该用户访问任意页面都应该跳转登陆页面.
    并且被禁用的用户在尝试登陆时, 会告知该用户, 此账号已被禁用..
  • 需求4: 当超级管理员将该用户删除(软删除)后, 与需求3同理..
  • 需求5: 登陆认证应有白名单

技术实现: form表单校验、session实现会话保持、中间件里实现登陆认证


# 动态菜单

提一嘴: 权限类型分为menu和meun-z和auth, auth是不可作菜单的..

  • 需求1: 登陆成功后跳转的首页, 首页会自动加载左侧的动态菜单..
    • 左侧菜单会根据当前登陆用户的所拥有的权限进行动态加载!!
    • 若当前登陆用户所拥有的角色的状态被超级管理员改为了禁用, 那么该角色对应的权限不应该出现在动态菜单中
    • 若 用户-角色-权限, 某个权限的状态被超级管理员改为了禁用, 那么该禁用的权限不应该出现在动态菜单中
    • 若 用户-角色-权限, 软删除的角色和权限也应排除在外.
  • 需求2: 若当前登陆用户是超级管理员, 则左侧菜单默认会根据所有权限(除了软删除的)进行动态加载.

技术实现: 递归


# 权限认证

  • 需求1: 用户若无权访问当前访问的页面或功能, 展示403权限认证失败页面,借此提示此账号没有该功能权限..
  • 需求2: 若当前登陆用户是超级管理员, 无需权限认证
  • 需求3: 只要超级管理员在权限管理模块将某权限的状态改为了禁用或软删除了某权限
    那么给该用户分配的角色有该权限也没用, 权限认证依旧通过不了
  • 需求4: 权限认证应有白名单

技术实现: 中间件里实现权限认证


# 部门管理

[新增post]

  • 需求1: 新增的部门的上级部门id需有效 - <外键字段自身>
  • 需求2: 新增的部门名不能跟已存在的部门名重名 - <视图函数中 or clean中皆可>

[编辑post]

  • 需求1: 编辑的部门的id需有对应的对象
  • 需求2: 修改的上级部门id需有效 - <外键字段自身>
  • 需求3: 不能设置自己为父部门.
    <视图函数中,便于拿到edit_id 通过id来比!!不能通过name,编辑表单name改了,式子肯定不会成立的.>
  • 需求4: 修改的部门名不能跟除自己以外的其他已存在的部门名重名 - <视图函数中,便于拿到edit_id>

[删除post]

  • 需求1: 删除的部门的id需有对应的对象
  • 需求2: 有子部门是无法删除当前部门的
  • 需求3: 部门软删除

# 权限状态的逻辑

关于权限的状态 - 禁用|启用

  • 需求1: (操作者通过apifox发生请求)判断该权限是否已经不存在或已删除, 是的话, 提示操作者.
  • 需求2: 判断该权限的子权限在使用中, 若在使用, 则该权限不能禁用.
  • 需求3: 父权限和子权限原本都是处于禁用状态, 当启用一个子权限时, 其父权限同步自动启用..
  • 需求4: 权限的禁用对超级管理员应不起作用 (权限认证是在中间件中的, 若是superadmin, 我直接返回的None.. 意味着, 只要登陆后, 所有路由的访问畅通无阻
Ps:若其他管理员拥有了"权限状态"这个权限,他将"获取权限"这个权限的权限状态改为了禁用,那么他自己在表格里就看不到权限树了!!
- 若父权限没生效,那么该父权限下的所有子权限一并都不应该生效!! (在状态禁用的逻辑里变相实现了.
1
2

# 权限管理

★注意,新建菜单权限后,需要给用户的角色赋予这个权限, 不然刷新页面, 同步更新的用户的动态菜单中不会有相关的权限..

[新增、编辑]
- 获取权限的父权限下拉框,选择的pid只能是菜单或节点,不能是权限!
- 关于菜单、节点、权限的单选框 
  > 前端进行单选框切换实现某些表单项的隐藏和展示 以及 特定选择下必填项的校验
  > 后端根据表单的单选框的选择(项目中该单选框的name值叫kind)
    - 看pid是否必须
    - 看哪些字段的值在存储时应该覆盖为空
    
[新增]
- 权限名称不能跟已存在的权限名重名

[编辑]
- 权限名称不能跟除自己以外的其他已存在的权限名重名
  进行了软删除,又编写了新增不能重复名的问题.被软删除的权限也算到了里面,不算的话,加个判断即可!!我加了.
- 在权限编辑时,同样的要实现"权限状态-禁用启用"的逻辑!!

  
[删除] 同部门管理
 0. 删除的权限的id需有对应的对象
 1. 有子权限是无法删除当前权限的
 2. 权限的软删除
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

细品下动态菜单的结构

""" 在clean方法中!
首先,kind字段自身就是不为空的.字段自身校验没错的话,kind肯定有值.
可以将项目左侧菜单理解成 
-- 一级菜单`menu`
-- 一级菜单`menu`
  -- 二级菜单`menu`
    -- 节点`menu-z`
    -- 三级菜单`menu`
       -- 节点`menu-z`
  -- 节点`menu-z`
     -- 权限`auth`
     -- 权限`auth`
  -- 节点`menu-z`
> 规则怪谈: 新增的权限有三种类型-菜单menu、节点menu-z、权限auth。
  菜单可以放到任意层级的菜单下,也可以不选则自己作为顶级菜单 ; 节点可以放到已有的任意层级的菜单下 ; 权限都必须放到节点下!!
> 数据库中: (0代表不需要、1代表需要
          图标  权限标识  访问路径  pid是否必选
"menu"     1      0       0        0
"menu-z"   0      1       1        1 
"auth"     0      1       1        1
"""
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 角色管理

我就粘贴复制一通, 改吧改吧就完成了角色的CURD和状态的更改. - 因为所涉及的知识点前面都用到啦!!

[新增]
- 角色名称不能跟已存在的角色名重名

[编辑]
- 编辑的角色的id需有对应的对象
- 角色名称不能跟除自己以外的其他已存在的角色名重名

[删除]
 0. 删除的角色的id需有对应的对象
 1. 角色的软删除

[状态更改]
- 状态更改的角色的id需有对应的对象
1
2
3
4
5
6
7
8
9
10
11
12
13

# 角色授权

- 点击角色主页的授权,加载角色授权的iframe页面(携带了角色id),该页面会自动发送请求获取权限树并自动勾选当前角色所拥有的权限.
  - ★ 关于当前角色所拥有的权限,因为layui tree组件的缘故,我们只需返回树中叶子节点的id!!
- 点击角色授权页面上的重置按钮,重新进行发送请求获取权限树并自动勾选当前角色所拥有的权限.
- 点击角色授权页面上的确认按钮,前端通过递归采集到勾选的id,后端进行多对多的更新!!(先清空再添加)
1
2
3
4

# 用户管理

[用户主页]

> 分页和筛选条件都是构造?params参数,在请求用户表格数据时,携带该参数!!
- 分页
- 筛选条件 名称、性别、职位、注册时间、是否启用 + 部门
  > 因为是查询,后端直接查 部门树传递到后端的勾选id即可!!
   (不用考虑是否是叶子节点,非叶子节点是 经理或CEO.一并查询出来,无伤大雅
1
2
3
4
5

[用户 增加、修改、删除]

1.手机号、邮箱是唯一的 (昵称和用户名我们允许重名
2.密码和重复密码需一致
3.部门前端可不填,不填则表示待定.
1
2
3

[用户授角]

...
1

虽然没 权限是否启动 的权限, 但可以通过权限编辑来实现这个功能, 就不搞这么细了.
1
templet: (d) => {
    const imageUrl = `${window.location.origin}` + `${d.avatar}`;
    return `<a href="${imageUrl}" target="_blank" lay-on="user-tips-photos-one">
    <img src="${imageUrl}" alt="头像" style="width: 30px; height: auto;" /></a>`;
}
1
2
3
4
5

项目编写
一些思考

← 项目编写 一些思考→

最近更新
01
deepseek本地部署+知识库
02-17
02
实操-微信小程序
02-14
03
教学-cursor深度探讨
02-13
更多文章>
Theme by Vdoing | Copyright © 2023-2025 DC | One Piece
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式