Agile PLM: 9.3.0.2中MultiList attribute for User list的显示逻辑分析

本文内容

在Agile PLM 9.3.0.2环境中，有用户反馈，自定义的MultiList for User在打开的时候有的用户能看到用户组，有的用户看不到，而有的用户看到的用户组还会动态的增加，而用户手册完全没有提到这个，因此怀疑是否agile的设计缺陷。本文通过一定的分析过程来揭示其中的来龙去脉。

问题描述

先看下面的两张图。第一个用户看不到下拉列表中有任何用户组可供选择。

第二个用户能看到少量的用户组。

分析

第一印象是否是权限问题，检查第一个用户的Discovery User Group，权限充足。只好从其他方面开始分析。 首先我们从web层面入手，Agile在web2.0技术中大量应用了ajax，比如Yahoo的开源YUI。负责此处显示的脚本为MultiSelectionList.js。我们查看这一个函数 
AGILE.widget.MultiUserSearch.prototype._populateSelectionList

它的逻辑定义非常清晰，规定了如何显示该下拉列表

注意到这里的groups是从服务器中获取，groups为空还是不为空，必须从对应的server的调用类着手。根据grid-table.js的定义，MultiList调用了类AutoCompleteHandler

反编译AutoCompleteHandler.class，注意到下面的逻辑。

归纳一下Multilist for User的下拉列表的处理过程。

1. 下拉列表中显示的用户组由Global User Group，当前用户创建的所有Personal User Group组成。
2. 当全部的用户组数量超过100时，只会显示“在用户组内搜索”而不显示用户组。如果不超过100，则会显示全部的用户组，但不会显示“在用户组内搜索”
3. 当全部的用户组数量超过200时，Agile存在一个BUG，或者说也是一个有意为之的设计，就是不显示任何用户组，也不显示“在用户组内搜索”这一栏。

注意到上面的代码中有一项 

config.getAttributeValue("PREF_USER_GROUP_IDS", "PREF_USER_GROUP_IDS");

在groups超过200的情况下会被清空，但同时agile还要从http中获取PREF_USER_GROUP_IDS。这是什么意思呢？从字面上来看，这是在搜索用户的时候优先选择的用户组列表，注意它是复数（IDS），应该是一个数组列表。 在一个很巧妙的case下，即使用户组数超过200，某些用户也会显示“在用户组内搜索”及一定数量的用户组。

1. 登陆后，打开一个Change,必须找一个Change，然后选择添加审核人
2. 添加的时候选择“在用户组内搜索”，会弹出来另外一个对话框
3. 新的对话框是“选择用户组以在此组内搜索”，查找一个global的用户组
4. 然后确定，这个时候原先的选择列表中会出现那个用户组的名字，在右边的框中，随便输入用户，进行搜索 。在这个时候PREF_USER_GROUP_IDS就包含了这个用户组的ID
5. 然后关闭对话框，退出Change，打开Part
6. 在part中编辑Multilist User栏位，用户会发现刚才选择的那个用户组出现在列表里了，因为PREF_USER_GROUP_IDS已经包含了一个优先选择的组，在下拉列表框中而且也多了个“在用户组内搜索”

比如现在这个图，就多了一个用户组“ug0007”：

那这个PREF_USER_GROUP_IDS保存在哪里呢？在数据库表agileuser中就有这一个栏位

看到这里，这个下拉列表的逻辑已经很清晰了，虽然中间有个不置可否的bug（200的限制，加上诡异的逻辑设计）。

本文只提供一个分析方法，不推荐hack 内部逻辑。