link2fun

Results 7 issues of link2fun

## 你使用的 NASTool 是什么版本,什么环境? NASTool 版本: v2.2.2 环境: docker ## 你想要新增或者改进什么功能? ![image](https://user-images.githubusercontent.com/19241982/195982867-2b8b1ac9-5b5d-4922-8f5e-f2b3f85e0f78.png) 上面的刷新时间支持 CRON 表达式(如果是图形化的勾选就更好了) ## 使用场景 自定义订阅的东西一般都有固定的更新时间, 其他时间一直刷新也没有什么意义 ## 这个功能有什么可以参考的资料吗? https://bradymholt.github.io/cRonstrue/#cronstrue-demo ![image](https://user-images.githubusercontent.com/19241982/195983081-5d39b22b-4a52-4618-a865-0bedb9449347.png) ![image](https://user-images.githubusercontent.com/19241982/195983449-6814430e-213a-432d-9121-0183ad572fa3.png)

功能加强

```java EasyPageResult pageResult = entityQuery.queryable(SysRole.class) .where((role) -> { role.delFlag().eq(UserConstants.NORMAL); role.roleId().eq(IdUtils.isIdValid(searchReq.getRoleId()), searchReq.getRoleId()); // 角色ID检索 role.roleName().like(StrUtil.isNotBlank(searchReq.getRoleName()), searchReq.getRoleName()); // 角色名称检索 role.status().eq(StrUtil.isNotBlank(searchReq.getStatus()), searchReq.getStatus()); // 角色状态检索 role.roleKey().like(StrUtil.isNotBlank(searchReq.getRoleKey()), searchReq.getRoleKey()); // 角色权限检索 role.createTime().ge(Objects.nonNull(searchReq.getParams().getBeginTime()), searchReq.getParams().getBeginTime()); // 开始时间检索 role.createTime().le(Objects.nonNull(searchReq.getParams().getEndTime()),...

bug

场景 ``` // documentDate 在数据库中是个 bigint Long 类型, 但是查出来之后需要当做日期使用(部分场景下) // 所以期望能增加一个 converter 重载来支持 转换, 即能从 A 类型转为 B 类型, 使用Java代码进行查询后的转换 在部分场景下更为便捷 new xxxProxy().documentDate().set(purchaseOrderHead.documentDate(), (rawLong)->{ return formatLongToLocalDate(rawLong); }) ```

场景: 销售订单 关联有很多档案,算上订单表体的关联 多达30+ 目前的场景是 依次加载每一个关联的实体,这就会执行 30+条SQL 实际 一般都是 toOne 查询,可以合并成 join 查询 以减少数据库请求次数 来提升执行效率 额外的, toOne 有时候可能是大表,可以默认 join 执行,用户可以更改为独立执行 属性可以放在 Navigate 注解上,实体的和DTO的是否join查询可以不一致

现状 a().b().c() b是个没什么意义的中间表, 但是目前的数据结构又改不了 请求支持 oneToOne 能像 ManyToMany 一样 用上中间表 最终达成 a().c() 使用上和 ManyToMany 保持一致 只是类型变成 oneToOne

场景说明 现在的 extraFilter 类似一种默认的查询条件 比如: extraFilter 查询的是默认状态为正常的数据 但是少数场景下 可能需要去查一下 状态异常的数据 此时因为 extraFilter 的存在 就就无法直接复用当前的关联关系 私以为,将 Nav 注解视作关联关系, 将 extraFilter 视作查询的时候的默认条件 当需要的数据和默认条件不一致的时候 可以忽略掉默认条件的拼接

**Describe the bug** V3 版本 DAV 存在目录越权,alist 挂载后从 alist 删除数据 可能导致 根目录数据被删掉,本人数据已丢失请诸位数据注意备份 **To Reproduce** Steps to reproduce the behavior: 1. 创建目录 2. 创建目录对应的 dav 账号 3. alist挂载 dav 账号 4....