My DL的创建和更新在Suite下完成。
Centralized DL的创建和更新在CA下完成。
在创建DT选取invitee的时候，4个tab，每个tab的behavior如下：
当suite这边的UR控制打开时：
- My DL的创建。可以选择某个company下的user或者role，若suite这边的UR控制这个系统参数设置成了true。则在创建My DL的时候看到的user和role都是已经完成过滤了的user和role。过滤原则：登陆suite的当前user A请求CA的webservice，带参数userName A和tenantName B，CA通过tenantName B get到与此tenant相关的UR (UR1,UR2)，每一个UR都有一个“from user”和“to user”的map关系。若A在UR1的from user集合里，即UR1为这个A的可见UR（UR1对应的to user都是A可见的user）。
- Centralized DL，在选取Centralized DL做为一个Topic的Invitee的时候，对于Centralized DL的可见性，过滤也是请求CA的webservice,通过username A和tenantname B,get到可见的UR(比如：UR1，那此时A必须得在UR1的from user集合里)，除了get到可见的UR还得get到与tenant B相关的DDL(DDL001,DDL002...)和SDL，若DDL001的user list是被包含在UR1下的，则DDL001即为A可见的Centralized DL。对于SDL则同理。
- User，在选取“User” tab来添加user时，若UR控制打开则会请求CA，get到可见的user list，然后再与当前company下的user取一个交集。
- Role。根据当前user A以及他得company获取他所有的role(比如 role1，role2)。然后对于不同的role，如role1 拿到属于此role的所有user，再跟A的可见user list做一个比较，若被可见的user list包含，则此role是可见的。
当suite这边的UR控制未打开时：
- My DL的创建。在选取user时看到的user是当前company下的所有user，若在此时创建了以个My DL（001），然后在suite这边打开UR的控制。则有可能001就在select invitee处看不到了，因为001下的user可能有些不在当前user A的可见user集合里。
- Centralized DL，若UR未打开，可见的Centralized DL跟UR打开时一样，也会请求CA的webservice，在CA那边完成过滤。
- User。在选取“User” tab添加user时，若UR未打开，则可见的user即为CC company下的所有user。
- Role，若UR未打开，则根据UserName A和他得company就可以获取到他所属的role，这些role均可见。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
