Последующие темы описывают использование ролей и групп в коллективах контекста.

Роли связывают участников в контексте приложения с данными и задачами, управляемыми из этого контекста. Роли помогают образовывать группы людей с однотипными обязанностями в контексте наиболее целесообразным образом для коллектива. Если есть приглашенные стать участниками контекста приложения, администратор контекста должен назначить по крайней мере одну роль, такую как "Конструктор" или "Проверяющий", каждому лицу. Участники могут быть назначены в контексте более чем на одну роль. Набор назначений ролей для каждого участника отображается в таблице Участники.

Хотя создание некоторых ролей предусмотрено при создании контекстов приложения и организации, для каждого контекста с помощью таблицы Участники могут быть также определены дополнительные роли, если контекст не использует общий коллектив или если используемый общий коллектив может быть локально расширен.

У роли администратора контекста есть особые полномочия создавать и организовывать контекст приложения, приглашать или удалять участников коллектива, а также управлять операциями контекста. В контекстах проектов или программ роль администратора контекста также предусматривает управление данными отслеживания проекта или программы.

Пользователь, создающий контекст, автоматически назначается на роль администратора контекста. Чтобы разделить управление контекстом приложения, администратор контекста может назначить других участников на роль администратора контекста. Доступны следующие роли администраторов контекста:

Роль "Гость" позволяет просматривать контекст приложения без фактического приглашения стать участником. К участникам, назначенным на роль "Гость" определенного контекста, применяются следующие разрешения:

Доступом к информации в контексте приложения можно управлять при помощи ролей. Каждая роль связана с системной группой, имеющей то же самое имя, что и роль. Администратор или администратор контекста может задавать правила политики управления доступом для каждой системной группы с помощью утилиты "Администрирование политики". Кроме того, владелец объекта может предоставить или отменить разрешения управления доступом для объекта с помощью действия Править управление доступом. Например, при выгрузке нового файла или создании новой папки или детали, лицо, создающее этот объект, отвечает за настройку доступа к информации.

Дополнительные сведения о ролях, доступных в каждом решении Windchill, а также разрешениях управления доступом, которые могут быть заданы, см. в разделе Обзор управления доступом.

Группы используются для управления доступом к информации, ограничения видимости действий, обеспечения взаимодействия по электронной почте и приглашения участников на совещания. Например, можно пригласить на совещание участников совещания и разослать приглашения по группам по электронной почте.

Существуют системные группы, которые используются с коллективами контекста, так же как определяемые пользователем группы, которые могут создаваться и поддерживаться в контекстах организации и сайта, или создаваться и поддерживаться через сервер каталогов предприятия. Системные группы используются для управления членством ролей коллектива и поддерживаются только в базе данных Windchill. В этом разделе рассматриваются системные группы, которые используются с коллективами. Дополнительные сведения об определяемых пользователем группах, которые можно создавать в Windchill, см в разделе Группы (организации) или Создание группы.

Каждая роль, которая определена в коллективе контекста или шаблоне коллектива, имеет соответствующую системную группу, которая автоматически создается под тем же именем. Например, системной группой роли для роли "Администратор изменений II" является "АДМИНИСТРАТОР ИЗМЕНЕНИЙ II", а системной группой роли для роли "Участники" является "УЧАСТНИКИ". Пользователи, добавленные к роли, автоматически добавляются к соответствующей системной группе. Администратор контекста может после этого создать политики доступа для системных групп с помощью утилиты "Администрирование политики". Политики применяются принудительно всякий раз, когда используются роли.

Следующие дополнительные системные группы создаются для использования с коллективами контекста.

В качестве примера предположим, что создан контекст приложения и сотрудники организации "Компания A" добавлены к коллективу контекста как участники в ролях, доступных в коллективе. При этом действии создаются следующие системные группы.

Позднее были приглашены и присоединились к контексту сотрудники организации "Компания Б". Затем все участники коллектива из "Компании Б" были добавлены к группе "Участники коллектива" и была создана дополнительная группа под названием "Компания Б". Эта группа содержит только участников коллектива из "Компании Б".

Кроме того, при создании правил политики управления доступом в контекстах сайта и организации можно использовать динамические роли, которые доступны в утилите "Администрирование политики". Динамические роли представляют группы коллектива контекста и организации, которые поддерживаются для каждого коллектива контекста. Например, роль Роль коллектива контекста: инженер, которая доступна с вкладки Роли, при создании правила политики управления доступом представляет системную группу "Инженер", связанную с коллективами контекста и общими коллективами. Правила, созданные для динамических ролей, наследуются дочерними контекстами контекста организации, в котором были созданы правила. Правила должны быть созданы в домене, который является родителем домена, используемого в контексте приложения. Дополнительные сведения об использовании динамических ролей см. в разделе Использование динамических ролей для централизации администрирования правил управления доступом.