组织结构配置文件的诡异行为
2011-06-30 21:42
211 查看
组织结构配置文件(OrganizationProfile),大家可能比较陌生,尤其对编程访问。具体的操作我就不在这里一一列举了,SDK里面也有例子,这里面只说一个可能和我们的预期不太一样的一个API行为。
在组织结构配置文件中,一个组织中的成员分为两种类型,Leader和Member。可以通过OrganizationProfile的AddMember方法来向这两个部分中加入用户(通过一个参数来进行区分是Leader还是Member),并通过RemoveMember的方式删除之。
如果这个用户不在Member中,我们可是使用下面这句话把用户user1加为Leader
假设在之前这个组织中空无一人,执行完上面这句话的时候,user1既会出现在Leader中,也会出现在Member中,也就是说这个用户同时会自动加到Member里。这个行为很好理解,也make sense。
BUT!(又来了)
假设这个时候user1已经是Leader了(当然他也是Member),看下面这个代码:
执行完这句话你觉得会发生什么?把user1又一次加为Member,你觉得在上面那种假设情况下,应该不会发生任何变化是吧?错了!当我们执行完这句话的时候,user1还在Member中,但已经从Leader中消失掉了。很奇怪吧……我相信这是一个By Design的Bug……
换句话说,当我们要把一个用户加为成员的话,首先你得看一下这个用户是不是已经在成员中了,如果他已经存在,就不要再加一遍了。否则,万一这位用户是这个组织的领导,你一加,领导就没了(这在中国的项目中是多么可怕的行为)
在组织结构配置文件中,一个组织中的成员分为两种类型,Leader和Member。可以通过OrganizationProfile的AddMember方法来向这两个部分中加入用户(通过一个参数来进行区分是Leader还是Member),并通过RemoveMember的方式删除之。
如果这个用户不在Member中,我们可是使用下面这句话把用户user1加为Leader
1: orgProfile.AddMember("domain\\user1",
2: OrganizationMembershipType.Leader);
假设在之前这个组织中空无一人,执行完上面这句话的时候,user1既会出现在Leader中,也会出现在Member中,也就是说这个用户同时会自动加到Member里。这个行为很好理解,也make sense。
BUT!(又来了)
假设这个时候user1已经是Leader了(当然他也是Member),看下面这个代码:
1: orgProfile.AddMember("domain\\user1",
2: OrganizationMembershipType.Member);
执行完这句话你觉得会发生什么?把user1又一次加为Member,你觉得在上面那种假设情况下,应该不会发生任何变化是吧?错了!当我们执行完这句话的时候,user1还在Member中,但已经从Leader中消失掉了。很奇怪吧……我相信这是一个By Design的Bug……
换句话说,当我们要把一个用户加为成员的话,首先你得看一下这个用户是不是已经在成员中了,如果他已经存在,就不要再加一遍了。否则,万一这位用户是这个组织的领导,你一加,领导就没了(这在中国的项目中是多么可怕的行为)
相关文章推荐
- WCF 第五章 行为 通过配置文件暴露一个服务行为
- nginx+php-fpm配置文件的组织结构介绍
- 加载配置文件Behavior行为
- nginx+php-fpm配置文件的组织结构
- nginx+php-fpm配置文件的组织结构介绍
- 思想上移 行为下移---抽象工厂+反射+配置文件
- WCF 第五章 行为 通过配置文件暴露一个服务行为
- 有关nginx+php-fpm配置文件的组织结构
- MyBatis之全局配置文件(Configuration XML)之运行时行为设置(settings)
- WCF的行为与异常-------配置文件说明
- 通过反射该变WCF的Endpoint的行为,而无需修改客户端配置文件
- Tomcat配置文件server.xml中常用元素简介
- 在配置文件中设置全局变量
- hadoop(二)搭建开发环境安装选项:DesktopGnome、Server、Server GUI、ssh、vi(编辑配置文件)、perl
- nginx配置文件详解
- CXF整合Spring配置文件
- maven Settings配置文件详解
- SpringMVC深度探险 —— SpringMVC核心配置文件详解
- 导入文件时http504超时错误通过nginx配置处理
- 用户配置文件