共计 1711 个字符，预计需要花费 5 分钟才能阅读完成。
用户
在零碎里，用户是一个外围概念。它代表了一个人的惟一身份标识，除了与角色、团队、组织架构等无关，甚至还会影响到在同一个界面不同的用户操作流程与显示内容都会发生变化，再简单一点的话，或者在同一个零碎内的一个用户进入到不同产品后的身份也会变动
用户与角色
用户能够领有一个或多个角色，让角色作为权限组，将一组或多组权限间接的调配给用户
用户与团队
用户能够在多个团队中，每个团队能够领有一个或多个角色，将一组或多组权限通过角色与团队关联，并赋予团队内的成员
团队内成员能够是外部的，也能够是内部的。通过对立的用户表作为人的惟一身份标识。再通过 Employee 和 ThirdPartyUser 辨别用户身份属性。
用户与组织架构
用户能够被指定在组织架构的某一个节点中
但组织架构是一个虚构的树形构造，它归属于业务，所以没有与权限间接关联
除此之外，组织架构有时候很难示意角色继承关系。在同一个组织架构节点中的不同成员经常会具备不同的角色，且上下级关系也未必会作为上下级节点紧贴在一起。有局部公司上下级之间可能隔了几个层级
组织架构在咱们晚期定义中是与权限关联且没有团队这个概念的。但实际上我的项目制在很多公司外部都存在，以我的项目制运行时，人员的权限和虚构组织关系会频繁变动。导致经常要在组织架构调整和大量集体权限微调上做抉择，为了彻底解决这种割裂的行为。咱们把组织架构看作虚构的树形构造来形容每个人的部门归属权，同时采纳团队的形式解决我的项目制下人员频繁进出和到处作战而引发的权限变更问题
用户与权限
用户除了领有角色以外，可能还存在个别非凡业务下须要临时性授予或禁用局部权限
尽管与 RBAC2 有一点抵触，但事实上这样的场景确实存在，比方行将到职的财务须要长期发出付款性能，这里显著要违反互斥准则，在设计上咱们的抉择是扩大权限的优先级高于角色内蕴含的权限。这样能够通过对冲达到发出局部敏感权限的性能
用户类型
用户有三种类型：终端用户，员工，驻场员工
举个例子：
- A 是公司员工，领有外部权限。同时也是公司产品的终端用户
- B 是驻场员工，领有局部外部权限。同时也是公司产品的终端用户
用户权限优先级
用户的权限应该具备肯定的优先级，来解决同一个业务下多个权限同时失效时零碎该抉择激活哪一个
咱们将采纳以下规定：
超级管理员 / 管理员
超级管理员为系统管理员，管理员为指定我的项目的管理员
- 用户的扩大配置权限
用户的角色权限
用户的角色权限抵触时，回绝优先级高于容许，低于用户的扩大配置权限
- 团队的默认角色权限
团队中的父级角色权限
未来在团队反对上下级关系后，以后用户没有被调配到权限，且以后团队存在父级时将向上递归查找间隔最近的默认角色来取得权限列表
用户权限类型
用户的权限类型大略分为四类
- 菜单：是否能够通过菜单拜访某个页面
- 页面元素：是否能够对页面内的元素进行操作，如按钮。页面元素须要挂在菜单下
数据：是否显示指定字段。数据须要挂在菜单下
数据与页面元素相似，但与页面元素之间互相独立
- API：是否能够拜访指定 API。API 个别须要挂在菜单或页面元素下，如有须要也能够挂在数据下
权限层级
总结
至此，咱们从一个用户的角度将角色和权限，前端与后端都串联了起来。但到目前为止还是概念的梳理阶段，做好一个权限核心很难。每个团队有本人的治理形式，如何在不同的团队需要中摘取到共同点把主线串联起来，既能满足绝大部分场景需要又留有扩大余地依然须要工夫去验证。
（本文章不代表最终设计）
参考：
https://uxdesign.cc/design-pe…
开源地址
MASA.BuildingBlocks：https://github.com/masastack/…
MASA.Contrib：https://github.com/masastack/…
MASA.Utils：https://github.com/masastack/…
MASA.EShop：https://github.com/masalabs/M…
MASA.Blazor：https://github.com/BlazorComp…
如果你对咱们的 MASA Framework 感兴趣，无论是代码奉献、应用、提 Issue，欢送分割咱们
