Сотрудник не видит того, чего ему нельзя, — и не ищет там, где пусто
Типы объектов защиты
Доступ к процессам разведён по трём независимым типам объектов защиты, и это не формальность: право на один тип не даёт прав на другой. «Разделы процесса» отвечают за то, какие вкладки карточки сотрудник вообще видит и может редактировать. «Статусы процесса» и «Статусы тех процесса» — отдельно от разделов — отвечают за то, какие переходы статусной модели сотрудник может выполнить. Сотрудник может свободно читать карточку и не иметь ни одного права провести её по статусам — и наоборот.
| Тип объекта | Русское имя | Действия | Чем управляет |
|---|---|---|---|
| processSection | Разделы процесса | READ, WRITE | какие из 12 вкладок карточки видны и редактируемы |
| processStatusModel | Статусы процесса | READ, WRITE, EXECUTE | какие переходы статусной модели процесса доступны |
| techProcessStatusModel | Статусы тех процесса | READ, WRITE, EXECUTE | какие переходы статусной модели технологического процесса доступны |
Действия над объектами
EXECUTE — это не синоним WRITE, а отдельное действие: право видеть карточку в определённом статусе (READ), право её редактировать (WRITE) и право провести конкретный переход статуса (EXECUTE) выдаются раздельно. Пример из поставки: одна роль получает право читать и редактировать справочник процессов целиком, а право выполнять переходы статусной модели технологического процесса — от «Создан» до «Удалён» — выдано отдельной ролью, координирующей операционную надёжность, и не совпадает с правом на сам справочник.
Чтение показателя — не значит право его менять
У показателей технологического процесса есть роль с правом только READ и без WRITE: видеть контрольные и сигнальные значения деградации можно, а изменить их — нет. Это разграничение — не пробел, а осознанно выданная комбинация прав.
Роли и шаги согласования
Семь ролей закрывают весь жизненный цикл процесса — от создания записи до финального согласования. Ниже — методический ориентир, какому подразделению заказчика обычно соответствует каждая роль; роли настраиваются под вашу структуру, а не жёстко фиксированы этим списком.
Ролевые фильтры узла «Мои процессы»
Раздел навигатора «Мои процессы» строит собственный фильтр под роль текущего пользователя — менеджеру по качеству данных показывает процессы, где он назначен ответственным за качество, владельцу данных — те, где он владелец, владельцу процесса уровня 3 и менеджеру процесса — объединение «я владелец или я менеджер». Сотруднику не нужно каждый раз настраивать фильтр заново: раздел уже показывает именно его часть реестра.
У КПО и ОРМ — не личный фильтр, а очередь на согласование
Роли «Сотрудник КПО» и «Сотрудник ОРМ» узел «Мои процессы» не получают — вместо личного списка у них отдельные очереди: «Передано на согласование КПО», «Требуют корректировки» и «Передано на согласование менеджеру ОРМ». Задача этих ролей — не «мои процессы», а то, что ждёт именно их решения.
Разграничение прав по уровням иерархии
Право создавать процесс на конкретном уровне иерархии закреплено за ролью, а не за тем, кто первым успел нажать «Создать процесс». Подробный разбор обоих ограничений и точных сообщений системы — на странице «Согласование процесса».
Кто регистрирует справочники и объекты
Реестр процессов не заводит собственного контура прав в отрыве от платформы — все его справочники и типизированные объекты защиты регистрируются общим провайдером модуля операционной надёжности и администрируются тем же инструментом, что и остальная платформа: одна точка настройки, одна модель ролей, один журнал изменений прав.
Соберите меню навигатора по правам
Ни один узел не выдан — меню пустое.
Что это даёт ИТ-директору. Администратор, который ищет раздел «Процессы» в настройке прав, найдёт его внутри операционной надёжности, а не отдельным узлом дерева — это единственное место, где нужно искать права на реестр процессов, и единственное место, где их нужно проверять при аудите доступа.