We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
当前主要的资源数据: 用户 目录 部门 都是通过标记的方式(enabled=0)进行软删除,不同的是,创建时同步冲突的出路策略并不相同:
用户
目录
部门
enabled=0
key
这样的策略会带来一些使用上的困扰:当用户删除了某个用户名的用户,是无法通过产品重新添加同 username 的用户,需要手动在 DB 中删除数据才能重新添加。
username
因为 用户 和 目录 资源是“权限敏感”的,它们常常会被关联到具体的权限项。
在后续的计划中,我们会在同一个目录支持不同的数据源,那么很可能存在一个情况,不同的自然人拥有相同的系统 username,这时候直接恢复已删除的用户,就可能出现权限转移的风险。
相较于程序后台静默地直接复用,提供一个产品功能,显式地告之操作者数据恢复的风险——恢复数据同时权限也将恢复,会更加明智。
恢复数据同时权限也将恢复
The text was updated successfully, but these errors were encountered:
Xmandon
No branches or pull requests
现状
当前主要的资源数据:
用户
目录
部门
都是通过标记的方式(enabled=0
)进行软删除,不同的是,创建时同步冲突的出路策略并不相同:用户
目录
)创建遇到同key
的已删除资源时,程序直接抛出错误部门
创建遇到同key
的已删除资源时,则会恢复当前已删除的资源这样的策略会带来一些使用上的困扰:当用户删除了某个用户名的用户,是无法通过产品重新添加同
username
的用户,需要手动在 DB 中删除数据才能重新添加。为什么不直接复用?
因为
用户
和目录
资源是“权限敏感”的,它们常常会被关联到具体的权限项。在后续的计划中,我们会在同一个目录支持不同的数据源,那么很可能存在一个情况,不同的自然人拥有相同的系统
username
,这时候直接恢复已删除的用户,就可能出现权限转移的风险。手动恢复
相较于程序后台静默地直接复用,提供一个产品功能,显式地告之操作者数据恢复的风险——
恢复数据同时权限也将恢复
,会更加明智。The text was updated successfully, but these errors were encountered: