Во второй части материала об автоназначении прав мы переходим от общей логики к практической реализации механизма в 1IDM. Начало статьи читайте здесь.

Ситуация 1. Приём: пакет появляется из модели, а не из чек‑листа

Кадры заводят сотрудника в источнике — 1С:ЗУП, другой HR‑контур или встроенный учёт внешних пользователей. В 1IDM появляются подразделение, должность, тип сотрудника.

На следующем прогоне регламентного задания система проверяет, какие элементы каталога, какие права узлов JIC (включая унаследованные с верхних уровней) и какие отдельные правила на этого человека сейчас распространяются. Недостающее назначается: сначала право‑приложение, без которого нет учётной записи в целевой системе, затем зависимые права и состав бизнес‑роли, если она входит в норму.

Администратору целевой системы не нужно вспоминать чек‑лист «AD, почта, 1С, СКУД». Согласующим не нужно подписывать то, что и так следует из должности. Сотрудник получает не «что успели завести вручную», а пакет, который уже описан в модели.

В автоназначение имеет смысл класть то, что положено всем на этой позиции. Привилегированный доступ, проектный контур, доступ «сверх должности», права по совместительству — это отдельная заявка.

Ситуация 2. Перевод: то же задание забирает старое и назначает новое

Сотрудник переходит из продаж в поддержку, из филиала в головной офис, со специалиста на руководителя группы. Меняются должность и подразделение — меняется и то, под какие узлы иерархии и какие правила он теперь попадает.

Без автоназначения обычно происходит одно из двух: права добавляют поверх старых («пусть пока останется») или снимают вручную «на глаз» и на третий день выясняется, что закрыли нужную папку.

Регламентное задание делает это как сверку, а не как два разных процесса. Человек больше не в прежнем подразделении — унаследованные и назначенные по старому узлу права отзываются. По новому месту, должности и правилам назначается актуальный пакет.

Наследование по иерархии здесь особенно полезно. Пакет филиала задан на узле филиала — и уходит вместе с уходом из этой ветки, без отдельного правила «забрать всё, что было в городе N». Пакет компании, висящий выше, остаётся, потому что человек из иерархии компании не выпал.

Ситуация 3. Когда дерева ОШС мало — отдельные правила

Каталог и оргструктура хорошо описывают «всем в этом отделе» и «всем с этой должностью». Жизнь часто сложнее.

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

Для этого и нужны отдельные правила автоназначения: гибкость, которой нет у привязки «право → узел ОШС» или «право → кто указан в карточке каталога». Динамическая выборка уточняет состав: не «все бухгалтеры», а «бухгалтерия + внутренний сотрудник + конкретная организация». Правило применяется к актуальному составу выборки на момент прогона задания.

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

Ситуация 4. Норма и исключение: автоназначение не отменяет заявку

Рабочая модель доступа двухслойная.

Нижний слой — то, что положено роли. Его задают каталог, ОШС с наследованием и правила. Это одинаково для всех, кто подходит под условие, и не зависит от того, умеет ли сотрудник формулировать заявку.

Верхний слой — то, чего роли не положено, но нужно этому человеку. Проект, временное замещение, доступ к чужой базе «на две недели», привилегированная учётная запись, права по совместительству. Это заявка, маршрут, срок. И это как раз тот слой, который потом видит пересмотр.

Если в автоназначение кладут редкие привилегии, система назначает их пакетом всем, кто попал под условие. Если в заявку отправляют даже почту и интранет, согласование обесценивается: его проходят не читая.

Практический критерий простой. Право нужно почти всем на этой должности или в этой ветке оргструктуры и не требует отдельного обоснования — ему место в автоназначении. Право зависит от проекта, личной задачи, совместительства или повышает риск — ему место среди запрашиваемых.

Автосогласование в маршруте заявки — соседний механизм. Оно ускоряет уже запрошенное. Автоназначение заявку не создаёт: право появляется или исчезает на прогоне регламентного задания.

Ситуация 5. Увольнение и смена статуса: отзыв — часть того же пересчета

Назначить — только половина работы задания. Вторая — увидеть, что человек больше не подходит под условие.

Сотрудник уволен, закрыта должность, он вышел из подразделения или из выборки правила. На прогоне система не ищет «событие увольнения, чтобы на него среагировать». Она видит актуальное состояние: под каталог, узел JIC и правила человек больше не попадает — автоматически назначенное отзывается.

Поэтому автоназначение, которое умеет только добавлять права, — незавершённая настройка. Тогда после приёма пакет появляется, а после ухода или перевода остаётся жить своей жизнью. Задание, которое сверяет модель в обе стороны, как раз не даёт норме и факту разъехаться.

Длительное отсутствие — отдельный случай только если это отражено в данных, от которых считаются условия: статус, реквизит, попадание в выборку. Нет признака в модели — нечему измениться и на прогоне. Есть признак, и от него зависит правило или привязка — задание заберёт или оставит права так же, как в любом другом расхождении модели и факта.

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

Без неё типичный доступ живёт в очередях заявок и в памяти администраторов. Новый человек ждет, пока ему «оформят как у Иванова». После перевода «тащит» за собой чужой контур. Руководители ставят «да» на почту и интранет, потому что иначе человек не работает. Пересмотр раздувается до проверки всей роли — в том числе того, что и так следует из должности.

С автоназначением норма роли перестает быть договоренностью и становится работающим контуром. Сотрудник начинает работать, не дожидаясь ритуала заявки на очевидное. Перевод меняет пакет, а не наращивает его. Согласование остаётся для настоящего исключения — и поэтому его снова имееют смысл читать. Аттестация смотрит туда, где решение принимал человек, а не модель, и не тратит цикл на то, что система удерживает сама.