【组织架构】用户信息中的【账号到期时间】填充优化 about bk-user

[Canway-shiisa]

更新原型为：

=》将新建用户操作 原先的<账号过期时间>字段变更成<账号有效期>

目前：
1.用户表没有类似<密码有效期>一样，在目录配置表中存储一份密码有效期，在用户表中再单独存储一份用户个人的密码有效期
2.用户表是存储的 <账号过期时间>，新建用户默认是通过所在目录配置的<账号有效期>及新建用户时间进行<账号过期时间>计算，<账号过期时间>支持编辑

如果按照更新的原型进行修改，需要确认下面几个问题：
1.支持用户编辑<账号有效期>的话，用户表需要新增对应字段，枚举值类比<密码有效期>
2.账号有效期的计算是 【账号创建时间+账号有效期】，类比密码有效期的枚举，账号有效期也是除了永久之外最长时间为365天；由于密码修改会刷新一个密码更新时间=》密码过期时间也随着变更，但是账号创建时间是不会变的，这里计算账号过期时间上可能会有问题？

[wklken]

1. 密码有效期暂不处理; 保持现状(即, 保持现在的编辑和展示)
2. 账号有效期
   • 展示: 返回账号过期时间(原来的) + 还剩多少天账号过期(=账号过期时间-当前时间, 前端可以算, 也可以后台算多一个字段返回), 前端转成多少天展示
   • 编辑: 将账号过期时间设置为 用户选择的时间 (此时不用考虑账号创建时间, 不用管账号新建), 注意不允许大于永久的

即, 前端才有账号有效期的概念, 后台还是账号过期时间

[wklken]

[Shutulee]

设计稿的逻辑目前看没问题。用户通常来讲不太关注上次选择的相对时间，而更关注目前账号还有多少天剩余可用。

展示：账号剩余天数（过期时间：xxxx-xx-xx）。
编辑：选择有效期（过期时间:xxxx-xx-xx）。过期时间=当前更新时间+有效期。即进行续期。

但假如上次选择的相对时间能被记录，展示上会更友好一些——例如，「账号有效期：剩余12/30天（过期时间xxxx-xx-xx）」。
nice to have，可以评估一下改动量。

[wklken]

即:

• 展示：账号剩余 Y 天（过期时间：xxxx-xx-xx）。 Y=过期时间-当前时间 或者 0天(如果是负数); 这里 过期时间 xxxx-xx-xx即账号过期时间
• 编辑：选择有效期（过期时间: xxxx-xx-xx）。 这里 过期时间=当前时间+有效期。
  向后台提交的 账号有效期=用户下拉选择后计算出来的过期时间 (注意编辑态没有不展示原有的账号过期时间), 如果没有更新表单提交的是原始的账号过期时间(或者没有修改表单不提交这个字段)

假设当前时间 2023-01-30

展示: 
- 后台返回 2023-01-29, 展示成 `已过期(2023-01-29)`
- 后台返回 2023-01-31,  展示成 `1 天 (2023-01-31)`

编辑:
- 下拉选择, 提交时有更新直接设置账号过期时间为括号中的时间
   - 1 天 (2023-01-31)
   - 1 个月(2023-02-28) 
   - ...
   - 1 年 (2024-01-31)
 

---

记住上次选择的成本会比较高, 本身这个字段是非核心字段暂时不考虑