Изменить профиль MC-пользователя у партнёра: запрос основной системы и решение владельца
Увеличить схему
Основная организация предлагает изменение
Сотрудник получает новую роль, а для работы у партнёра продолжает использовать ранее выданный профиль. Возникает вопрос, кто должен внести изменения. Административный обмен ACM предусматривает запрос основной системы на обновление профиля пользователя, назначенного партнёром.
В таком запросе передаётся служебный идентификатор пользователя, созданный партнёрской системой, и предлагаемый обновлённый профиль. Это предложение проходит предусмотренные проверки. Оно не означает, что администратор основной организации непосредственно редактирует любые настройки чужой системы.
Как согласовать изменение роли
Предположим, сотрудник становится ответственным за совместную ремонтную группу. Стороны сначала определяют, какие сведения его партнёрского профиля действительно должны измениться. Затем фиксируют исходную версию, запрашиваемую конфигурацию и идентификатор, под которым этот человек известен партнёру.
Основной ACM-сервер проверяет полномочия инициатора. Партнёр сохраняет, проверяет и рассматривает запрос в соответствии со своей политикой. При ручной обработке уполномоченный пользователь решает, одобрить ли предложенное изменение. Внутренние действия применения профиля рассматриваемая процедура не стандартизует.
Отсюда следует практическое требование: в результате должны быть видны решение и фактически применённые сведения. Один факт доставки предложения не подтверждает новую роль сотрудника на площадке партнёра.
Приёмка изменения без догадок
В тестовом контуре выбирают пользователя с известным партнёрским профилем. Отправляют согласованное обновление и прослеживают цепочку до окончательного ответа. Затем партнёр показывает применённый профиль доступным административным способом.
После этого проверяют именно то действие, ради которого запрашивалось изменение. Если требовалась возможность работы в определённой проектной роли, тест должен подтверждать соответствующий разрешённый сценарий. Универсальное обещание любых новых полномочий по одному положительному ответу недопустимо.
Отдельный опыт предусматривает отклонение предложения партнёром. Проверяют понятность результата для инициатора и сохранность согласованного исходного состояния. Если изменение требует дальнейшего обновления клиента, поставщик документирует этот участок и способ подтверждения его завершения.
Какие сведения сохранить
Карточка содержит основной и партнёрский ID, исходный профиль, предложенное изменение, решение партнёра и наблюдавшийся эффект. Чувствительные настройки хранят в защищённом контуре, а в обычном отчёте оставляют статус и указатель.
Такое сопровождение сохраняет ответственность владельца профиля и даёт основной организации управляемый способ запросить нужное изменение. При следующей смене роли инженер видит, что было предложено, что принято и что реально заработало. Это устраняет спор между «заявку отправили» и «пользователь уже получил новые возможности» до выхода сотрудника на совместный объект.
Запросы отправляются на наш e-mail из вашей почтовой программы.
