ericli

Results 22 comments of ericli

> 1、需要考虑当前支持的账号登录、手机号登录、邮箱登录等方式,和多渠道综合设计重构 > 2、支持管理员配置开启哪些登录渠道 多租户方案已纳入规划支持。

# 评审后方案刷新 ## 方案说明 ![image](https://user-images.githubusercontent.com/50794209/205546842-c7c96bec-ab18-4987-9922-c014edd78f5a.png) ## 产品原型 ### 多会话登录 ![image](https://user-images.githubusercontent.com/50794209/201249958-1e15e59d-4dd5-4608-83f5-4624fd475e59.png) ### 多会话存量提醒 ![image](https://user-images.githubusercontent.com/50794209/205546916-7c8ef5ae-a91d-4352-bf3e-9b3595bff3e0.png) ### 登录拦截提醒 ![image](https://user-images.githubusercontent.com/50794209/201250064-e286b639-069d-4e5a-9d56-4a34d77acc4c.png)

## 评审后方案 ![image](https://user-images.githubusercontent.com/50794209/205652621-0ed23e15-1c1a-425b-8529-59824b6f2eb6.png) ![image](https://user-images.githubusercontent.com/50794209/205652688-8369492e-4980-4539-849c-ec3aca3ebdf5.png) ![image](https://user-images.githubusercontent.com/50794209/205652781-f1237176-4b3f-4951-9dd0-3a6d64425d41.png) ![image](https://user-images.githubusercontent.com/50794209/205652888-35b8a8ff-534c-401d-8f2d-b41b4d47f7db.png) ![image](https://user-images.githubusercontent.com/50794209/205653003-dd328bcb-5d37-4a18-89f4-134f050c17fe.png)

# 初版草案 ## 需求背景 ![image](https://user-images.githubusercontent.com/50794209/209422609-a7f0e275-cdee-4022-8ba5-0bb8f05b75ab.png) ## 方案说明 ![image](https://user-images.githubusercontent.com/50794209/209422619-ee9dfcb6-b538-4667-a586-930e51fab95f.png) ## 产品原型 ### 手机号/邮箱必填设置 ![image](https://user-images.githubusercontent.com/50794209/209422629-1eef0d1d-86a8-40c8-b76a-8d2f9e9a5b37.png) ### 登录/通知限制 ![image](https://user-images.githubusercontent.com/50794209/209422637-ef9c14d3-60f8-4d33-a0f1-9a3d53e0b058.png) ### 手机号/邮箱验证 ![image](https://user-images.githubusercontent.com/50794209/209422652-3d2acb24-dccd-4474-a242-7000c42158ed.png)

相关联issue: 1、【已评审】前端有关于用户信息的字段信息需要支持可见、可编辑、脱敏展示设置 #769 (新方案已更新) 2、用户信息中手机号和邮箱应改为非必填 #440 3、[重要] 多租户及多渠道登录需求分析 #889 (已评审) ———————————————————————————————— 针对手机号/邮箱唯一性与必填的逻辑,之前出过相关的方案,并进行了评审。多租户纳入支持后,唯一性校验与必填逻辑需要基于前置方案进行相应调整。 整体字段配置方案会放在多租户之后进行。唯一性校验逻辑可以先做简单支持,即: 单租户内,一个手机号/邮箱仅能绑定一个蓝鲸账号(bk_username).

> 手机号是绑定关系, 目前不是全局唯一的, 如果一个手机绑定多个账号, 目前的登录逻辑是会报错的 > > 所以 > > 1. 拿手机号来发短信, 是不知道他要重置哪个账号的密码 > 2. 如果只输入用户名, 目前手机号是`非必填`的, 假设没有填, 这时候短信是发不出去的(未来手机号也是可选的) > > @Shutulee @Zoeyzhou11 需要产品侧考虑下这里的交互, 可能要做修改 1、未来多渠道登录会约定手机号在单目录下全局唯一。目前只能先给临时方案。 2、非必填的需求要求短信/邮箱二选一(必填其一),未来有了其他的联系方式会多选一,由用户自行选择可行的找回密码方式;未填的联系方式会提醒「不存在/未绑定」。**非必填和多渠道会一起设计。 临时方案: 1、通过输入的用户名定位账号,再走手机号/邮箱重置校验(现在还是必填的逻辑)。 2、只输入手机号,一个手机号绑定多个账号的场景会报错拦截,提醒「该手机号同时绑定多个账号,无法定位账号并重置密码,请输入具体的用户名或联系管理员处理」。...

> 数据恢复逻辑图有点问题,由于用户和组织都是目录内唯一的?恢复时应先判断其所属目录的存在与否,然后才是目录内判断id是否重复。不然可能会做成跨目录判断id是否重复的逻辑。 > > 删除比较简单,数据恢复涉及到的各种交互细节没有提供,至少在设计稿评审时应提供。 1、数据恢复逻辑图已修改 2、交互细节已补充,新增了还原操作的二次确认交互。(详见原型交互) ![image](https://user-images.githubusercontent.com/50794209/200719776-a2aede7e-be66-4e87-94e0-fdf2bca05218.png)

> ## 问题 > ### 删除组织有疑问 > 设计的逻辑: 单组织用户, 跟随组织一并被删除, 以及恢复; 跨组用户, 仅解除用户-组织关系, 恢复组织时, 需要一并恢复 > > * 删除用户 A, 还未过 30 天(未清理) > * 删除 A 的上级组织, 此时联动删除用户, 包括...

> @Shutulee @Xmandon 内部设计稿怎么转出来放 github? 或者第三方存储, 需要共享给到他们 抱歉,我的问题。