lin-cms-spring-boot
lin-cms-spring-boot copied to clipboard
TaleLin
🔨 基于SpringBoot的CMS/DMS/管理系统开发框架
**描述 bug** 新增的websocket功能没有yaml的语法提示  
请详细描述您对本项目的任何问题，我们会在第一时间查阅和解决。 spring 中有配置限制文件大小上传的设置，设置如下 // 设置单个文件大小 spring.servlet.multipart.max-file-size= 10MB // 设置单次请求文件的总大小 spring.servlet.multipart.max-request-size= 50MB 而lin-cms-boot 中，理解不到位，只使用了max-file-size参数，并错用为总文件大小限制，同时又另外设置single-limit参数去判断单个文件。 建议，统一规范，在io/github/talelin/latticy/extensions/file/config.properties中使用配置max-request-size和max-file-size参数即可，去除single-limit部分涉及到的多余的业务代码
我们内置的管理员用户表为 `lin_user`，对应的模型层命名为 `UserDO`、服务层命名为`UserService`、控制器层命名为`UserController`。 当我们开发一个独立的 CMS 项目，是没有什么命名冲突问题的。 但对于一个小型项目，我们想使用 LinCMS 快速开发 C 端用户接口，如果 C 端用户表名称为 `user` ，那么对应的模型层、服务层等等就不能使用`UserDO`、`UserService`这些来命名，可否考虑把`lin`内置的类命名加一个前缀做区分？（例如`LinUserDO`、`LinUserService`）。这样`C`端用户相关的类，就不用考虑命名冲突问题了。也不会因为系统中`user`相关的命名太多，对后续的维护者造成困惑。
此问题属于 #185 的衍生问题。 `LocalUser`对象是线程安全的当前登录用户，除了 LinCMS 系统内的管理员用户（对应模型为`UserDO`）外，C端用户也需要同样设置到请求上下文中，甚至说除了用户需要设置到请求上下文中，其他数据也可能需要设置到请求上下文中。现在的 LocalUser 只能 set 和 get `UserDO` 类型的对象： https://github.com/TaleLin/lin-cms-spring-boot/blob/bd6b0c8692b95bafd14b8ba0585ebb64b35d8788/src/main/java/io/github/talelin/latticy/common/LocalUser.java#L12 这样 LocalUser 基本就不可复用了，如果 C 端用户同样需要设置线程安全的当前登录用户，就不得不重新封装一个类，但里面的代码除了所存储的类型基本都一样的，可以考虑把`ThreadLocal `中的泛型`UserDO`类型改为`Map`，并将类重命名为 `LinThreadLocal`： ```java private static ThreadLocal threadLocal = new ThreadLocal(); ```...
java -jar target/latticy-0.2.0-RC2.jar 启动报错：  该问题主要出现在 `windows` 操作系统用户 使用`java -Dfile.encoding=utf-8 -jar target/latticy-0.2.0-RC2.jar`命令可以正常启动，要不要在文档中加入说明？
使用gradle配置成功，数据库已配置，在运行项目后出现如下错误 
配置文件切换问题
请详细描述您对本项目的任何问题，我们会在第一时间查阅和解决。 请问一下为什么在命令行中指定项目配置环境和jar包同目录下配置环境都无法使用呢？而且在resource目录下的application.yml文件中，如果代码写死激活的是dev环境后，打包运行怎么都的dev环境
目前@Logger的使用必须配合LoginRequired、GroupRequired或AdminRequired一起使用，再考虑到权限的使用，通常会出现PermissionMeta、LoginRequired(三选一)、Logger三个注解一起使用的情况。 是否考虑可以将@Logger或@PermissionMeta直接内置LocalUser.setLocalUser()的功能
CMS 是一个颇为复杂的应用，它需要的东西太多。我们无法涉及到方方面面，因此关于新特性，我们会以讨论的形式来确定这个特性是否去实现，以什么形式实现。 我们鼓励所有对这个特性感兴趣的人来参与讨论，当然如果你想参与特性的开发那就更好了。 如果你实现了一个 feature，并通过了单元测试，请用`git rebase`合并成一条标准的`feat: description`提交，然后向我们的 项目提 PR，我们会在第一时间审核，并感谢您的参与。 **请问这个特性跟什么问题相关？ 有哪些应用场景？请详细描述。** 请清晰准确的描述问题的内容，以及真实的场景。 **请描述一下你想怎么实现这个特性** 怎么样去实现这个特性？加入核心库？加入工程项目？还是其他方式。 当然你也可以描述它的具体实现. **讨论** 如果这个特性应用场景非常多，或者非常重要，我们会第一时间去处理。但更多的我们希望更多的人参与讨论，来斟酌它的可行性。
