Еще один небольшой опрос, правда я не стал оформлять его в виде галочек-чекбоксов, так как от вас требуется развернутое мнение. В данный момент в SCSM есть только одно отношение, которое относится (не смог придумать, как избежать тавтологии)) ) к пользователю: “пользователь является управляющим” (System.UserManagesUser). Сегодняшний опрос посвящен необходимости вводить еще одно отношения типа “пользователь является членом группы AD”
Такого отношения нет, и тому, скорее всего, есть причины. Я постараюсь изложить своё видение ниже:
- Отсутствие необходимости. Сценариев, где бы понадобилось такое отношение, не так уж много. У нас есть роли, в которые мы включаем реальных пользователей и группы из AD, соответственно здесь это не применимо. Другие сценарии я сходу не смог придумать.
- Нагрузка на сервер. Когда создает связь между объектами (в нашем случае между пользователем и группой), в CMDB создает новый объект. Допустим, что у нас 200 групп, в каждой по 20-30 пользователей в среднем. В итоге будет создано около 6000 объектов. Это в принципе не так и много, но и не мало. Плюс, когда мы начнем получать данные с сервера с помощью type projection, размер получаемых данных может быть довольно большим, если в группе много членов.
Не смотря на п.1, я часто встречаю вопросы, как можно отображать данные в зависимости от группы пользователя, или как маршрутизировать запросы на базе группы обратившегося пользователя и так далее.
Если бы такое отношение было, и автоматически заполнялось из AD с помощью коннектора, то в теории мы могли бы строить запросы вида:
<Expression> <SimpleExpression> <ValueExpressionLeft> <Property>$Context/Path[Relationship='WorkItem!System.WorkItemAffectedUser' TypeConstraint='System!System.Entity']/Path[Relationship='System.UserMemberOfGroup' TypeConstraint='System!System.Entity']/Property[Type='System!System.Entity']/DisplayName$</Property> </ValueExpressionLeft> <Operator>Equal</Operator> <ValueExpressionRight> <Value>GS_main-group</Value> </ValueExpressionRight> </SimpleExpression> </Expression>
Т.е. проверять, что затронутый пользователь для данного обращения является членом группы GS_main-group. Такое условие можно использовать в представлении, в рабочих процессах и в SDK.
Собственно, хотелось бы узнать, что общественность думает на счет необходимости и востребованности такого функционала? Своё мнение излагайте в виде комментариев.
Такой функционал будет востребован. На моем примере, где я с этим столкнулся:
в организации сложная система отделов, где один отдел включает в себя несколько профильных отделов. Критерий принадлежности к отделу — является членство в группе АД. В чем была сложность: не возможно идентифицировать в каком отделе создан рабочий элемент. При наличии данного функционала можно было бы создать очередь на членство в группе для идентификации по отделу.
Еще немного размышлений на данную тему :-)
Может данный функционал уже частично реализован. Например, при создании представления ведь можно отобрать рабочие элементы по принадлежности пользователя к группе
Id
[me]
[mygroups]
Какая-то проверка членства в группе все таки выполняется.