mirror of
https://github.com/suyiiyii/SIMS.git
synced 2025-05-31 11:46:42 +08:00
* refactor(common): 整理拦截器配置和JWT拦截器实现 * feat(auth): 将权限信息使用注解的形式固定在接口上 * feat(rbac): stash * fix(GlobalException): 在ServiceException处理中添加日志记录 在全局异常处理器中为ServiceException添加错误日志记录,以提高错误跟踪的可观察性。现在,当捕获到ServiceException时,将记录错误消息。 更改包含: - 导入lombok.extern.slf4j.Slf4j注解以启用日志记录功能。 - 使用@Slf4j注解GlobalException类。- 在ServiceException的@ExceptionHandler方法中添加日志记录语句。 * feat(auth): 实现RBAC,调整JWT验证,更新用户服务和控制器 * 为所有接口添加权限注解 * 删除没有必要的接口 * 删除过期的测试 * refactor(entity): 使用MyBatis-Plus和AutoTable注解重新定义主键和注释 - 重构`Role`, `RolePermission`, `User`, 和`UserRole`实体类,统一使用`@ColumnId`注解代替`@TableId`,并为各实体类的字段添加了相应的注释。- 为`Role`实体类的`roleId`和`roleName`字段,`RolePermission`的`roleId`和`permissionId`字段,`User`实体类的`studentId`, `username`, `password`, `email`, `grade`, 和`userGroup`字段,以及`UserRole`的`userId`和`roleId`字段添加了`@ColumnNotNull`注解,以强化字段的非空约束。 * refactor(jwt-interceptor):精简无效的JWT,提高检查效率 调整JwtInterceptor以精简无效的JWT检查逻辑。实现对JWT效验和用户ID提取的优化,避免不必要的数据库查询。refactor(role): 使用自定义注解替换MyBatis Plus注解并移除冗余字段 通过自定义注解替换MyBatis Plus注解,以整理和优化实体类定义。删除了Role类中的冗余字段,如'tag',以及未使用的imports。 refactor(user-service): 使用ModelMapper简化对象映射,重构注册逻辑引入ModelMapper以简化User对象和DTO之间的映射操作。重构UserService中的用户注册逻辑,使用ModelMapper进行对象转换,减少手动设置属性的需求。 fix(user-controller):调整用户注册请求参数,统一数据类型 调整UserController中的注册请求参数,将'studentId'和'userGroup'的类型与现有代码库保持一致,以便正确进行参数传递和处理。 feat(user-service): 实现rbacService集成,增强用户注册流程 在UserService中集成rbacService,以在用户注册时为新用户分配默认角色。优化了用户注册流程,并简化了权限和角色的管理。 BREAKING CHANGE: 对UserRole逻辑的改动可能会影响现有的用户权限和角色分配。请确保在更新代码后进行 * 修复测试配置
SIMS
Super Invincible Management System
开发流程:
-
git fetch: 拉取远程仓库的最新代码
-
git checkout origin/main: 切换到远程仓库的 main 分支
-
git switch -c xxx : 创建并切换到新的分支
-
commit ..... : 进行开发
-
git fetch origin && git merge origin/main: 拉取远程仓库的最新代码并合并到当前分支
-
git push origin xxx: 推送当前分支到远程仓库
-
提 PR
-
require review: 请求reviewpush
-
merge: 合并 PR
-
delete: 删除分支
-
基础rbac的五张表: user, role, permission, user_role, role_permission
-
然后奖惩记录这张表,通过用户id来查到,里面有相应的记录, 有一个 奖惩类别ID是对应到奖惩类型去的
-
有一个上下级关系表,想着是用户明确查上下级就可以用查,
-
然后就是附件,是通过奖惩记录的id来存一个路径,然后前端通过这个路径来获取附件,同样的上传的时候也是
-
通知是这样子想的,有上传的人的id和接收的人的id,然后有状态(已读,未读),然后有附件的路径,然后有通知内容,然后有通知时间,然后有通知类型(奖惩,通知)
-
RevokeRequest: 存普通成员提出的撤销申请,跟踪申请状态 RevokedRecord: 存储管理员对奖惩记录的撤销信息,包括撤销原因
Languages
Java
99.3%
Dockerfile
0.7%