project-mirai/mirai-plugin-center

[WIP] Center of plugins for Mirai Console and Mirai community.

mirai-plugin-center's Issues

关于文档

• server/README.md

角色与权限

Role 应当被细分为 Permission，并且 User 也不应该只拥有一个 Role，考虑加表或者修改表结构

基础注册登录

/plugins/count和实际数量不对应

支持插件审核

前端的工程化

• env文件中增加生产环境、调试环境判断
• 引入redux（或者使用store）作为全局信息存储工具
• 封装全局请求库

插件查询

日志操作

• 插入日志

ktor

要不要试一下ktor代替spring boot来开发后端 [doge]
据说更简洁且插件中心规模估计没有复杂到用spring

文件控制

• 前端支持文件上传
• 后端支持文件列表控制
• 前端支持文件列表控制
• 支持可见控制（Admin）

管理员查看非 Accepted 插件的接口

可以扩大到查看所有插件，并且可以附带 filter

插件版本管理

• 后端-查看版本列表
• 后端-为插件新建版本
• 后端-查看某版本下所有文件列表
• 后端-删除某版本下某文件
• 后端-权限控制接口
• 后端-路径安全控制
• 前端-编辑页面支持插件版本浏览
• 前端-编辑页面支持插件版本创建
• 前端-编辑页面支持插件版本删除
• 前端-编辑界面支持某插件版本下文件列表查看
• 前端-编辑界面支持某插件版本下文件上传
• 前端-编辑界面支持某插件版本下文件删除
• 前端-权限控制
• 前端-抽象下载组件
• 后端-修改权限判断支持Admin组进行所有操作，而不是仅限owner

画大饼

为什么没有 TODO List？

• #17
• #36
• #20
• #23
• #39
• #30

全面使用 Caching

仅有少部分代码使用了 Caching，需要全面使用 Caching

改密码未成功修改

是否有过测试 @HoshinoTented

插件列表API需要返回总页数

插件查询

• 单个插件查询（是否考虑作为批量查询）
• 插件列表

关于开发标准

急需开发标准
or become a shit mountain

数据库表命名

• 所有 column：snake_case
• 所有 foreign key：[表名]_[主键名]

Spring Model

所有请求

• 以 RequestData 结尾

所有响应

• 以 ResponseData 或 RespData 结尾

Remarks

至于 RequestData 为什么不选择用 ReqData，是因为我觉得 req 这个缩写太丑了。

所有 Spring Component

• 以 Service 结尾的 Component 的类型的变量名，允许使用 Svc 代替 Service，如：val userSvc: UserService
• 以 Repo 或 Repository 结尾的实现了 Repository 接口的类型的变量名，推荐使用 Repo 代替 Repository，如：val userRepo: UserRepository

所有函数

• 最多只能有一个 return 语句（不强制）

所有类字段/属性访问

• 使用 this.xxx（不强制）

whoami接口返回用户权限

用于前端路由判断

Tracking issue for Exception Handling

目前的错误处理似乎有些混乱，希望可以统一一下：
有些代码使用 throw 交给外部处理，有些则使用返回一个包含具体错误代码的 ApiResp
考虑仅使用其中一种（这里的错误仅考虑手动判断的 “错误”：如用户不具有某些权限）

插件上传下载修改

Pr #41 的后续工作

目前找到的问题是：

• 删除当前用户相关的内容无法立刻生效：
  因为当前用户的实例是存在 Session 里的，没有办法被 Hibernate 刷新。

日志历史链

为 LogEntity 增加 parent: LogEntity? 字段来构成一个日志历史链，所有操作都可以通过追踪这个历史链获得

问题

Question. 创建者是否作为历史链的一部分存入，而不另外开辟一个 column？
Advice. 需要频繁访问创建者的 Entity 可以考虑增加 owner column

Tracking Issue for 氪金 System